※ 引述《peanut97 (丁守中)》之銘言：
: 大家中秋節快樂，快收心了。
: 想問一個假設性問題，大家在工作上，如果有一份專案的 code 是某位前人一手寫的
: 後來新人加入，變成前人帶新人，此時繼續維護那份code。
: 但再過一陣子，前人離職了，唯一的創始者走了。
: 新人把舊 code 重構，或是砍掉重鍊的機率高嗎？
先跟主管、老闆提，確認有人支持你，不然你會被當成怪物
「為什麼要改？」
「系統好好的幹麻改？」
「改了有好處嗎？」
「會花多久時間？」
「時間剩不多，要動不動隨便你，不要影響到時程」
: 我的想像是，如果一份code是出自於1個人之手
: 我的想像是，如果一份code是出自於1個人之手
: 那麼code就是他的世界觀、他的切入點
: 那麼code就是他的世界觀、他的切入點
: 後面的人看著他的世界觀，有時候不一定能全部接受
: 而有人的地方就有政治
: 當他還在的時候，當然就不會亂動。
: 而當他走了的時候，後面的人，一看不爽，就可能改寫成自己看得爽的、
: 好改的code。
: 如果是一個團隊，那當然要好好討論為什麼要改
: 哪些因素造成現在不好的情況，以及主管同不同意改等等的。
: 只是我很好奇，1,2人的專案，改的機率高嗎？
: 是不是，code只能是「現在還存在公司的人」能控制的才行。
我們公司的經驗，以前因為很多原因 (十幾年前的 code)
導致系統沒有測試、沒有嚴謹的 coding style、方法註解也很少
copy paste 是基本，沒有遵照 SOLID
錯誤不是丟 null 就是 false (欸! 我的 Exception 呢？
每個 team 成員想怎麼寫就怎麼寫，不管後續的漣漪
反正東西交出來就好 多棒
然後中間當然成員就是來來去去的
我看這之中大概也是 有人進來 -> 看 code -> what the fuck？ -> 離職
大概就是這種循環
因為自己痛過，知道 clean code、設計模式 的重要性
進公司沒多久就跟主管說這 code 不能搞，一定要重構
每個工程師一定看不爽前人的 code XD
但是不是說說而已，總是要提出改善的方法
理所當然地，你前面那些問題我都被問過
幸好我的主管與老闆也是支持我這件事情
但是我們討論的結果，現在的 code 也沒辦法全部翻掉，怎麼辦
在那個時候剛好要把原本的系統生出一套 API
原本的系統是 server-side template render，模板與資料、樣式高耦合
這個沒辦法改成 API
我們的作法是，把原本 DAO 抽出來，放進框架裡當成 library
然後加一層 Adaptor 讓新系統相容舊模組
舊的 DAO 邏輯怎樣就不去動他，要改一律在 Adapter 裡面改
(就算 method rename 也是)
在這個新系統，以 SOLID 與設計模式為基楚
controller 與邏輯之間，包裝成 service 呼叫 (一律把該寫的東西放在該去的地方)
service 只准有抽象的敘述，實作的部分寫成介面去依賴，由子類別注入 service
使用 DI Container 自動注入依賴的類別，不准直接 new (方便替換測試)
提交功能分支以前，要一併提交單元測試與 functional test，否則不准進 develop
這些都是規定好寫在專案文件裡面的 (以前沒有的文件，現在開始留下記錄)
接著就是重頭戲的部分