重構
該篇開頭提到一點：一名優秀開發人員，重構應當成為一種習慣。
大佈局你傷不起
很多公司都會有維護多年的大系統，會有以下問題
- 程式碼很亂
- 開發人員換很多任、維護工作越來越困難
- 文件不齊全
從過去瀑布開發週期長狀況下，需求→設計→開發→測試→交付，在整整數個月開發，無法知道對不對…成功失敗各佔50% 成功的專案管理，就是將失敗降到最低…
最常見的案例就是，公司常常會開會起個頭，我們要某某個案子和需求，甚至系統想改造，這時候一群IT的人開會，有資深工程師或PM或是架構師這些人起頭，大家都會遇到系統改造，首先要對系統進行梳理，整理他的業務需求，肯定不齊全，功能業務都沒整理清楚怎麼改造啊?
當然要整理功能，系統架構整理，怎麼分層，怎麼制定介面，細緻工作，反覆驗證，然後大家討論一致可行，丟給底下的人做，經過分析、設計、開發、測試、上線，等到系統上線後數個月，以前舊系統修復問題，在新系統再次出現…客戶覺得改造系統爛，IT隊友真是豬隊友等等，經常上演系統的循環。
如何失敗降到最低
- 每工作一個月做一次檢查，可以知道工作這個月項目對不對，發現錯誤，損失一個月
- 每週檢查一次，發現錯誤，損失一週
- 每天檢查一次，發現錯誤，損失一天
總結：錯誤發現的越早，損失越小。
系統改造的方案應該怎麼做?
不要搞這麼大局，大佈局傷不起，不要去掌握無法掌控未來，小設計可以讓你成功。
筆者解讀應該是要怎麼大的項目當中，抓到整體方向，目標為確保是進行對的方向
再來確認隊的項目部分，應該會是拆解小項目，轉換成小設計，能夠持續迭代改善。
一次重構時間由我們設計決定
- 小設計對程式碼修改量小，完成重構時間越短
- 大設計對程式碼修改量大，完成重構時間長，完成重構時間長，測試週期長，發現錯誤時間越晚，損失越大
元哥的筆記