楼主:
stu87616 (文组工程师)
2018-01-20 22:24:29各位先进好，
小弟现在手上的专案迎来了一次架构优化的机会，正好由我负责
为了达成某个特定的小需求，我发现下到底层去客制一些接口就可以完美做到，
由于本来份内的工作就完成得很快，我就利用多余时间如火如荼地进行实作。
虽然花了不少时间，但该作法确实是可行的，
于是我在基本架构实现到八成左右后与团队讨论是否能够整进专案内，
这时成员就提出了质疑
1. 原先目的的那个小需求，不客制接口，只用原生的，
再加上一些额外的流程一样做得到，只大概会损失 10% ~ 20% 的效能，
而且这个效能长期来说可以忽略，没有必要多花这么多时间串接；
2. 这个客制流程我就算有信心改到没 bug 真的可以用，
我走了的话，以后的人会很难维护
第一点我不介意多花时间来做这个流程，毕竟都做得差不多了，也很有成就感
第二点就无法反驳了，我完全没有信心能够把这套流程完美交接给别人
这个问题让我陷入了困惑，在以前做一人专案的时候，
我可以毫不顾忌的追求效能，偶尔也会写得很脏
但是要考虑到易维护性的话，很多东西就要变的绑手绑脚了
想请问，像这样的抉择，通常都是怎么选呢
有些公司不太接受程式重构 但如果有机会重构 我觉得机会难得 有点羡慕
作者:
angusyu (〒△〒)
2018-01-20 22:32:00留下文件不就好了吗？都做完了还在那边唧唧歪歪
作者:
testPtt (测试)
2018-01-20 22:33:00看要不要改
作者:
maxqq (max)
2018-01-20 22:38:00无论如何文件都要写得干净第二个我想你提的方案可以在未来效能扩充时的参考方案留下注解与方法即可容易维护，有时真的必须放第一考量
你客制化新的接口 旧的还在吧？ 新的别人不会用叫他们继续用旧的啊...
作者:
CGS0 (Mike Chen)
2018-01-20 23:20:00留下文件 想一下怎么教别人
作者:
netburst (133 134 592)
2018-01-20 23:55:00管以后干嘛 你只要管你接下来自己开发上好不好写离职以后都不甘你的事多改了会加薪吗 出BUG也是你死
重构很脏的程式码 达成效能跟维护兼顾不过我会选1 反正上面不在意就好 干嘛多花时间做
作者: t64141 (榕树) 2018-01-21 00:54:00
在效能没大问题前提下，我会以程式码的干净优先毕竟维护的是人，为了一点点效能牺牲维护性长期来说不一定是好事
作者:
CCben (new man)
2018-01-21 01:23:00只听leader的话就好，问它想要什么。不要管你队员讲什么可维护性，因为说不定你现在接手的烂程式码就是来自要求须有可维护程式码的猪队员^^
作者:
y3k (激流を制するは静水)
2018-01-21 01:34:00追求效能是机器运作效能还是人的作业效能?前者还OK 后者我就认为糟糕有些程式码根本是外行人写出来 只是可以动而已 这种当然要修阿 除非只是一个已经快死的专案...阿 我第一句可能造成误会 说的是"现在"的作业效能XD
作者:
strlen (strlen)
2018-01-21 01:59:00效能成本可以承担的情况下当然选择易维护性文件和注解可以写 但最好不要将之视为主轴
没有效能需求当然选易维护阿...不过好奇20%效能差异是什么架构阿，有点猛
作者: joyce66789 (拉拉) 2018-01-21 02:23:00
有没有bug是你走后别人说的，不是你说的算。后人没有
像原PO这行为 在我公司称作工程师的暴走自high 请在不影响他人为前提
作者:
shiauji (消極)
2018-01-21 08:18:00易维护 框架再好烂掉没人维护也没用
作者:
pttworld (批踢踢世界)
2018-01-21 08:53:00原本需求用量的评估。不常用的维护性优先
效能瓶颈不在这里的话上我会选择好用的，不是技术展示。
作者:
mozume (米虫)
2018-01-21 10:07:00先写好维护的,有效能需求再调,在公司内写可能会转手多人的程式时要先预定自己和接手是笨蛋的概念,文件不可信推荐阅读之前讨论“如何沉住气读别人的 code”系列
作者:
yyc1217 (somo)
2018-01-21 11:24:00我会以如何让他人轻易上手维护为第一 如果效率只差一点点的话毕竟系统会一直改 不可能就这样永远不变甚至是为了三个月后的自己着想
作者:
ChoDino (Dino)
2018-01-21 11:38:00如果那接口是整个系统的瓶颈，你改写他才有意义。
其实你一开始合的时候找人帮忙review就好优化根可维护很少是完全冲突的，大部分都是懒的借口
作者:
ChoDino (Dino)
2018-01-21 11:41:00不然就是造成维护上的困扰。如果资源都用不完却花时间在这，是不明智的事。
今天如果你拿这种战绩去外面面试嘴砲，大部分会是扣分而不是加分
想知道这10%的提升会有什么好处？更实际的说，可以让公司省钱税赚钱吗省钱或赚钱
作者: WiseLin1125 (Wise) 2018-01-21 12:14:00
哪那么复杂，问leader就好
你不必想这么多 这种专案都是能交件能丢给码农维护优先不用特地想说我能把这东西做多好 风险人家无法承担事实是你能优化搞不好大家也行阿 但有其他考量且没必要
作者:
Argos (Big doge is watching u)
2018-01-21 13:38:00这不是废话？没人在乎效能差距当然是易维护性为最高考量极度不专业的人才会在不要求效能的状况下为了效能搞烂code就算是要求效能 那也要把影响效能最大的核心割出来其它部份还是以易维护性为最高考量 基本中的基本中的基本
作者:
saladim (杀拉顶)
2018-01-21 14:47:00好奇新改的接口是有多难懂跟多复杂?
作者: za755188 2018-01-21 15:14:00
大家都发明新的路 最后程式无法维护
作者:
atpx (秋雨的心情)
2018-01-21 16:28:00以管理面来说, 效能不是主要考量的情况还是以维护性为主
作者:
iceonly (只有冰)
2018-01-21 18:40:00挖，这10%是怎么算的
只有自己才看的懂的...半年之后应该就会靠北自己了吧
作者:
justben (BEN)
2018-01-21 20:38:00键盘工程师猜:底层那段应该只有你知道吧 建议就是把底层那段接口 写得物件导向一点 或者整理一下就好了参数可以的话 多丢几个框架 再过去 别人比较好查
作者:
cutem (大少爷)
2018-01-21 22:17:00在下不觉得这二者有冲突。
作者:
chuegou (chuegou)
2018-01-21 22:47:00以维护组语的经验 效能取向就算注解 自己还是重看很久所以乖乖的走维护取向
作者:
Sunal (SSSSSSSSSSSSSSSSSSSSSSS)
2018-01-21 23:19:00用2你要如何证明没有bug
作者:
cobrasgo (人鱼线变成鲔鱼线，超帅)
2018-01-29 08:22:00看有没有类似compile flag的东西隔开，不然开个branch