在開發新專案過程中，必須要撰寫全程方案程式程式碼，這種程式碼是非常繁瑣的。最初引入使用的ISO9001國際認證，中國最初試用在檔案資料管理上，後逐步移植到其它事務方面，過去對這種做法一直稱為耗費錢財之舉，其實是一種分門別類的細化。完成這項工作沒有什麼捷徑可走，如果熟練自然快些，不過純國內專案可根據實際情況需要加以簡化，這樣便降低成本節約時間。

技術債務概述

技術債務是由Ward Cunningham在1992年的報告中創造的一個比喻，被定義為當我們有意或無意地做了錯誤的或不理想的技術決策所累積的債務。它和金融債務非常相似。一個人貸款了就會產生債務。如果他定期還款，那麼所建立的債務是可以接受的，不會產生進一步的問題。但是，如果他不還款，就會以利息作為懲罰，並隨著不還款次數的增加而增加。如果這個人很長一段時間不能支付任何款項，那麼應計利息使得他更難以償還債務。在極端情況下，該人不得不宣佈自己破產。

同樣地，當一個人採用一個非最優或次優技術決定，他就引入了技術債務。如果不及時糾正，該決定將影響其它相關技術的決定，債務開始上升。在很長一段時間未償還累計的技術債務的情況下，軟體越來越難以改變，在極端情況下，軟體產品變得在技術上已經破產（即在規定的時間引入一個可靠地變化是不可行的）。這種情況往往會導致專案終止。

為什麼軟體從業者意識到技術債務很重要？為什麼一定要避免引入它？要理解這一點，讓我們先了解技術債務的組成部分。技術債務本就是本金（最原始的hack或者捷徑），而當本金不能按時償還時，就會累積利息。 利息有複合的性質：開發團隊越是忽略或推遲它，隨著時間的推移，債務變得越大。因此，是利息使得技術債務成為一個顯著問題。

巨大的技術債務影響了軟體開發團隊的生產效率，並降低他們計程車氣和積極性。技術債務不斷累積導致了惡性迴圈：巨大的技術債務降低了生產效率和團隊計程車氣;同時低生產效率使得管理者推出更多的功能並導致技術債務問題的延期，而這又進一步增加了技術債務。

技術債務是多方面的。一些突出的方面是：

產生債務：例如-程式碼重複、違反靜態工具規則和程式碼異味。

設計和架構債務：例如-設計異味、違反設計規則和違反架構規則。

測試債務：例如-缺乏測試、測試覆蓋面不足和不正確的測試設計。

文件債務：例如-沒有重大問題的文件、缺乏文件和文件過期。



技術債務的維度

一個技術債務的型別是由它產生的原因和方式來定義的。一種著名的技術債務分類如下：

戰略債務：這種型別的債務是在知情的狀況下為了戰略利益（例如首次市場發行）而產生，並長期存在。

戰術債務：這種型別的債務是在知情的情況下為了快速收益而產生，通常適用於短期。

疏忽債務：不慎產生的債務通常是在不知情的情況由於缺乏知識和意識而產生。

增量債務：定期不慎產生的債務導致增量債務。

管理技術債務

“債務是必然的！”在這個快節奏的世界，軟體開發團隊有責任迅速提供價值給客戶。在這種追求中，有各種情況團隊必須選擇快速和骯髒的解決方案。在這種情況下，採取勤奮和務實的態度處理技術債務問題是很重要的。

第一個方面的管理技術債務是“防止”技術債務積聚。它包括增加有關技術債務的軟體開發團隊的認識並在組織內引入相關流程。另一個方面管理技術債務是為了“償還”技術債務。需要有意識的努力以鑑別、優先處理和重構在實際專案的技術債務問題。讓我們在下面更詳細地討論這些方面。

防止技術債務產生

防止技術債務產生的主要方法是，使人們瞭解開發團隊存在的技術債務。開發團隊必須瞭解技術債務，它的各種方面和型別，以及債務對他們的專案的影響。他們必須具備完善的設施與程式碼質量的概念，乾淨的編碼習慣、設計嗅覺、以及如何重構它們。

理解和認識有關最佳實踐和上述概念的程度可以透過開展集中培訓，以及舉辦研討會和會議得到提升。

用人相關的流程可以幫助開發團隊避免技術債務積累。這樣的方法的典型例子是審查過程（如程式碼、設計、架構和測試審查）和架構管理（例如：以確保該程式碼符合預期的體系結構和設計）。然而，所採用的流程必須是務實的：頑固和艱難地遵循流程會阻止團隊從完全遵循它們，並在堅持的過程帶領他們尋求捷徑。

