技術債務管理以及Firefox/Chromium的債務評價

現在的軟體開發是在遍地敏捷，人人講唯快不破的時代，哪有人有時間思考程式碼質量，設計的質量？ 哪個又不是從一堆程式碼中殺出血路來實現另一個功能？一個產品都存活不了幾年，何必考慮什麼可維護性？

我們追求進度的時候，總是要犧牲些東西，或是破壞了一些東西等著後面補。這就是技術債！ 管理不好，債臺高築，即使不破產，也是要拆東牆，補西牆的玩平衡。現實是殘酷的，但不影響我們抬頭看看這個世界。

技術債務

技術債務(Technical Debt)這個詞，我最早是從InfoQ關於Uber的一個訪談中瞭解到的，正好也在思考持續重構的問題，發現它是推動持續重構的有效工具。所以花了點時間做些學習，在這裡做個分享，主要來自這篇文章的學習，有時間的直接看原文就好了:
Technical Debt in Firefox and Chromium

關於技術債務，並不是新名詞，就不考據它的歷史了。其實很多團隊都有類似的工具，比如:問題記錄，優化點，TODO List等等。但是通常是比較鬆散，大雜燴式的，不繫統。

我總結之前沒有管理好有兩點:

1. 範圍太大
   在一篇IEEE 2012一期的文章(Technical Debt:From metaphor to Theory and Practice)裡也強調了一個重要的觀點，Technical Debt不要同需求和Bug搞在一起, 應當聚焦在對未來有負作用的設計和實現，通常都是無法直接感知的。比如效能優化到多少多少，這不是技術債務。回想以前做的優化點，太過於聚焦於功能，更像為了未來開發工作安排的參考。
2. 缺少到位的管理
   如果一件事只是追求錦上添花，它自然就會被排到低優先順序。然後，太天真了，其實沒有然後了。

對策就不說了，這是一個管理問題，見仁見智。如果沒有意識，或者正如開頭說的，如果覺得沒有必要的話，確實不需要做什麼，因為大家都差不多。

如果想要做，我們如何定義和評估技術債務呢？ 向領先者學習！FireFox和Chromium都算是比較大的開源專案了，分別是280萬行和470萬行的規模。看看他們的總結就是很好的學習了。核心是以量化的方式評價和管理程式碼，工具是基於SciTools Understand。(其實以發現&記錄的方式也很好，這裡只是作為參考的方式。)

技術債務的量化 (即程式碼質量的評價)

主要來自How maintainable is the Firefox codebase?。要優化，就要先定義問題和評價的標準。
以下程式碼質量評價的維度：

1. LOC (程式碼行數)
   代表了程式碼的規模。可以用這個:cloc
   程式碼量越大，系統的複雜越高，但是相對的Bug率反而越低。評估的物件沒有說明，顯然是針對設計良好的系統。如果架構設計良好，並且大家都遵守，這樣新增的功能都會集中以元件的形式實現，並不會改變介面，這是Bug沒有擴散的原因。
2. 圈複雜度
   不多說了，不知道的看這裡:圈複雜度評價及工具。如果要嚴謹的定義，以軟體工程類書中的定義為準。
3. 一階密度 (First-Order Density)
   用於評估檔案間的直接依賴程度，因為是直接依賴，所以是一階，裡面只有A和B的關係。對應的工具是DSM, Design Structure Matrix。Github上可以找到一個工具，我沒有試過。
4. 變更成本 (Propagation Cost)
   評估隨意的改一個檔案，平均會影響到多少檔案。它可以反應直接依賴的一階關係，也可以隨著間接依賴層次上升的高階關係。
   這也是一個衡量架構設計的重要指標。歡迎推薦相關的工具。
5. 核心程式碼大小 (Core size)
   所以核心程式碼，是從依賴關係上定義的。如果檔案間有著環形依賴形式的高度依賴就是所謂的核心程式碼。很多研究已經證明，這類的程式碼量越小，Bug就越少。

工具

1. 程式碼靜態分析工具
   LOC, 圈複雜度，以及依賴關係這些都容易通過一個靜態分析工具來獲得。
   比如兩者的程式碼量變化:
   
   兩者的圈複雜度:
   

2. 網路化處理 (Network Multiplication)
   通過網路化處理，可以得出變更成本，一階密度，核心程式碼大小的資料。
   下圖為Firefox&Chromium變更成本的比較:
   
   下圖則是Core size的對比:
   

3. DSM工具。
   DSM其實很簡單。就是描述系統中各個元素的有無關係。橫軸和縱軸都是系統各個元素，如果i,j有關聯，則矩陣中(i,j)就是為true，或者作個標記。
   下圖就是作者提供的一張Firefox 16的DSM:
   
   左側為直接依賴，右側為間接依賴。

更詳細的內容，參考:Technical Debt in Firefox and Chromium
資料可以在這裡體驗:http://www.almossawi.com/firefox/
完整的文件在Github上:Tools
其大致的處理流程如下圖:

總結

技術債務的定義只是參考，更重要的還是意識和執行。有了基本概念和意願，執行的工具就很靈活，完全一個技術管理的行為。

關注微信公眾號交流:

轉載請註明出處: http://blog.csdn.net/horkychen