原文：https://news.cnblogs.com/n/730599/
-------------------------------------------------
軟件行業中的人都“知道”代碼質量很重要，但從來沒有任何數據或數字可以證實這一點。因此，健康的代碼庫的重要性在業務層面被大大低估了——超過 90% 的 IT 經理缺乏管理技術債務的流程和策略。
在本文中，我們將通過探究最近關於代碼質量的研究來探討其影響。隨着開發速度提高了兩倍，bug 減少了 15 倍，完成時間的不確定性顯著減少，代碼質量的業務優勢也就變得清晰了。讓我們來深入探究一下，看看如何利用這些數字爲自己創造優勢。
定義技術債務
技術債務這種比喻的說法最初是開發人員向業務人員解釋重構需求和權衡的一種方式。然而，這個詞在今天有了更廣泛的含義。
組織之所以會承擔技術債務，有多方面的原因。也許是因爲我們試圖通過犧牲代碼質量來更快地交付功能，也許是因爲我們對業務的理解發生了變化，導致設計不再匹配，也許是因爲我們的設計一開始就不合適？
因此，雖然原因不同，但結果是相同的——我們最終得到的代碼的維護成本比原本的要高。
量化技術債務造成的浪費
最近關於代碼質量對業務影響的研究表明，一般來說，由於技術債務和糟糕的代碼，公司平均浪費了開發人員 23% 到 42% 的時間。但似乎這還不夠令人感到擔憂，關於軟件開發人員由於技術債務而導致的生產力損失的研究還發現，開發人員經常“被迫”引入新的技術債務，因爲公司一直在用代碼質量換取新功能等短期收益。
然而，技術債務的影響比財務浪費更加深遠。技術債務同樣會影響開發人員的幸福感和工作滿意度（參見 Graziotin 和 Fagerholm 在 2019 年撰寫的關於軟件工程師的幸福感和生產力的論文）。
很少有開發人員喜歡使用本來可以避免的糟糕代碼。這樣的代碼導致我們在解決問題的過程中被困在壓力和時間緊迫感之中。高利息的技術債務加劇了開發人員的流失。
這個問題並不侷限於開發人員。在過去的幾年裏，我也看到過許多技術管理者放棄並離開。我還記得向一家知名公司 CEO 做過一場關於技術債務的報告。報告進行到一半時，這位 CEO 驚叫道：“現在我明白爲什麼前 CTO 會離開了。”未能得到緩解的技術債務的連鎖反應在整個組織中嚴重地打擊了士氣。
我們是不是陷入了事倍功半的泥潭
擁有一個高效的軟件團隊是一種競爭優勢。作爲一家公司，如果我們想要在市場上站穩腳跟，需要快速對客戶的需求做出反應，根據反饋採取行動，並持續創新。我們需要在更短的產品週期內實現這一點。
顯然，這需要熟練的軟件開發人員。不幸的是，軟件開發人員全球短缺——我們不能繼續僱傭更多的人，因爲不存在。
考慮到這些限制，在技術債務上浪費一半的資源在我看來是一種糟糕的權衡。
作爲一種思想實驗，我們假設開發人員 42% 的時間確實花在處理技術債務上。這意味着，如果你的組織中有 100 名工程師，你只得到相當於 58 人的產出。然而——這是關鍵——實際的浪費要比這多得多。100 人與 58 人之間的協調、管理和溝通開銷是真實存在的。布魯克斯定律告訴我們，增加人員數量是有代價的。在一個人員過剩的項目中工作是痛苦的：你花在同步會議上的時間比花在代碼編輯器上的時間還要多。
探索代碼庫中的技術債務
技術債務的主要問題是代碼缺乏可見性。代碼是一種抽象的概念，不是組織的所有成員都可以理解。因此，即使我們意識到了普遍存在的問題，仍然很容易忽略掉技術債務。對代碼庫進行量化和可視化是關鍵，對於工程團隊以及產品和管理來說都是如此。
可視化是很奇妙的，因爲它讓我們進入已知宇宙中最強大的模式探測器：人腦。我在“Your Code as a Crime Scene”中深入探索了這一概念，並在 2015 年創建了 CodeScene，以便讓普通觀衆能夠使用這些技術。
我們使用的可視化方法學習起來很快。一旦找到了這些方法，可以用它們來指出代碼庫中的強點和弱點，以此來增強整個組織。此外，可視化可以讓你評估潛在問題的深度。
我來分享一個來自兩個流行的開源項目的例子。
在前面的可視化中，每個圓對應一個帶有源代碼的模塊。顏色反映了代碼的健康狀況（參見“管理技術債務”，以獲得更深入的瞭解）：
綠色的代碼易於理解，風險低；
黃色表示警告，存在技術債務；
紅色的代碼表示存在嚴重的維護問題和技術債務。
對代碼的運行狀況進行可視化是堅實的第一步。然而，技術債務的實際成本是你爲使用了不符合標準的代碼所支付的利息。爲了確定利息，我們需要了解組織如何處理正在構建的代碼。讓我們看看它是如何工作的。
根據利息來考慮技術債務優先級
技術債務的利息不能僅從代碼中計算出來。幸運的是，我們可以通過像 Git 這樣的版本控制系統來獲取這些關鍵信息。特別是我們可以獲取每段代碼的變更頻率，即提交的數量，並用它們來了解代碼對開發人員的影響。將其與一些複雜性指標（如代碼健康狀況）相結合，我們就可以識別出需要經常處理的複雜代碼。我稱之爲交叉熱點。
熱點爲我們提供了相關性維度，而代碼健康與質量維度相輔相成。爲了管理技術債務，我們需要兩個維度。下面是一個來自真實代碼庫的例子。
熱點的最大優勢在於，它們將信息限制在可操作的範圍內。作爲一個組織，我們不能也不應該一次性重構和重新設計所有的代碼。熱點讓我們能夠平衡短期目標，比如新特性和代碼庫的長期可持續性。
通過達到這種平衡，我們可以系統地償還技術債務，並騰出時間進行有價值的創新。這些結果可能可以真正地改變遊戲規則。Carterra 的案例是一個很好的例子，這是一家領先的生物技術研究公司，報告稱在解決了他們的熱點問題後，計劃外工作減少了 82%。通過精確識別正在開發中的文件及其相關的代碼健康狀況，Carterra 可以確定他們的工作優先級。
可度量的代碼質量業務影響
有了代碼健康狀況和熱點之後，我們就有了進行完整循環所需的一切。如果沒有可量化的業務影響，就很難有理由投入資源去償還技術債務。當代碼持續惡化時，我們使用的任何指標都有被視爲虛榮指標的風險。我們不希望這樣的事情發生。
正如之前所說的，我們以前找不到能夠證實高代碼質量重要性的數據。在我們的紅色代碼白皮書中，我們調查了來自不同行業和領域的 39 個商業代碼庫，以此來改變這種狀況。
紅色代碼白皮書表明，代碼質量對發佈時間和產品的外部質量都有顯著的影響。
紅色代碼中的缺陷平均數量是健康代碼庫的 15 倍。這種缺陷密度會給產品帶來不合格的體驗。
紅色代碼造成了大量的浪費。向紅色代碼中添加一個特性所需的平均時間是綠色代碼的兩倍多。
在紅色代碼中實現一個特性所需的時間是綠色代碼的 9 倍。
在這些發現當中，最重要的是低質量代碼的不可預測性。向健康的代碼中添加特效似乎是一個可預測的過程。數據表明，在不健康的紅色代碼中添加新特性在時間方面有顯著的變化，可能要長 9 倍。這給組織帶來了不確定性。
我將通過一家持有紅色代碼的虛擬公司來詳細說明這種不確定性意味着什麼。這家公司可能能夠在 9 個月內實現一種新特性。如果他們的競爭對手持有綠色代碼，他們可以在一個月內實現相同的特效。這家公司很難跟上競爭對手的步伐。可見代碼質量是一個真實的、可度量的競爭優勢。
代碼質量和前進速度是相關的
在我從事軟件行業的 25 年裏，有很多人告訴我，我們沒有時間做 X。X 可以是重構、適當的單元測試，或者重新調整架構以適應變化的業務環境。似乎存在一種誤解，認爲速度和質量是相互排斥的。紅色代碼白皮書的數據表明，實際上不存在這樣的權衡。而事實恰恰相反——我們需要高質量的代碼才能快速前進。
對於我來說，吞吐量的增加很大程度上是不確定性降低的結果。簡單的代碼可能造成的意外更少，造成破壞的風險也更低。健康的代碼還反映了強大的工程文化，這很可能說明組織有其他一些重要的實踐。
最後，值得注意的是，紅色代碼的發現表明了一種類似於之前由 Accelerate/DORA 研究提出的關係理論——部署週期越短，生產故障就越少。
處理遺留代碼或低質量代碼
代碼健康指標清楚地表明我們需要保持較高的標準。然而，大多數時候我們並沒有編寫新的代碼，我們也需要處理遺留代碼。那麼如何在這種情況下應用這些指標呢？
大規模處理遺留問題和代碼質量問題具有一定的挑戰性。在過去的十年裏，我有幸分析了 200 多個代碼庫。我發現行爲代碼分析技術是必不可少的。我使用這項技術的過程概述如下。
獲取情形意識——主要問題出在哪裏、問題有多嚴重、問題的深度如何？
用一種能夠讓所有涉衆（工程和管理）分享想法的語言進行總結。我們前面看到的代碼健康狀況可視化技術就是爲此目的而設計的。
根據影響情況來安排優先級——一個常見的錯誤是設定量化目標（例如，“我們將在 N 個月內將代碼質量的問題數量從 5000 個減少到 2500 個”)。問題是，組織不需要解決所有的技術債務。這是對技術債務的一種常見誤解，源於忽略了技術債務的利息。
低利息債務可能是我們未來需要關注的風險，但絕對不是當務之急，我們可以把它們看作是免費貸款。
我們要重點解決熱點問題，優先解決高利息債務。在進行這種區分時，熱點分析是必不可少的。
讓相關進展可見。在美國，很多組織都會將代碼健康狀況指標作爲 KPI，我自己也發現這樣做很有價值。然而，真正的進展是通過業務結果來衡量的。我建議將吞吐量指標與以質量爲中心的反饋循環結合起來。具體地說，我已經看到了衡量計劃外工作數量的趨勢的價值（例如，bug 修復、生產崩潰——任何不在路線圖上的事情）。
在償還了技術債務後，計劃外工作的數量也會減少，正如我們在前面的案例研究中看到的那樣。這使得開發更加可預測，而且組織可以專注於開發令人興奮的特性，而不是被動地修復問題，這是一個很大的好處。我在我的白皮書“The Business Costs of Technical Debt”中提到了相關細節。
對技術債務採用數據驅動的方法
在本文中，我們看到由於技術債務造成的浪費是巨大的，並帶來了實實在在的業務風險。爲什麼這種浪費會被容忍，一種解釋可能是因爲技術債務的影響在以前不可能在源代碼級別進行量化。
本文介紹的紅色代碼研究爲我們提供了挑戰現狀並將代碼質量提升到業務 KPI 級別的方案。結合熱點分析技術，我們甚至讓這些發現變得具有可操作性。作爲一家軟件公司，區分紅色代碼和綠色代碼有助於你通過數據驅動的方法來解決技術債務。
作者簡介：
Adam Tornhill 是一名工程學和心理學學位的程序員。他是 CodeScene 的創始人，這家公司專門設計軟件工程智能工具。Tornhill 是多本技術書籍的作者，包括暢銷書“Your Code as a Crime Scene”，也是一位獲過獎項的軟件研究人員。Tornhill 的其他興趣還包括音樂、武術和復古計算機。
原文鏈接：
https://www.infoq.com/articles/business-impact-code-quality/