成長系列第二篇-有技術債就得還
- 2020 年 2 月 17 日
- 筆記
今天的主題是技術債，康威法則和重構
技術債的由來
最早聽別人談起過，軟體版本每次迭代的需求包含兩個來源，一個是業務需求，另一個是技術改造。
業務需求毫無疑問會以研發產品特殊的方式立項開發。
技術改造來源於技術內部，研發人員認為實現方法方式不合理，架構不靈活等方面都可以納入技術改造的範疇。
在正常的公司開發流程中，業務需求總是壓著技術改造被優先處理，技術遺留問題很多時候很難被發現，屬於改造不改造，短期內都可以的情況。
而一旦技術遺留問題的影響逐步顯現出來，往往改造的成本就會變高，如果技術遺留問題得不到及時解決，久而久之就會變成技術債。
技術債清償計劃
康威法則說過每個部門都有一堵牆，正常情況下，每個部門都在自己部門的角度來做開發計劃。每個部門無法在對項目整體的技術優先順序和了解業務情況下再決定技術方案和改進方案，其中最重要的就是技術選擇和實現優先順序。
每個項目或者核心功能點錯過合適的時間檔口，那就變成了技術債，之後在業務方的運行進程中，原則上不會為之前的錯誤，嘗試，架構優化甚至是技術改造補充足夠的時間檔期。
說簡單點，就是在該開發好的時間節奏內沒有開發好。後邊沒有人關注的情況下，系統就在那裡平躺的運行了，要付出很多代價來彌補之前的業務理解不到位，架構不合理等各種問題。
如何解決呢
關於技術債和老項目重構，本文不展開來講，說兩點比較重要的。
重構和老項目的重構改造優化，都需要得到領導和同事的支援，那麼如何說服領導和團隊成員對於一個老項目進行重構？
1 將問題轉化為可以量化的業務指標，業務驅動，讓量化的指標幫助參與者做決策。
2 將需要解決的問題分類梳理，進行重構的目標管理，看到希望就會有人支援。
end 2020 年 1 月整理
