程式設計中的惡業。什麼是技術債以及如何解決它

技術債。大多數積極從事其專業工作的程式設計師都必須處理這個術語。對於許多人來說，提及它甚至會引起頭痛，以及每當您在專案中處理技術債時就會出現身體其他部位的不適。 因此，今天我們將討論技術債（TD）：它是什麼、它是如何出現的、技術債有哪些類型以及如何有效地管理它。

什麼是技術債？

不過，首先讓我們了解一下術語。技術債是一種軟體工程隱喻，指的是因為忽視軟體開發品質而在軟體程式碼或架構中累積的問題，並在未來造成額外的勞動成本。這是維基百科給出的技術債的定義。簡單地說，技術債是在開發中應用簡化和短期解決方案的結果，這導致後續改進的金錢和時間成本不斷增加（當然，除非債務被「償還」），重寫程式碼或以現有形式維護產品。在普通程式設計師的世界裡，技術債是一種負面業力，一種負面因素和悲傷的根源，它是對糟糕程式碼的報應，使用拐杖和「臨時」（但實際上不是很好）的解決方案有助於解決短期問題並「賒帳」地加快發展，即以犧牲未來日益複雜的問題為代價。在IT產業，技術債是一個相當嚴重的問題。根據最近的一項研究，世界各地的公司每年僅花費超過 850 億美元來修復不良代碼。每年總共約有 3000 億美元花費在與支援過時系統和「不良」軟體相關的項目上。這些都是重要的數字。研究人員估計，如果所有處理技術債及其後果的開發人員的努力重新集中在「正確」的開發上，那麼在當前十年中，全球 GDP 將會增加約 3 兆美元。

出現原因

應該理解的是，技術債務並不總是壞事，就像陷入金融債務可能是積極的，例如，如果您貸款來發展業務（或創辦新創公司）。就 TD 而言，這對於快速成長的公司來說是可以接受的，這些公司需要快速且頻繁地發布新產品或服務，以評估其成功並研究市場需求，或快速佔領新的利基市場。但是，與金融債務一樣，您需要小心技術債務並知道如何管理它，否則可能會出現嚴重的問題。軟體產品開發過程中累積的技術債越多，對公司的影響就越大，減慢新版本的發布速度，降低負責「維持」此類債務的普通程式設計師的士氣，並增加成本，最終甚至會毀掉公司。技術債發生的原因，除了盡快完成產品或以新版本取悅用戶的崇高願望之外，往往是產品管理不善、不切實際的截止日期或資源限制，當然還有編碼人員的懶惰加上資質低下以及缺乏對關鍵發展原則的理解，也往往助長債務的成長。經常發生的情況是，開發人員本身很清楚技術債的存在和不斷增長，但沒有足夠的權力來改變它，或者無法向管理層傳達有關此類問題的存在以及解決該問題的重要性的信息。

分類

如上所述，技術債有多種不同的形式，由於定義本身只是一個比喻，不同類型的技術債可以有不同的分類方式。尤其是被認為是全球技術債專家之一的Tapad聯合創始人兼CTO Dag Liodden，在年度CTO高峰會活動的演講中提出將技術債分為三大類。

1. 故意的技術債。

   它出現在開發人員故意選擇不是最佳解決方案的情況下，因為實施起來更容易、更快，這反過來又有助於快速向市場發布新產品。

   「有時我們故意承擔技術債以減少開發時間。如果您決定走這條路，不僅要考慮在開發過程中節省的時間，還要考慮以後「還清」此類債務所需的時間。此外，還要確保利益相關者（公司高層管理人員）意識到這樣的決定將不可避免地減慢未來其他功能的推出，」Dag Ljodden 說。

   解決此類技術債的方法

   專家建議仔細記錄此類案例，以便在技術債務消失之前返回並糾正它們，成為專案結構的組成部分。

2. 意外的或由過時的專案架構產生的技術債。

   此外，由於創建專案架構階段的錯誤和缺陷，技術債通常會隨著時間的推移而出現。隨著系統的發展和軟體需求的變化，設計錯誤變得更加明顯，增加新功能需要更多的時間和精力。初始專案架構的品質在這裡起著重要作用——它應該既簡單又實用，這樣才更容易適應變化。

   解決此類技術債的方法

   為了防止此類技術債務累積且不超過臨界水平，Dag Llodden 建議在系統處於穩定狀態期間定期進行重構 - 大約每兩年一次。團隊領導和產品經理必須分配時間來「償還」由於專案的架構和頻繁變化的需求而產生的這種技術債。

