重構學習筆記(3)-大話重構第三章-小步快跑開發模式-筆記

重構

該篇開頭提到一點:一名優秀開發人員,重構應當成為一種習慣。

大佈局你傷不起

很多公司都會有維護多年的大系統,會有以下問題

  • 程式碼很亂
  • 開發人員換很多任、維護工作越來越困難
  • 文件不齊全



從過去瀑布開發週期長狀況下,需求→設計→開發→測試→交付,在整整數個月開發,無法知道對不對…成功失敗各佔50% 成功的專案管理,就是將失敗降到最低…

 

最常見的案例就是,公司常常會開會起個頭,我們要某某個案子和需求,甚至系統想改造,這時候一群IT的人開會,有資深工程師或PM或是架構師這些人起頭,大家都會遇到系統改造,首先要對系統進行梳理,整理他的業務需求,肯定不齊全,功能業務都沒整理清楚怎麼改造啊?

 

當然要整理功能,系統架構整理,怎麼分層,怎麼制定介面,細緻工作,反覆驗證,然後大家討論一致可行,丟給底下的人做,經過分析、設計、開發、測試、上線,等到系統上線後數個月,以前舊系統修復問題,在新系統再次出現…客戶覺得改造系統爛,IT隊友真是豬隊友等等,經常上演系統的循環。

 

如何失敗降到最低

  • 每工作一個月做一次檢查,可以知道工作這個月項目對不對,發現錯誤,損失一個月
  • 每週檢查一次,發現錯誤,損失一週
  • 每天檢查一次,發現錯誤,損失一天

總結:錯誤發現的越早,損失越小。

系統改造的方案應該怎麼做?
不要搞這麼大局,大佈局傷不起,不要去掌握無法掌控未來,小設計可以讓你成功。

筆者解讀應該是要怎麼大的項目當中,抓到整體方向,目標為確保是進行對的方向
再來確認隊的項目部分,應該會是拆解小項目,轉換成小設計,能夠持續迭代改善。

 

一次重構時間由我們設計決定

  • 小設計對程式碼修改量小,完成重構時間越短
  • 大設計對程式碼修改量大,完成重構時間長,完成重構時間長,測試週期長,發現錯誤時間越晚,損失越大

老E隨手寫