遺留系統之殤
本系列文章均整理自《C++代碼整潔之道——C++17可持續軟件開發模式實踐》
測試金字塔
在軟件開發項目中有不同級別的質量保證措施, 這些不同級別的質量保證措施通常使用金字塔的形式形象的表達, 也就是所謂的測試金字塔.
因爲實踐表明, 關於測試實施和維護的總成本是朝着金字塔頂端增長的. 大型系統的測試和手動的用戶驗收測試通常是很複雜的, 並且一般需要大規模的組織又難以實施自動化.
但是不幸的是, 在一些軟件開發項目中, 你會發現退化的測試金字塔. 這些項目中人們把更多的精力投入到高層的測試中, 忽略甚至沒有單元測試.
破窗效應
此理論認爲環境中的不良現象如果被放任存在, 會誘使人們仿效, 甚至變本加厲.
一幢有少許破窗的建築爲例, 如果那些窗不被修理好, 可能將會有破壞者破壞更多的窗戶. 最終他們甚至會闖入建築內, 如果發現無人居住, 也許就在那裏定居或者縱火. 一面牆, 如果出現一些塗鴉沒有被清洗掉, 很快的, 牆上就佈滿了亂七八糟的東西. 一條人行道有些許紙屑, 不久後就會有更多垃圾, 最終人們會視若理所當然地將垃圾順手丟棄在地上. 這個現象, 就是犯罪心理學中的破窗效應.
童子軍原則
在離開露營地的時候, 應該讓露營地比你來之前還要乾淨.
改善代碼並不一定要大刀闊斧的去做, 也可能只是一次小小的清理. 例如:
- 重命名命名不佳的類, 變量, 函數或方法
- 將大型函數分解爲更小的函數
- 讓需要註釋的代碼不言自明, 以避免註釋
- 清理複雜而令人費解的 if-else 組合
- 刪除一小部分重複的代碼
代碼所有權集體化
代碼所有權集體化意味着我們應該真正的融入團隊. 每個團隊成員在任何時候都可以對任何代碼進行更改或擴展, 不應該有這樣的態度 “這是 A 的代碼, 這是 B 的模塊, 我不會碰他們!”. 其他人可以接管我們寫的代碼, 這應該被當做一種很高的衡量標準, 團隊中的任何人都不應該害怕, 或者必須獲得許可才能整理代碼或添加新功能. 代碼所有權集體化這種文化將使童子軍原則很好的執行.
是什麼在阻擋我們的步伐
- 不健全的測試體系. 沒有測試的 “重構” 不能稱之爲重構, 它僅僅是到處移動垃圾代碼! 這一點我們心知肚明, 所以我們信奉只要他還能正常工作, 就不要動他. 沒有堅實的基礎設施支持我們進行哪怕是小範圍的重構.
- 難以添加的單元測試. 圖形項目難以添加單元測試是客觀事實. 再有就是設計風格極差的代碼本身就難以爲其設計單元測試.
- 費時費力的 code review 與代碼格式檢查.
- 重構其他代碼與自身工作安排的衝突.
惡性循環
如何改善
我們首先開啓了爲遺留代碼補充單元測試的工作, 新需求按照 TDD 的方法進行開發, 期望通過建立更加完善的測試體系來打破上述的惡性循環
但是爲遺留系統補充單元測試確實非常困難, 任重道遠, 方向方法都還需要不斷的摸索改進.