3. 隨著時間的推移而產生的技術債。

   專家稱這種技術債是「長期腐爛的」。隨著時間的推移，由於不斷添加許多更改，組件或系統逐漸變得更加複雜，它會隨著時間的推移而累積。如果不同的人在不同的階段處理系統並且不完全理解原始架構，情況往往會變得更糟。

   解決此類技術債的方法

   專家表示，這是您應該透過定期重構持續避免的三種技術債中的唯一一種。理想情況下，開發團隊應該花時間徹底了解他們正在開發的系統的架構，即使它最初是由其他人創建的。了解該系統將使您能夠逐步改進和糾正錯誤的程式碼，而不會讓專案陷入「腐爛」的階段。

技術債管理解決方案

有效管理技術債的選擇有很多，但所有專家都認為必須這樣做，因為技術債幾乎是所有開發的一個組成部分，而那些忽視它的公司總是會在後期面臨問題。以下是一些管理開發團隊技術債的有效解決方案和方法。

1. 分配固定百分比的工作時間來處理技術債。

   關於技術債的問題是，除非您有目的地這樣做，否則永遠沒有時間消除它（因為總是有更高優先順序的任務）。因此，一個好的解決方案是為這些目的分配一定固定百分比的工作時間—大約 20-25%。

   這可以透過不同的方式來完成。

2. 每週 1 天處理技術債

   Если выделять на работу над устранением ТД всей командой один день в неделю, это How раз будет около 20% от общего рабочего времени. Для некоторых команд такой подход работает просто отлично и, говорят, даже повышает мораль, ведь в этот конкретный день недели вся команда занимается решением проблем, которые достают их все остальное время разработки.

3. Посвящать работе над ТД каждую четвертую задачу

   Такая система подходит тем командам, которые склонны разделять работу над проектом на примерно равномерные по времени и усorям для их выполнения задачи. Если один из каждых четырех тасков посвящать “выплате” ТД, это будет занимать около четверти всего времени разработки. А введение такого подхода в качестве правила позволит убедиться, что codeеры не будут откладывать технический долг “на потом”.

4. Переходящая роль

   Еще одним подходом к проблеме устранения технического долга будет назначать на данную задачу разных членов команды поочередно, чтобы равномерно распределить эту порой далеко не самую приятную работу среди членов коллектива. Количество разработчиков, назначенных заниматься “разгребанием” ТД, может быть разным — для команды из 4-5 человек будет достаточно одного, тогда How коллективы побольше могут назначать двух-трех. Но суть остается прежней — на работу над ТД должно уходить около 20-25% всех ресурсов и человеко-часов.

5. Правило бойскаутов.

   Правило бойскаутов состоит в том, чтобы всегда оставлять туристический лагерь (стоянку для палаток) в лучшем состоянии, чем он был до их прихода, то есть убирать даже тот мусор, который был оставлен не ими. Этот принцип, How выяснor заокеанские codeеры, отлично подходит и для управления техническим долгом. Согласно данному правилу, все члены команды должны заниматься исправлением ТД каждый раз, когда сталкиваются с ним в том or ином виде. Конечно, это правило нужно применять разумно, чтобы время, которое уходит на исправление ТД, не превышало “разумные” 25-30% от общих временных ресурсов.

6. Приоритизация “дорогого” технического долга

   Также эксперты в массе своей рекомендуют не забывать о том, что технический долг может различаться в том числе и по важности. Далеко не каждый тип ТД требует немедленного устранения, поэтому важно работать над классификацией разных видов технического долга и приоритезацией работы с ними соответственно. Проще говоря, прежде всего закрывать надо те долги, которые оказывают прямое влияние на speed разработки продукта, будучи частью его базовой архитектуры. Такие долги являются самыми опасными, потому что ведут к появлению новых долгов, которые могут расти How снежный ком.

Заключение

最後，我想再次強調，軟體開發中不可能沒有技術債，因為它們本身就是開發不可或缺的一部分。然而，儘管TD具有技術性質，但它仍然是發展過程中人為因素造成的問題。儘管您無法完全沒有它，但如果您編寫“乾淨”的程式碼並盡可能負責任和專業地處理開發過程，則可以盡可能減少技術債。這就是我們對大家的祝福！