擺脫技術債務，就是“成功的標誌”
“債務就像陷阱，進去容易，想要脫身卻很難。”
—— Josh Billings，美國著名的幽默作家
技術債務是科技行業最令人頭疼的問題，就像生活中一提到債務就會讓人感到壓力重重。擺脫債務是一件苦差事。
特別是在軟體工程中，技術債務通常指的是頗有年頭且會佔用大量工程師寶貴時間的系統。技術債務必須得到妥善地管理和維護，且應最小化。技術債務往往坐落在積壓事項的最底部，管理不善就會拖垮你。
然而，凡是技術債務就一定是這個樣子嗎？
工程組織中越來越多的人認為，技術債務應該是所有軟體開發人員工作的核心部分，積極管理技術債務不僅可以讓團隊免於被拖垮，而且還可以超越競爭對手。
這個概念最初由計算機科學家Ward Cunningham於1992年提出，指的是技術系統因構建短期解決方案而引發的一系列權衡，這些欠下的債務將來必須以工程作業的形式償還。
正如軟體開發人員 Martin Fowler 在 2003 年所描述的那樣：
根據 Stripe 2018 年的開發人員指數報告，軟體開發人員平均每週需要花費13個小時以上的時間來解決技術債務問題。現如今，隨著應用程式變得越來越複雜，管理這些債務的重要性也達到了空前的高度。Stepsize 的執行長 Alexandre Omeyer表示：“所有你認為是負債的程式碼都是技術債務。”
技術債務的形式多種多樣。InfoWorld 專欄作家 Isaac Sacolick 去年寫道：“就應用程式架構體系的底層來說，技術債務可能是一小部分需要重構的程式碼、需要升級的庫或者修復的單元測試；而從高層來看，技術債務包括重新設計複雜的單體應用程式、移植過時的 Web 服務協議、將多個平臺整合成一個標準、清理資料債務問題、現代化基礎設施、引入可觀察性實踐或自動化積壓的手動測試用例。最糟糕的技術債務型別是‘著火的平臺’，意思是說”平臺經常突發影響業務的中斷和意外。
雖然相較於與“著火的平臺”苦苦糾纏，每個人更加希望釋出閃亮的新功能，但只有團隊持續付出積極的努力來解決技術債務，開發人員才能避免長時間的痛苦。
Sacolick曾表示：“解決技術債務常常會被忽視，因為這些工作無法解決緊急的業務需求，尤其是在不怎麼緊急的情況下，投資回報率不明確，因此被認為是可以推遲的。凡是長期的維護工作都會面臨這種遭遇，無論是程式碼還是房屋。”
窺探技術債務的深淵Mik Kersten是《Project to Product》一書的作者，也是Tasktop 的創始人，他表示：“我們需要將技術債務視為首要問題，需要主動解決。然而不幸的是，對於很多人來說，這是一個新穎的概念。”
對於許多工程團隊，尤其快速發展的組織中的團隊來說，技術債務似乎與推出新功能之間似乎勢同水火。但在Honeycomb的首席技術官與聯合創始人Charity Majors來看，技術債務是“成功的標誌，它意味著你還活著。”他表示，“千里之堤毀於蟻穴，我們必須妥善處理小問題。”
雖然說起來容易，但是要想認真地對待技術債務，整個組織都需要進行文化轉變。
RedMonk 分析師 Rachel Stephens表示：“對於許多企業來說，能夠按照優先順序分配待辦事項本身就是一個挑戰，尤其是很多公司都會獎勵推出新產品，但對於管理技術債務卻沒有任何特定的基於績效的激勵措施。”
Tasktop 的 Kersten也表示：“僅對推出新功能的工作提出獎勵，就會將自己置於技術債務死亡的漩渦之中。”
如何承擔技術債務LaunchDarkly的首席技術官兼聯合創始人John Kodumal早些時候曾表示，雖然“技術債務在軟體開發中是不可避免的”，但主動減少債務總好過被堆積如山的債務壓垮並影響到其他工作。
為了能夠主動承擔技術債務，你必須將技術債務視為正常敏捷流程中的一項工作。
Sacolick 表示：“維護應用程式、避免或延緩系統進入遺留狀態的關鍵就在於，組織和團隊如何管理技術債務。”我們必須積極主動，“制定政策、約定和流程，將減少技術債務的工作視為一項長期的成本。”
許多團隊都會投入一定的人員和時間來解決技術債務，例如每個衝刺的20%。然而，Tasktop 的 Kersten 建議將專案的截止日期以及團隊的能力考慮在內，採取一種更加靈活的方法。他說：“你應該衡量業務成果和技術債務的投資，並確保二者的平衡。將技術債務擺到眼前，這樣你隨時都能看到還有多少債務需要償還。然後再設定一個目標交付百分比，當然這個比例必須隨時間動態變化。”
對於雲端儲存公司 Box 的首席技術官 Ben Kus 來說，償還技術債務必須出現在所有工程團隊的擠壓工作列表中。“當然，技術債務的償還會被推遲，但這是一項長期的任務，你必須持續投入時間和精力。”
但Kus不建議指派工程師專門解決技術債務，他表示：“千萬別這麼幹，這會迫使某些員工離職。沒有人願意成天和技術債務、程式碼重構或類似的任務打交道。”
在Box，他們會將開發的工作以及在衝刺的過程中、事後分析和值班期間湧現的問題，平均地分配給各個工程團隊。“我們有一個嚴格的事後分析流程，我們會找出有待解決的問題，以防止同樣的問題再次發生。雖然我們不會說放下手頭的一切工作，專門解決某個問題，但我們會明確表示，如果問題再次發生，就會追究責任。如果同樣的問題再次出現，那將是非常不愉快的經歷。”
輪流值守的重要性由於工程團隊希望有效地挖掘和衡量導致團隊開發速度減慢的技術債務，隨時待命變得越來越重要。
Honeycomb的Majors支援讓從事開發新功能的工程師定期輪流值守，專門負責修復bug、重構程式碼以及償還技術債務等工作。他表示：“有一個主要負責小問題的工程師很重要。工程師不應在值班期間從事產品開發工作。這樣可以增加系統開發的靈活性。”
Chris Evans 是 Incident.io 的創始人，該公司是一家專門從事應急響應的軟體初創公司。Evans告訴我們：“跟蹤並記錄一切的意義是減少那些‘不言自明’的知識。在輪流值守期間，你需要處理自己不太擅長的工作。”
雖然聽起來這項工作的壓力很大，但我們不僅可以解決問題，而且還可以在事後的分析中強調出現的問題，這樣解決技術債務的重要性也會變得更加明顯。
Evans曾在部落格文章中寫道：“承擔運營的工作可以幫助我們收緊釋出新功能與執行系統之間的反饋迴圈。這有助於我們做出務實的工程決策，並在釋出新功能和支援與改進現有功能之間保持健康的張力。”
例如，Incident.io最近遇到了這樣一個問題：他們的一個數據庫互動出了問題，導致工程團隊的開發速度減慢。Evans說：“我們投入了一週的時間，建立了一種更好的與資料庫互動的方式，這對我們將來構建每個功能都產生了一定的影響。”
類似於這樣的改進值得慶祝，就像解決了某個重大問題或釋出了某個新功能一樣，“償還技術債務的重要性不亞於贏得新客戶。”
《金融時報》對於技術債務的重新思考在過去六年中，《金融時報》一直在重塑其處理技術債務的方法。早在 2015 年，這家英國報紙網站由一款名為 Falcon 的“大而全”的應用程式搭建。2016 年，該公司的開發人員將 Falcon 轉換成了一組微服務，總稱為Next。他們的 332 個程式碼儲存庫由一組職責明確的團隊長期負責，從應用程式、內容發現和廣告到中央平臺，他們只需要負責 72 個程式碼儲存庫。
《金融時報》的客戶產品技術總監 Anna Shipman 在 4 月於倫敦舉行的 QCon 會議上表示：“大約只過了一年，我們的系統就開始出問題了。”他們的技術團隊搞不清楚整體的技術戰略，以及哪些服務歸誰管。這導致技術負債越來越多，甚至出現了“鬧鬼的森林”——沒有人願意接管的孤立程式碼庫，而且願意輪流值守的工程師數量也不斷減少。
Shipman的一位同事跟她說：“感覺這個系統不是我們的，我們根本駕馭不了。我們只是在不斷往裡塞東西。”
為了戰勝這種困境，他們付出了巨大努力重建秩序，清除“鬧鬼的森林”，接受複雜性，並有效地管理整個系統。只有明確技術棧的所有權，組織才能更有意識地對付技術債務和鬧鬼的森林”。
Shipman表示：“這項工作不同於常規的功能交付，你需要留出適當的時間，並安排專人去解決。這項工作永無止境，不是說稍微整理一下就萬事大吉。”
雖然他們沒有統一決定分出20%的工程時間來清除“鬧鬼的森林”和管理技術債務，但 Shipman 認為如今團隊能夠更好地平衡功能交付與技術債務了。
將正確的觀點傳達給高層透過上述討論，相信你已重新認識技術債務，而且也明白放慢開發的速度，持續解決技術債務的價值，但挑戰沒有到此結束。你必須將這些觀點傳達給高階管理層。
Honeycomb 的 Majors 說：“產品和工程經理所有的時間都花在增加業務價值上了，就好像更多的附加功能和點綴是唯一的價值，但有時只有整體得到提升才能獲得最大價值。”
對於工程經理來說，追求業務目標是當務之急，而技術債務常常被忽視，他們必須改變這種觀點。
eBay 的高階首席架構師 David Van Couvering 在今年早些時候的一篇部落格文章中寫道：“在與工程師交談時，我最常聽到的抱怨之一就是，他們必須不斷地開發功能，而他們使用的軟體和工具變得越來越容易出問題、缺乏統一性，非常令人沮喪，這導致完成工作的難度越來越大。”
為了將這些風險轉化為業務，就需要及時解決技術債務，讓工程師們能夠更快地工作，並確保軟體更安全。
Van Couvering表示：“為了你自己，為了你的團隊，也為了避免整個公司被技術債務拖垮，你必須學會向高層傳達正確的觀點。”
避免風險成功管理技術債務需要投入大量精力來改變根深蒂固的文化和工作方式，還需要改善工程團隊與業務團隊之間的溝通。公司應該推出相應的激勵措施，鼓勵開發人員做出改變，避免技術債務越累越高的風險。
RedMonk 分析師 Rachel Stephens 在 2017 年寫道：“你必須幫助業務夥伴瞭解到今天的決策會導致未來風險增大，技術債務必須及時得到解決。你可以談談技術債務問題對專案造成的危害，並展示如今的妥協會對今後埋下何等禍根。”
雖然閃亮的新功能會讓客戶和高管喜笑顏開，但負債累累的系統會摧毀一切，相信災後重建是任何人都不希望看到的局面。
原文地址：https://www.infoworld.com/article/3660632/you-re-thinking-about-technical-debt-all-wrong.html