“債務就像任何陷阱一樣，很容易進入，但很難擺脫。”——喬什·比林斯(美國幽默作家)

 

技術債務是科技界最討厭的術語之一。就像在生活中一樣，一提到債務就會讓人感到壓力重重。因為擺脫債務是一件苦差事。

 

具體來說，在軟件工程中，技術債務通常指的是耗盡工程師大量寶貴時間維護的老化系統。技術債務需要管理、維護和最小化。因為技術債務可能是壓倒駱駝的最后一根稻草，最終將會讓企業不堪重負。

 

但一定要這樣嗎?越來越多的行業領先的工程組織認為，技術債務應該是所有軟件開發人員工作的核心部分，通過主動管理和清除技術債務，不僅可以避免失敗，而且實際上可以超越競爭對手。

 

 

技術債務這一術語最初由計算機科學家Ward Cunningham于1992年提出，技術債務是指為技術系統構建短期解決方案會帶來一系列權衡，從而導致未來的債務必須以工程工作的形式償還。

 

正如軟件開發人員Martin F owler在2003年所描述的那樣：一些快速的做事方式給企業帶來了技術債務，這類似于金融債務。與金融債務一樣，技術債務也會產生利息，這是企業在未來發展中必須付出的額外努力。

 

根據Stripe公司在2018年發布的開發人員系數報告，軟件開發人員每周平均花費13個小時以上來解決技術債務問題。現在，隨著應用程序變得越來越復雜，管理這些技術債務從未像現在這樣重要。Stepsize公司首席執行官Alexandre Omeyer說：“任何認為是負債的代碼都是技術債務。”

 

技術債務有多種形式。行業專家Isaac Sacolick說，“在低端，它可能是需要重構的一小部分代碼、需要升級的庫或需要修復的單元測試。而在高端，技術債務包括重新設計復雜的單一應用程序、移植過時的Web服務協議、將多個平臺整合到一個標準、清理數據債務問題、基礎設施的現代化、引入可觀察性實踐或自動化積壓的人工測試用例。最糟糕的技術債務類型是一種‘燃燒的平臺’，這意味著平臺經常出現影響業務的中斷和事件。”

 

盡管開發任何被稱為“燃燒的平臺”似乎都不如推出新功能那么吸引人，但只有通過以積極和持續的方式作為一個團隊來解決技術債務，開發人員才能避免長期的痛苦。

 

Sacolick寫道：“解決技術債務往往被忽視，因為這樣做很少能解決緊急的業務需求，尤其是對于非緊急情況，投資回報率不明確，因此被認為是可以推遲的。對于涉及維護的任何事情，無論是代碼還是房屋，這都是一個經典問題。”

 

 

《產品到項目》一書的作者兼Tasktop公司創始人Mik Kersten說，“技術債務需要成為主動解決的首要問題。不幸的是，在許多情況下，這是一個新穎的概念。”

 

對于許多工程團隊，尤其是那些在快速發展的組織中的工程團隊來說，技術債務可能會讓人覺得它與推出新功能的重要工作之間存在緊張關系。但對于Honeycomb公司首席技術官和聯合創始人Charity Majors來說，技術債務本身就是成功的標志，它意味著企業還活著。

 

Majors表示，只有確保小事得到妥善處理，才能確保不會積少成多變得難以處理。

 

雖然這說起來容易，但整個組織都需要進行文化轉變但企業都需要進行文化轉變，以確保認真對待技術債務。

 

R??ed Monk公司分析師Rachel Stephens說，“對于許多企業來說，能夠有一個真正的優先待辦事項是一個挑戰，尤其是那些有動力推出新產品但沒有特定的基于績效的激勵措施的企業。這些企業同時還要管理他們的技術債務。”R??edMonk分析師RachelStephens告訴InfoWorld。

 

或者，正如Tasktop公司的Kersten所說，“僅通過激勵功能，企業就會將自己置于技術債務死亡漩渦中。”

 

 

Launch Darkly公司首席技術官兼聯合創始人John Kodumal指出，雖然技術債務在軟件開發中是不可避免的，但隨著時間的推移，主動減少債務比停止其他工作并試圖擺脫堆積如山的債務要好得多。

 

這種應對技術債務的主動方法涉及將企業可能認為是技術債務的任何事情視為要包含在正常敏捷過程中的另一項功能工作。

 

行業專家Sacolick表示，維護應用程序和避免或至少延遲遺留狀態的秘訣在于企業和團隊如何管理技術債務。關鍵是積極主動，這意味著需要制定政策、慣例和流程，并隨著時間的推移分攤減少債務的成本。

 

許多團隊會傾向于投入一定的能力來解決技術債務，例如每個sprint的20%。然而，Tasktop公司的Kersten建議采取一種更加動態的方法，考慮即將到來的截止日期或團隊能力的背景。

 

Kersten說。“你應該衡量業務成果和對技術債務的投資，并確保這些平衡。讓技術債務可見，這樣始終知道自己有了多少技術債務。一旦可見，設置目標交付百分比，該百分比必須隨時間動態變化。”

 

對于云存儲提供商Box公司的首席技術官Ben Kus來說，償還技術債務是所有工程團隊都需要在其工作中包含的內容。他說，“當然這會被推遲，但應該有一種持續的感覺，那就是一直在處理這些事情。”

 

不過，Kus并不建議指派某些工程師專注于技術債務。他說：“這可能是人才流失的根源。沒有人愿意從事技術債務或重構之類的工作。”

 

