大多數(shù)軟件開發(fā)人員都很熟悉技術債務，而編程專業(yè)以外的人就不一定知道了。但了解這個概念十分重要，因為它不僅存在于編程領域，也存在于短期決策可能影響長期結果的廣泛場景。

什么是技術債務？

簡而言之，當軟件開發(fā)團隊急于快速交付而忽略了代碼質量時，就會產生技術債務，比如用戶可能迫切需要某項功能，所以開發(fā)人員選擇先部署“僅僅夠用”的代碼并打算在以后再修復和優(yōu)化。如果最后沒有重新檢查和修復這段代碼，這圖一時方便的操作所帶來的代價就是日后工作量的增加，就像不償還貸款就會產生利息和罰金一樣。技術債務本身不一定是問題，但如果日后產品優(yōu)化不足或者任由異常的代碼泛濫，就會成為一個不容小覷的問題。為了跟上市場快速變化的步伐，企業(yè)轉向的敏捷開發(fā)在一定程度上加劇了技術債務的風險，開發(fā)運維（DevOps）促進頻繁的代碼發(fā)布和持續(xù)不斷的改進，每天甚至每幾個小時就需要推送新代碼，開發(fā)人員可能會迫于壓力而在文檔規(guī)則或測試上“走捷徑”。

技術債務實例

“計算機千年蟲危機”正是一個經典的技術債務案例。在六十年代和七十年代，許多軟件開發(fā)人員為了節(jié)省寶貴的內存而只使用兩位十進制數(shù)來表示年份，比如“1973年”被存儲為“73”而不是“1973”。這種做法持續(xù)了多年，甚至在內存價格下降的時候也是如此。許多這樣的程序被嵌入到運營業(yè)務中，并且使用的時間遠遠超過了人們的預期。隨著2000年的臨近，數(shù)千家企業(yè)和政府機構意識到當系統(tǒng)進行跨世紀的日期處理運算時就會出現(xiàn)錯誤的結果，進而引發(fā)各種各樣的系統(tǒng)功能紊亂甚至崩潰，因此進行了大量瘋狂的清理工作。據(jù)估計，解決“千年蟲問題”花費了近千億美元。

另外，技術債務并不止發(fā)生在軟件上。比如網絡安全領域的一項最佳實踐是將文件權限授予組織內的角色而不是個人。假設一名行政助理得到了上級的批準，可以臨時訪問他平時無權查看的敏感文件。如果IT組織批準了這一例外，但在后來沒有撤銷權限，那就等同于把敏感文件的永久訪問權授予了一個最終可能被入侵并出現(xiàn)漏洞的帳戶。

技術債務的影響

如果短期內能夠迅速修復并且開發(fā)人員知道如何處理技術債務，那么技術債務幾乎不會產生壞處，甚至促使企業(yè)快速響應機會或問題而帶來好處。

但當技術債務層層疊加時，修復工作因為缺少文檔記錄或者根本沒有文檔記錄，且當執(zhí)行修復工作的開發(fā)人員離職后，企業(yè)對這段代碼只能束手無策，不知其義何談修復。任何冒然的更改都可能會導致程序失敗或運行緩慢，企業(yè)怕承擔該風險就不愿做出改進，使得創(chuàng)新速度減慢。

技術債務的類型

技術債務主要分為有意產生和無意產生。開發(fā)人員培訓公司Construx的首席執(zhí)行官Steve McConnell將有意產生的技術債務定義為根據(jù)戰(zhàn)略故意承擔的技術債務，將無意產生的技術債務定義為“因為做得不好而產生的非戰(zhàn)略結果”。

2014年，一群學者制定了技術債務分類法，將技術債務分成13種不同的類型，包括架構債務、代碼債務、缺陷債務、設計債務、流程債務和測試債務等。這種分類法涵蓋了所有因短視思維而可能導致的長期問題的場景，因此十分實用。

技術債務的產生

有意產生的技術債務是刻意做出的決定，因此應記錄成文檔并安排重構。而無意產生的技術債務發(fā)生的原因可能是臨時措施產生了修改或添加并且沒有特意制定代碼重構計劃，也可能是由于缺乏技術知識或未能遵守開發(fā)標準而導致的不良設計決策。例如，當測試套件不完整或者為了方便而縮短或跳過測試環(huán)節(jié)時，就會無意產生測試債務。

文檔債務是一種十分常見的技術債務，發(fā)生的原因是開發(fā)人員沒有完整記錄他們的代碼。從長遠看，如果有人在離開公司時沒有留下幫助別人理解其代碼的線索，就會產生嚴重的問題。文檔債務是造成“千年蟲問題”的一個主要原因。

技術債務的預兆

技術債務的“預警信號”有：

●   由于開發(fā)人員缺乏對代碼庫的深入了解而導致項目陷入困境；

●   由于復雜性或缺乏文檔而出現(xiàn)難以修復的錯誤；

●   錯誤修復后產生了新的錯誤或性能穩(wěn)定下降。

技術債務的預防

要知道如何處理技術債務，首先要有健全的開發(fā)實踐，比如DevOps環(huán)境中的測試左移和右移。測試左移是指將測試流程提前到整個開發(fā)周期中，以便在生產之前預見并解決問題。測試右移是指在應用進入生產階段后收集反饋，以便在軟件被廣泛使用之前提前發(fā)現(xiàn)并修復錯誤。這些預防措施可以防止產生更大的問題。

造成技術債務的臨時措施不可避免，但開發(fā)人員必須記錄在案，包括原因和修復說明。也可以通過定期審查現(xiàn)有代碼，讓團隊成員互相檢查工作，主動發(fā)現(xiàn)文檔的缺陷或異常代碼。

了解技術債務的重要性

有人說現(xiàn)在每家公司都是軟件公司，每年構建的軟件數(shù)量持續(xù)快速增長。就連重工業(yè)企業(yè)也在為了讓客戶從購買的產品中獲得更多價值而挖掘數(shù)據(jù)。

與此同時，開發(fā)部門需要將項目快速投產，忙碌不堪的開發(fā)人員自然會“走捷徑”，而項目經理應該予以理解并向團隊強調測試和文檔記錄的重要性。

有哪些最佳實踐？

采用DevOps技術的企業(yè)應該明確什么是技術債務并采取敏捷的策略加以管理。企業(yè)可以使用測試右移和左移以及A/B和金絲雀測試技術在問題失控之前發(fā)現(xiàn)問題；另外，同行代碼審查能夠從新的視角檢查開發(fā)人員的工作。開發(fā)人員應該使用一套統(tǒng)一的規(guī)定工具和語言，并有一份每個階段需要完成的任務清單。有效率的DevOps部門不但提供開發(fā)人員足夠的自由度以構建應用，同時制定軟件開發(fā)規(guī)范以確保開發(fā)質量。

低代碼開發(fā)平臺—減輕技術債務的好工具

為了更加有效地減輕技術債務，企業(yè)可以在每次變更模塊時使用自動化測試對每項代碼的改動進行多輪調試；通過建立強制文檔化等健全的代碼結構流程；將程序員安排成兩人一組，使他們可以了解彼此的決策；使用項目管理工具可視化團隊中每個人的工作狀態(tài)等。

此外，使用低代碼和無代碼工具編寫的軟件日益增加。由于流程圖和拖放技術能以可視化的方式呈現(xiàn)邏輯和預期結果，因此這些軟件很大程度上實現(xiàn)了自動歸檔。此外，所生成的代碼可以按原計劃運行，也可以出于自定義或性能目的進行修改，開發(fā)經理應該鼓勵團隊使用低代碼和無代碼技術，以提高生產效率。