※ 引述《stu87616 (文組工程師)》之銘言：
: 於是我在基本架構實現到八成左右後與團隊討論是否能夠整進專案內，
: 這時成員就提出了質疑
: 1. 原先目的的那個小需求，不客製接口，只用原生的，
: 再加上一些額外的流程一樣做得到，只大概會損失 10% ~ 20% 的效能，
: 而且這個效能長期來說可以忽略，沒有必要多花這麼多時間串接；
: 2. 這個客製流程我就算有信心改到沒 bug 真的可以用，
: 我走了的話，以後的人會很難維護
: 第一點我不介意多花時間來做這個流程，畢竟都做得差不多了，也很有成就感
: 第二點就無法反駁了，我完全沒有信心能夠把這套流程完美交接給別人
都是放屁 別想太多
既然都叫你優化了 又不是你今天沒由沒來自己搞個優化在那庸人自擾
誰assign這個任務給你 誰是團隊最大咖的 聽他的就對惹
這個產業多的是一堆只會質疑卻沒有答案的人
1. 10~20% 假設這個數據是實際的 那就要看使用情境
假設這個功能 每秒執行個五六次 不要講20% 10%就夠了
假若這個功能 他媽每千年才執行一次 多個100%都沒人在乎
客戶能不能從這個優化受益 能不能感受到 才是最實在的
剩下的都是工程師在自嗨
2. 難維護個屁
會有這種質疑 只有兩種狀況
a) 你真他媽屌 這技術全台大概每十個工程師只有一個會
b) 你同事真他媽爛 反正就不想了解新的
c) 你寫得有夠難懂 你解釋人家聽不懂
: 這個問題讓我陷入了困惑，在以前做一人專案的時候，
: 我可以毫不顧忌的追求效能，偶爾也會寫得很髒
: 但是要考慮到易維護性的話，很多東西就要變的綁手綁腳了
: 想請問，像這樣的抉擇，通常都是怎麼選呢
介面包裝好就好了呀 真的受不了就寫註解嘛
code寫得乾淨整潔 是一種習慣 說綁手綁腳 我覺得只有要不要的問題
有些人好像你要他多打個字就會死一樣
你寫演算法 代碼寫得再屌再乾淨再好懂
他媽不懂演算法的還是覺得很難維護 問你為什麼不用bubble sort
最後還是八十二十法則而已
講東西難交接 怕會失傳 就是放他媽的屁
要嘛就是新人沒實力 要嘛就是程式寫太爛
能5min上手的技術 還叫技術嗎