償還技術債務

通常情況下，團隊在已經積累了大量的技術債務的專案中工作。在這種情況下，忽視債務前進是不明智的，因為它可能會導致該專案技術破產。在另一方面，停止數個月不開發新功能轉而只專注於償還技術債務也是不可行和不實用的。

1.識別、記錄和追蹤債務

償還技術債務的第一步是識別並記錄現有債務。有許多工具可以用來識別各種技術債務的具體例項。此外，團隊的經驗豐富的開發人員和架構師也可以識別的債務情況。一旦確定，債務情況必須以一個合適的形式記錄下來。可以用簡單的Excel工作表或使用如Teamscale一樣強大的工具。然後，記錄的債務情況需要加以評估而且他們的狀態必須被跟蹤（團隊是否會解決這些問題，如果是，誰將會解決這些問題，何時解決）。

2.優先處理異味

並非所有的債務都是一樣的——不同型別的債務都設有不同的利率。因此，所識別的債務例項必須優先考慮用於基於以下因素重構，如債務例項對專案的潛在影響。在現實世界中的專案100%償還債務是不切實際的（事實上也不推薦）;存在一些（低優先順序）債務以保持功能開發和技術償還債務之間的平衡是可以的。

3.在每個迭代中分期償還債務

在金融領域，如果一個人有一個大的貸款（比如住房貸款），一次性償還所有債務是不可能的;但是，透過支付EMIs貸款（等同於每月分期付款）來償還債務絕度是更容易的。同樣地，專案團隊一次性償還鉅額的技術債務是不可能的;然而，以小額分期付款的形式還款——REIs（等同於分期付款）是非常可行和實用的，即努力在每次迭代中為重構留出一小部分精力。

4，激勵和獎勵員工保持品質

“人們關心的是你衡量和獎勵的事情。”如果一個軟體開發團隊的經理以團隊交付功能的數量或修復缺陷的數量為準繩衡量團隊的表現，那麼團隊將只專注於增加功能和修復缺陷。做好它和完成它同樣重要。保持高度的積極性，不僅為了開發工作的程式碼同時為了程式碼質量而獎勵隊員，這是對抗高技術債務和惡化質量的關鍵策略。

5.遵循“男孩的童子軍規則”

男孩的童子軍規則例如，“要始終保持營地比你發現它的時候更清潔”也是適用於軟體開發的：“提交的程式碼比檢出的要更好”。鼓勵團隊成員，以積極減少技術債務;例如，當他們發現了一塊為了功能增加或錯誤修復的程式碼時激勵他們重構。

6.留意可能出現的大規模的債務償還

大範圍的債務償還類似於在收到來自僱主的獎金時支付大的家庭貸款的一部分。比如說，在一次重大的發行之後，繼續大範圍尋找機會償還債務。大規模的變化，如進行架構重構，可以有助於大幅減少技術債務。另一方面，在進行這樣大規模的債務償還時需要大量的規劃和有效的溝通，以減少相關的風險。

7.平地償還債務而不是垂直地

屬於不同維度的債務例項相互影響。例如，屬於測試和設計債務的例項可能是相關的。為了使程式碼可測試（或反之亦然），改變一些設計決策是有可能的。因此，而不是試圖完全償還技術債務的一個層面，試圖償還與一個實體（一個類、檔案或元件）有聯絡的債務。

8.在某些情況下不償還債務

是的，在某些情況下，即使債務很高，也不值得償還技術債務。這些情況包括原型、證明概念的實現和即將報廢的產品產生的技術債務。此外，如果計劃為您的傳統專案遷移到一個新的技術、平臺或架構，不償還的技術債務是明智的，因為相關的債務可以在遷移過程中解決的。

謝謝邀請回答，該文章轉載自網路，它 是一個的隱喻，可以是在軟體體系結構和軟體開發中最終產生結果是差勁的程式碼。債務可以被認為是工作之前必須完成特定的工作。從演化程式碼開始，經常有需要對變化做出協調的，同時也包括其他部分的程式碼或文件，也被認為是在一些在未來必須支付的債務。

它是：

在重構中(消除重複/冗餘程式碼)，隨著時間的推移讓程式碼質量惡化。正如金融債務，這是在短期內容易做到的事情。然而隨著時間推移，有趣的是你的支付是巨大的，這些債務是有利息的，噁心的程式碼是不容易維持或修改它，已經變得重寫程式是更加可行的解決方案。所以，問題是你是否要付一點現在解決的小問題或要付出更多的時間在N個月之後，程式碼已經變成侏羅紀公園2。

