作者stu87616 (文组工程师)
看板Soft_Job
标题[讨论] 效能与易维护性的取舍?
时间Sat Jan 20 22:24:29 2018
各位先进好，
小弟现在手上的专案迎来了一次架构优化的机会，正好由我负责
为了达成某个特定的小需求，我发现下到底层去客制一些接口就可以完美做到，
由於本来份内的工作就完成得很快，我就利用多余时间如火如荼地进行实作。
虽然花了不少时间，但该作法确实是可行的，
於是我在基本架构实现到八成左右後与团队讨论是否能够整进专案内，
这时成员就提出了质疑
1. 原先目的的那个小需求，不客制接口，只用原生的，
再加上一些额外的流程一样做得到，只大概会损失 10% ~ 20% 的效能，
而且这个效能长期来说可以忽略，没有必要多花这麽多时间串接；
2. 这个客制流程我就算有信心改到没 bug 真的可以用，
我走了的话，以後的人会很难维护
第一点我不介意多花时间来做这个流程，毕竟都做得差不多了，也很有成就感
第二点就无法反驳了，我完全没有信心能够把这套流程完美交接给别人
这个问题让我陷入了困惑，在以前做一人专案的时候，
我可以毫不顾忌的追求效能，偶尔也会写得很脏
但是要考虑到易维护性的话，很多东西就要变的绑手绑脚了
想请问，像这样的抉择，通常都是怎麽选呢
--
我觉得
Ｃ＃是世界上最强的语言了 π红胶咖咖褐希希
Ｃ ◥▁▁▁▁ ◢ 麦
其他的应该废除 省宝水啡啡雨嘉
＃ ◤
██ ／-
科
石 食 燕嘉
□–□◢◤ 舒
如果各位有兴趣的话，可以现在开始学
谱
▼ㄑ ◢ 服
但是要安装
VisualStudio ▼ㄧ ／◣ 特
因为我们只会支援
精英IDE，绝对不会接受
垃圾 ψ ◢ /◣– ◤ /█◣
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 101.8.147.212
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1516458274.A.EC1.html
1F：→ angusyu: 留下文件不就好了吗？都做完了还在那边唧唧歪歪 01/20 22:32
2F：→ testPtt: 看要不要改 01/20 22:33
3F：推 maxqq: 无论如何文件都要写得乾净 01/20 22:38
4F：→ maxqq: 第二个我想你提的方案可以在未来效能扩充时的参考方案 01/20 22:39
5F：→ maxqq: 留下注解与方法即可 01/20 22:39
6F：→ maxqq: 容易维护，有时真的必须放第一考量 01/20 22:40
7F：推 SHANGOYANYI: 你客制化新的接口 旧的还在吧？ 新的别人不会用叫他 01/20 22:42
8F：→ SHANGOYANYI: 们继续用旧的啊... 01/20 22:42
因为专案最後势必是选一个做，
成员当然就会觉得如果我打从一开始就用简单作法，就没有转移成本了
当下我都有冲动说那我两个都做算了(还好没说
※ 编辑: stu87616 (101.8.147.212), 01/20/2018 22:50:12
9F：推 CGS0: 留下文件 想一下怎麽教别人 01/20 23:20
10F：→ netburst: 管以後干嘛 你只要管你接下来自己开发上好不好写 01/20 23:55
11F：→ netburst: 离职以後都不甘你的事 01/20 23:56
12F：→ netburst: 多改了会加薪吗 出BUG也是你死 01/20 23:56
13F：→ vi000246: 重构很脏的程式码 达成效能跟维护兼顾 01/21 00:50
14F：→ vi000246: 不过我会选1 反正上面不在意就好 干嘛多花时间做 01/21 00:52
15F：推 t64141: 在效能没大问题前提下，我会以程式码的乾净优先 01/21 00:54
16F：→ t64141: 毕竟维护的是人，为了一点点效能牺牲维护性长期来说不一定 01/21 00:55
17F：→ t64141: 是好事 01/21 00:55
18F：推 CCben: 只听leader的话就好，问它想要什麽。不要管你队员讲什麽可 01/21 01:23
19F：→ CCben: 维护性，因为说不定你现在接手的烂程式码就是来自要求须有 01/21 01:23
20F：→ CCben: 可维护程式码的猪队员^^ 01/21 01:23
21F：嘘 darkMood: 当然是易维护性啊，反正又不追求效能，别拖累别人啊 01/21 01:29
22F：→ y3k: 追求效能是机器运作效能还是人的作业效能? 01/21 01:34
23F：→ y3k: 前者还OK 後者我就认为糟糕 01/21 01:35
24F：→ y3k: 有些程式码根本是外行人写出来 只是可以动而已 这种当然要修 01/21 01:36
25F：→ y3k: 阿 除非只是一个已经快死的专案... 01/21 01:37
26F：→ y3k: 阿 我第一句可能造成误会 说的是"现在"的作业效能XD 01/21 01:38
27F：推 strlen: 效能成本可以承担的情况下当然选择易维护性 01/21 01:59
28F：推 strlen: 文件和注解可以写 但最好不要将之视为主轴 01/21 02:01
29F：推 abccbaandy: 没有效能需求当然选易维护阿...不过好奇20%效能差异是 01/21 02:19
30F：→ abccbaandy: 什麽架构阿，有点猛 01/21 02:20
31F：→ joyce66789: 有没有bug是你走後别人说的，不是你说的算。後人没有 01/21 02:23
32F：推 RunRun5566: 少写文件ㄅㄅ 01/21 06:07
33F：推 del680202: 像原PO这行为 在我公司称作工程师的暴走 01/21 08:08
34F：推 del680202: 自high 请在不影响他人为前提 01/21 08:10
35F：推 shiauji: 易维护 框架再好烂掉没人维护也没用 01/21 08:18
36F：→ pttworld: 原本需求用量的评估。不常用的维护性优先 01/21 08:53
37F：推 stephen23032: 效能瓶颈不在这里的话上我会选择好用的，不是技术展 01/21 10:07
38F：→ stephen23032: 示。 01/21 10:07
39F：推 mozume: 先写好维护的,有效能需求再调,在公司内写可能会转手多人的 01/21 10:07
40F：→ mozume: 程式时要先预定自己和接手是笨蛋的概念,文件不可信 01/21 10:08
41F：→ mozume: 推荐阅读之前讨论「如何沉住气读别人的 code」系列 01/21 10:10
42F：→ alan3100: 改底层又不能交接给别人 这就是地雷 01/21 11:16
43F：推 yyc1217: 我会以如何让他人轻易上手维护为第一 如果效率只差一点点 01/21 11:24
44F：→ yyc1217: 的话 01/21 11:24
45F：→ yyc1217: 毕竟系统会一直改 不可能就这样永远不变 01/21 11:24
46F：→ yyc1217: 甚至是为了三个月後的自己着想 01/21 11:25
47F：→ ChoDino: 如果那接口是整个系统的瓶颈，你改写他才有意义。 01/21 11:38
48F：推 shortoneal: 其实你一开始合的时候找人帮忙review就好 01/21 11:39
49F：→ shortoneal: 优化根可维护很少是完全冲突的，大部分都是懒的藉口 01/21 11:40
50F：→ ChoDino: 不然就是造成维护上的困扰。如果资源都用不完却花时间在 01/21 11:41
51F：→ ChoDino: 这，是不明智的事。 01/21 11:41
52F：→ shortoneal: 今天如果你拿这种战绩去外面面试嘴炮，大部分会是扣分 01/21 11:41
53F：→ shortoneal: 而不是加分 01/21 11:41
54F：推 james732: 想知道这10%的提昇会有什麽好处？ 01/21 11:48
55F：→ james732: 更实际的说，可以让公司省钱税赚钱吗 01/21 11:48
56F：→ james732: 省钱或赚钱 01/21 11:48
57F：推 clamperni: 如果是架构的话人脑效率比较重要 01/21 11:58
58F：推 WiseLin1125: 哪那麽复杂，问leader就好 01/21 12:14
59F：推 olen0622: 你不必想这麽多 这种专案都是能交件能丢给码农维护优先 01/21 12:22
60F：→ olen0622: 不用特地想说我能把这东西做多好 风险人家无法承担 01/21 12:22
61F：→ olen0622: 事实是你能优化搞不好大家也行阿 但有其他考量且没必要 01/21 12:24
62F：推 Argos: 这不是废话？没人在乎效能差距当然是易维护性为最高考量 01/21 13:38
63F：→ Argos: 极度不专业的人才会在不要求效能的状况下为了效能搞烂code 01/21 13:39
64F：→ Argos: 就算是要求效能 那也要把影响效能最大的核心割出来 01/21 13:40
65F：→ Argos: 其它部份还是以易维护性为最高考量 基本中的基本中的基本 01/21 13:41
66F：→ saladim: 好奇新改的介面是有多难懂跟多复杂? 01/21 14:47
67F：推 za755188: 大家都发明新的路 最後程式无法维护 01/21 15:14
68F：推 abc0922001: 当然是效能差又难维护，後面有事做+只有你能做（X 01/21 16:11
69F：→ atpx: 以管理面来说, 效能不是主要考量的情况还是以维护性为主 01/21 16:28
70F：→ iceonly: 挖，这10%是怎麽算的 01/21 18:40
71F：→ MOONY135: 只有自己才看的懂的...半年之後应该就会靠北自己了吧 01/21 19:09
72F：推 justben: 键盘工程师猜:底层那段应该只有你知道吧 建议就是 01/21 20:38
73F：→ justben: 把底层那段接口 写得物件导向一点 或者整理一下就好了 01/21 20:38
74F：→ justben: 参数可以的话 多丢几个框架 再过去 别人比较好查 01/21 20:41
75F：推 cutem: 在下不觉得这二者有冲突。 01/21 22:17
76F：推 chuegou: 以维护组语的经验 效能取向就算注解 自己还是重看很久 01/21 22:47
77F：→ chuegou: 所以乖乖的走维护取向 01/21 22:47
78F：推 Sunal: 用2你要如何证明没有bug 01/21 23:19
79F：→ PUTOUCHANG: 看薪水工时比, 时间少交差就好, 还做啥狗屁文件 01/22 01:38
80F：推 cobrasgo: 看有没有类似compile flag的东西隔开，不然开个branch 01/29 08:22
81F：推 leveger0903: 有些公司不太接受程式重构 但如果有机会重构 我觉得 02/02 13:23
82F：→ leveger0903: 机会难得 有点羡慕 02/02 13:23