Box公司希望在sprint過程中、事后分析和待命時平均分配工程團隊的工作和表面問題。Kus說，“我們有一個嚴格的事后分析流程，我們會確定要解決的問題，以防止同樣的問題再次發生。我們并不是那么想當然地說‘放棄一切來解決問題’，但我們明確表示，如果問題再次發生，這將成為一個責任問題。如果再次發生，那將非常令人不快。”

 

 

隨著工程團隊希望有效地挖掘和衡量拖慢他們前進速度的技術債務，這種隨叫隨到的元素變得越來越重要。

 

像Honeycomb公司的Majors這樣的工程經理支持定期將工程師從特性工作中脫離出來，以便隨時待命，專注于修復、重構和自動化債務。

 

Majors說，“有一個主要負責小事的工程師很重要。作為待命的一部分，應該積極勸阻他們不要從事產品工作。這將彈性引入了一個通常很少使用的系統中。”

 

Chris Evans是Incident.io公司的創始人，該公司是一家專門從事事件響應的軟件初創公司。他說，“跟蹤事物的全部意義在于清除那些隱性知識，員工會被要求完成他不擅長處理的事情。”

 

雖然一開始這聽起來很可怕，但問題會得到解決，然后，通過強調在事件后清理或事后分析中出了什么問題，解決技術債務的重要性會變得更加明顯。

 

Evans在去年12月發表的一篇博客文章中寫道，“通過對我們所做的工作承擔運營責任，我們加快了反饋循環。這有助于做出務實的工程決策，并在發布新代碼與支持和改進我們現有的代碼之間保持健康的張力。”

 

例如，該公司工程師最近因與其中一個數據庫的交互而減慢了速度。Evans說，“通過一周的努力，我們認為可以建立一種與數據庫交互的更好方式，這將對我們未來如何構建每個功能產生復合影響。”

 

這些成功應該像解決一個重大事件一樣重要，或者開發出色的新功能一樣值得慶祝，而消除大量技術債務，就像獲得新客戶一樣重要。

 

 

英國《金融時報》在過去六年中一直在重塑其處理技術債務的方法。早在2015年，這家英國報紙的網站就由一款名為Falcon的單一應用程序提供支持。2016年，該公司的開發人員將Falcon轉換為一組微服務，現在其名稱為Next。由此產生的332個代碼存儲庫由一組具有明確職責的持久團隊管理，從應用程序、內容發現和廣告到中央平臺，僅負責72個存儲庫。

 

英國《金融時報》客戶產品技術總監Anna Shipman在4月于倫敦舉行的QCon會議上表示。在大約一年之內，事情開始變得不太順利。其開發團隊忽略了整體技術戰略以及誰擁有哪些服務。這導致了越來越多的技術債務，沒有人愿意使用孤立代碼庫，以及愿意在數小時內隨叫隨到的工程師越來越少。

 

正如Shipman的一位同事告訴她的那樣：“感覺不像我們擁有或指導這個系統。我們只是向里面塞進一些東西。”

 

企業需要清除那些技術債務并接受復雜性，以便更有效地管理它。只有當團隊對他們的技術堆棧擁有明確的所有權時，企業才能開始更有意識地清理那些技術債務。

 

Shipman說，“這不是與常規功能交付一起做的事情，而是需要適當地留出時間并安排時間去做的事情，這并不是一勞永逸的事情。”

 

雖然沒有中央授權將所有工程時間的20%分配給清除和管理技術債務，但Shipman認為其團隊現在能夠更好地平衡功能交付與技術債務。

 

 

一旦重新評估了與跨工程技術債務的關系，開發人員將了解放慢速度以持續解決技術債務的價值，但挑戰并沒有就此結束，仍然必須向企業高管傳達這種價值觀。

 

Honeycomb公司的Majors說，“產品和工程經理將他們的時間分配給增加業務價值，好像華而不實的功能是唯一的價值。”

 

解決技術債務可能是在追求業務目標時優先考慮的第一件事，但工程經理必須改變這種說法。

 

eBay公司高級首席架構師David Van Couvering在今年早些時候的一篇博客文章中寫道。 “當我與工程師溝通時，我聽到的最常見的抱怨之一是，他們覺得自己必須不斷地開發功能，而他們使用的軟件和工具變得更加脆弱、不一致和令人沮喪，他們完成工作變得越來越困難。”

 

而讓不同部門的人員了解這些脆弱系統的風險，通過強調現在清除技術債務可以使工程在未來更快地發展，確保軟件更安全。

 

Van Couvering寫道，“當清除技術債務時，企業、團隊和員工都會受益。因為它們避免了工程工作堆積可能帶來的失敗。”

 

金融時報的Shipman建議道，“其他工程師會明白這項工作的重要性。企業需要真正與業務指標聯系起來，例如周轉時間、性能和質量。”

 

 

成功管理技術債務需要付出大量努力來改變根深蒂固的企業文化和工作方式，以及改善工程團隊與業務團隊之間的溝通。開發商采取的激勵措施可能需要改變，但忽視不斷增長的技術債務的風險可能存在。

 

RedMonk公司分析師Rachel Stephens說，“如果企業專注于幫助業務伙伴了解當今的決策如何增加未來風險，那么反對技術債務的論點將會得到加強。可以展示項目中可預測性的喪失，面臨的問題將導致以后的性能下降。”

 

開發出新功能會讓客戶和高管們感到很高興，但技術債務沉重的系統會讓一切都停頓下來，因此企業需要盡力避免技術債務。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。