技術債務的常見原因包括： 商業壓力，在所有完整的需求情況下，業務需求需要軟體提前釋出的，包括那些未完成的需求變化。 缺乏軟體過程或理解，企業對技術債務的概念是盲目的，並做出決定，而不考慮的影響。 缺乏構建鬆散耦合的元件，功能模組是硬編碼的，當業務需求發生變化時，該軟體缺乏靈活性。 缺乏測試元件，它鼓勵快速和低風險的打補丁的方式來修正Bugs。 缺少文件，其中的編碼沒有一個必要文件支援。這些支援文件代表是這項工作必須支付的債務。 缺乏協作，周圍團隊沒有共享知識從而工作效率受到影響。同時對兩個或兩個以上的程式碼分支並行開發，可能會導致成為的技術債務，因為最終工作是將合併成一個單一原始碼庫。這時可能有更多的變化需要進行隔離，債務越積越多。 推遲重構。隨著專案發展，需求變化，部分程式碼已經變得笨拙，變得必須進行重構，以應對未來的需求。重構推遲的時間越長，就需編寫更多的程式碼，更多的債務堆起來，必須花費更多支付的時間來完成重構 最近我一直在討論技術債務負面反饋。 我一直在試圖探索，在我的腦海，為什麼它會被認為是負面的，它是一種消極的東西？是什麼時候產生的想法？ 我真的不能找出為什麼它會被認為是不好的，有技術方面的債務，而不是試圖找出人們為什麼會認為這是一件壞事。所以，我會盡力透露了一些關於在現實中是什麼技術債務。 我要開始說技術債務的東西，所有的專案都有，無論是最近建立專案。 事實上，我可能會認為我們將在每天上所有的軟體專案的技術債務。 但在此之前，我想花時間去列舉並歸類為技術債務的東西。

/ / TODO 你曾經看到那些反感的程式碼，你真的無法修復，因特定時間情況下，其也涉及其當前專案的架構，將不允許你這樣做，或許它是直接很簡單的，但你沒有時間，因為接下來你將某個Sprint結束後做DEMO演示。 你用 / / TODO 在程式碼中註釋，試想在稍後階段重新審視這些問題。 你可能甚至不知道什麼時候陷入了技術債務。 甚至可以說，任何註釋的程式碼，使程式碼變成技術債務，原因是 - 該程式碼是自己太理解的和需要註釋來解釋它是什麼做的。

遺留程式碼 幾乎所有的系統在那裡構建的，他們要處理一些資料模型，你不能擺脫一些舊的模組。 處理遺留程式碼藝術是保持遺留程式碼可以工作並嘗試提取出一個反腐化層。 但是，即使這個地方，有時難做到事滴水不漏。 這樣的事情，你真的不希望在您的新模式可能引發新問題，也可能是任何東西，從一個簡單屬性錯誤名稱導致您的新模式大的概念被歪曲。 所有這些都可以被歸類為技術債務。

工作中軟體

軟體開發是在我看來，很像是在高速列車真的沒有目標，但是有鐵路岔道口，使軟體的軌跡變化。 這可能是團隊想要擁抱做事情新方式。 這可能是團隊需要的新知識，是他們以前沒有的，這將使軟體更好地向前發展。當時的一切留下都代表技術債務。他們是理想的團隊需要去Fix的，但往往由於時間關係，他們不能現在就去做。 複雜性 另一個警示標誌使我的警鐘熄滅是當發現某些東西是很難跟蹤的。 除非你傳送到月球或其他行星的太空船，我也很難相信軟體應該是很難做到理解或遵循的。 做的好，一切都應該是很簡單的。 超長的Method，大的Class有一個以上的職責，所有這些都是導致軟體的複雜性，很難讓別人明白了。 事實上，我認為寫那些程式碼的傢伙很難回到自己的複雜程式碼中。 這是一個典型的情況是團隊想有它的另一種方式，因此，應歸類為技術債務。

Bugs 那麼，什麼是Bugs。 這是有趣的是東西，不屬於個別特殊的東西。 Bugs是軟體的缺陷，功能沒有按預期工作。 當然，這可能是一個連鎖效應，多數人造成的Bugs，或發生衝突的Bugs，基於系統其他部分的技術債務。 但是，那麼你應該嘗試找出真正的問題和修復，隔離時，可以分類為技術債務。

