※ 引述《stu87616 (文组工程师)》之铭言：
: 于是我在基本架构实现到八成左右后与团队讨论是否能够整进专案内，
: 这时成员就提出了质疑
: 1. 原先目的的那个小需求，不客制接口，只用原生的，
: 再加上一些额外的流程一样做得到，只大概会损失 10% ~ 20% 的效能，
: 而且这个效能长期来说可以忽略，没有必要多花这么多时间串接；
: 2. 这个客制流程我就算有信心改到没 bug 真的可以用，
: 我走了的话，以后的人会很难维护
: 第一点我不介意多花时间来做这个流程，毕竟都做得差不多了，也很有成就感
: 第二点就无法反驳了，我完全没有信心能够把这套流程完美交接给别人
都是放屁 别想太多
既然都叫你优化了 又不是你今天没由没来自己搞个优化在那庸人自扰
谁assign这个任务给你 谁是团队最大咖的 听他的就对惹
这个产业多的是一堆只会质疑却没有答案的人
1. 10~20% 假设这个数据是实际的 那就要看使用情境
假设这个功能 每秒执行个五六次 不要讲20% 10%就够了
假若这个功能 他妈每千年才执行一次 多个100%都没人在乎
客户能不能从这个优化受益 能不能感受到 才是最实在的
剩下的都是工程师在自嗨
2. 难维护个屁
会有这种质疑 只有两种状况
a) 你真他妈屌 这技术全台大概每十个工程师只有一个会
b) 你同事真他妈烂 反正就不想了解新的
c) 你写得有够难懂 你解释人家听不懂
: 这个问题让我陷入了困惑，在以前做一人专案的时候，
: 我可以毫不顾忌的追求效能，偶尔也会写得很脏
: 但是要考虑到易维护性的话，很多东西就要变的绑手绑脚了
: 想请问，像这样的抉择，通常都是怎么选呢
接口包装好就好了呀 真的受不了就写注解嘛
code写得干净整洁 是一种习惯 说绑手绑脚 我觉得只有要不要的问题
有些人好像你要他多打个字就会死一样
你写算法 代码写得再屌再干净再好懂
他妈不懂算法的还是觉得很难维护 问你为什么不用bubble sort
最后还是八十二十法则而已
讲东西难交接 怕会失传 就是放他妈的屁
要嘛就是新人没实力 要嘛就是程式写太烂
能5min上手的技术 还叫技术吗