現在該怎麼辦？ 不要跳進恐慌，只是還沒有，只是因為你實現你從一個或多個上述問題似乎遭受的專案。 我們該如何應對呢？ 好了，首先 - 是誠實的。 當涉及到一般的軟體開發和生活中，我已經取得了巨大的成功，只是實話實說。 對自己和你的團隊要誠實，說實話，不管是誰的Case，在每一天結束的時候， 你都有技術方面的債務。還好，它實際上是一件好事，這意味著該系統是不斷變化的，你作為一個開發人員是不斷變化的，而且很可能就更好為其所謂的進步。 你只需要知道技術債務，把它寫下來的地方- 不是在程式碼 ---- 是整個團隊可以看到的某個地方。 把它寫下來，在規劃過程中看一眼，這使得更加容易在後面過程，每一個開發人員心中都有實際處理的債務，需要花費的時間，而使進度漸漸向前邁進，並開始開發新的功能或修正Bugs。就個人而言，我更喜歡簡單的方式處理這個問題。 一個專案，我們開始只是把技術債務的形式化後，貼在牆壁上。 慢慢地進化到使用Trello畫板 ，並且所有的時間已經顯示在一個42英寸的螢幕。 透過這樣做，面對我們的技術債務時，不是坐在辦公室裡，而是把它在42“螢幕上顯示，使它成為焦點。 重點圍繞團隊的事情，所有的時間，保持眼睛能看到這些債務 - 慢慢償還。 另一個方面，我覺得重要的是，不僅技術債務，但一般不是使你的程式碼個性化。 它不是一個對自己的表現，它是程式碼。 該程式碼被提交到庫中，它不再是你的，但屬於整個團隊。 要有這個想法，你將永遠保持它僅僅是愚蠢的(KISS原則)，你可能會辭掉你的工作，或更糟糕的事情可能發生。 在這個意義上的程式碼不是你的寫。 如果因為任何原因，在您的團隊中，技術是一個意味深長的長期債務，你可能要考慮別的東西。 在您的解決方案中不要假裝你沒有提到的內容，只是因為它是一個意味深長的詞。 這類似任何會出現您的團隊和工作中 “恥辱牆” 一樣東西。

結論 不要讓技術債務嚇唬你，試圖避免承認的事實是技術債務。 我們每個人都有，大家都有助於它，唯一重要的事情是，它是在我們的議程上，我們需要一種方式償還。 建立您自己的債務管理計劃，無論是在你工作中的工作專案的跟蹤軟體，然後在出現於牆上或適合你的東西。 把它弄出來，在開放的，它並不可怕 - 事實上，我認為相反更可怕是不知道什麼是債務級別。

你這個問題的核心是基於控制心理的管理。

那麼，有幾個問題你可以嘗試自省：

1、你為什麼把自己定位為管理者？是崗位分配需要還是基於安全心理的效率追求？

2、為什麼不可以把崗位從業者推到管理者的位置，對自己的工作進行管理？

3、為什麼不放心他管理不好自己的工作？

4、如果他自己的工資他自己定，他的工作進度由團隊稽核，稽核質量決定他的工資福利，他會不會對自己的工作主動進行管理？

5、如果他能對自己進行管理，你還操什麼管理的心？

6、嚴重拖團隊的人員，由團隊最佳化即可。

所以，你無需識別，進行技術性授權即可；也無需管理，因為他自己的進度管理決定他的收入和晉升機會，你就輕鬆了。

管理技術債務

1、技術債務的維度

一個技術債務的型別是由它產生的原因和方式來定義的。一種著名的技術債務分類如下：

戰略債務：-這種型別的債務是在知情的狀況下為了戰略利益（例如首次市場發行）而產生，並長期存在。戰術債務：-這種型別的債務是在知情的情況下為了快速收益而產生，通常適用於短期。疏忽債務：-不慎產生的債務通常是在不知情的情況由於缺乏知識和意識而產生。增量債務：-定期不慎產生的債務導致增量債務。

在這個快節奏的世界，軟體開發團隊有責任迅速提供價值給客戶。在這種追求中，有各種情況團隊必須選擇快速和骯髒的解決方案。在這種情況下，採取勤奮和務實的態度處理技術債務問題是很重要的。

第一個方面的管理技術債務是“防止”技術債務積聚。它包括增加有關技術債務的軟體開發團隊的認識並在組織內引入相關流程。另一個方面管理技術債務是為了“償還”技術債務。需要有意識的努力以鑑別、優先處理和重構在實際專案的技術債務問題。讓我們在下面更詳細地討論這些方面。

防止技術債務產生

防止技術債務產生的主要方法是，使人們瞭解開發團隊存在的技術債務。開發團隊必須瞭解技術債務，它的各種方面和型別，以及債務對他們的專案的影響。他們必須具備完善的設施與程式碼質量的概念，乾淨的編碼習慣、設計嗅覺、以及如何重構它們。

理解和認識有關最佳實踐和上述概念的程度可以透過開展集中培訓，以及舉辦研討會和會議得到提升。

用人相關的流程可以幫助開發團隊避免技術債務積累。這樣的方法的典型例子是審查過程（如程式碼、設計、架構和測試審查）和架構管理（例如：以確保該程式碼符合預期的體系結構和設計）。然而，所採用的流程必須是務實的：頑固和艱難地遵循流程會阻止團隊從完全遵循它們，並在堅持的過程帶領他們尋求捷徑。

償還技術債務

通常情況下，團隊在已經積累了大量的技術債務的專案中工作。在這種情況下，忽視債務前進是不明智的，因為它可能會導致該專案技術破產。在另一方面，停止數個月不開發新功能轉而只專注於償還技術債務也是不可行和不實用的。

1.識別、記錄和追蹤債務

償還技術債務的第一步是識別並記錄現有債務。有許多工具可以用來識別各種技術債務[4]的具體例項。此外，團隊的經驗豐富的開發人員和架構師也可以識別的債務情況。一旦確定，債務情況必須以一個合適的形式記錄下來。可以用簡單的Excel工作表或使用如Teamscale [5]一樣強大的工具。然後，記錄的債務情況需要加以評估而且他們的狀態必須被跟蹤（團隊是否會解決這些問題，如果是，誰將會解決這些問題，何時解決）。

2.優先處理異味

並非所有的債務都是一樣的 - 不同型別的債務都設有不同的利率。因此，所識別的債務例項必須優先考慮用於基於以下因素重構，如債務例項對專案的潛在影響。在現實世界中的專案100%償還債務是不切實際的（事實上也不推薦）;存在一些（低優先順序）債務以保持功能開發和技術償還債務之間的平衡是可以的。

3.在每個迭代中分期償還債務

在金融領域，如果一個人有一個大的貸款（比如住房貸款），一次性償還所有債務是不可能的;但是，透過支付EMIs貸款（等同於每月分期付款）來償還債務絕度是更容易的。同樣地，專案團隊一次性償還鉅額的技術債務是不可能的;然而，以小額分期付款的形式還款 - REIs（等同於分期付款）是非常可行和實用的，即努力在每次迭代中為重構留出一小部分精力。

4，激勵和獎勵員工保持品質

“人們關心的是你衡量和獎勵的事情。”如果一個軟體開發團隊的經理以團隊交付功能的數量或修復缺陷的數量為準繩衡量團隊的表現，那麼團隊將只專注於增加功能和修復缺陷。做好它和完成它同樣重要。保持高度的積極性，不僅為了開發工作的程式碼同時為了程式碼質量而獎勵隊員，這是對抗高技術債務和惡化質量的關鍵策略。

5.遵循“男孩的童子軍規則”

男孩的童子軍規則例如，“要始終保持營地比你發現它的時候更清潔”也是適用於軟體開發的：“提交的程式碼比檢出的要更好”。鼓勵團隊成員，以積極減少技術債務;例如，當他們發現了一塊為了功能增加或錯誤修復的程式碼時激勵他們重構。

6.留意可能出現的大規模的債務償還

大範圍的債務償還類似於在收到來自僱主的獎金時支付大的家庭貸款的一部分。比如說，在一次重大的發行之後，繼續大範圍尋找機會償還債務。大規模的變化，如進行架構重構，可以有助於大幅減少技術債務。另一方面，在進行這樣大規模的債務償還時需要大量的規劃和有效的溝通，以減少相關的風險。

7.平地償還債務而不是垂直地

屬於不同維度的債務例項相互影響。例如，屬於測試和設計債務的例項可能是相關的。為了使程式碼可測試（或反之亦然），改變一些設計決策是有可能的。因此，而不是試圖完全償還技術債務的一個層面，試圖償還與一個實體（一個類、檔案或元件）有聯絡的債務。

8.在某些情況下不償還債務

是的，在某些情況下，即使債務很高，也不值得償還技術債務。這些情況包括原型、證明概念的實現和即將報廢的產品產生的技術債務。此外，如果計劃為您的傳統專案遷移到一個新的技術、平臺或架構，不償還的技術債務是明智的，因為相關的債務可以在遷移過程中解決的。