為什麼加個類似的需求，就有很複雜的開發工作？
淺談技術債
市場競爭非常地劇烈，現行的程式自動化部署五花八門，很多 buzzword 像是持續整合是持續遞交也被應用到許多軟體開發團隊上，這些人的操作技術越來越純熟，軟體也越來越精密且好用，照道理來說應該要每次都準時交付程式碼。這個時候你的專案經理（或者架構師）告訴你說：「嘿，我們的程式遇到了一點麻煩，我們可能需要花時間把這些技術債解決掉，或者之後花時間來解決。」
你也許會覺得這個經理在愚弄你，明明現行那麼多好的技術，而且市場競爭越趨激烈，沒有道理跟時間延遲交付新功能啊！
技術債名詞的起源
說到技術債，不得不提到在1992年的 Ward Cunningham 提出了「技術債」，提出這個概念其實是一種隱喻，他把程式開發比喻成一借款交易，為了優先把軟體推出到市場，我先把有問題的部分先欠著，等到下次開發時再一併解決。這種類似先欠錢買東西，日後再還錢的概念被拿到科技領域後變成了技術債的概念。
Martin Flower 針對這種求快速交付價值不顧軟體品質的情況做了以下的評論：
請注意，並不是交付的速度變快就一定等於會有技術債。
主要形成的原因
當我們深入探討技術債的形成原因時，從軟體開發過程中的多個方面工作，我們可以簡單歸納技術債的累積有這些因素：
＊越來越多功能跟構造要做
＊越來越多使用者以及程式碼
＊越來越多的文件或者彼此間的依賴關係變得非常嚴重
＊code base 越來越複雜。
隨著軟體產品的發展，客戶和市場的需求不斷變化，這迫使開發團隊不斷增加新功能和改進架構。每增加一個新功能或修改一些架構，都會對現有的系統產生影響，可能會導致程式碼的複雜性增加。如果這些變更沒有得到妥善的管理和整合，就會導致程式碼變得難以理解和維護，從而累積技術債。
又或者是你很幸運，做出的軟體產品很多人使用。而隨著使用者基數的增加，軟體必須適應更多不同的使用情境和效能要求。這表示需要寫更多的程式碼來滿足這些新的需求。隨著程式碼量的增加，系統的複雜性也隨之增加。如果這些新增的程式碼沒有遵循良好的設計原則，就會進一步增加系統的維護難度。
另外一種情境偏向團隊本身的編制以及團隊文化。團隊有沒有適度地撰寫好的文件？文件的缺失或過期且沒有維護的情況下，會使新加入的開發人員難以理解系統的工作原理，從而增加了 bug 產出的風險。或者隨著系統的擴展，各個組件之間的依賴關係變得越來越複雜，這使得進行改動時更加困難，因為改動一處可能會影響到系統的其他部分。或者是團隊是分散式的，可能彼此間修改導致錯誤的發生。
如果這些東西也沒有自動化測試保護等等，將會造成修復錯誤變得更加困難。
結語
請務必記住天下沒有白吃的午餐
控制並減少技術債，這些實踐需要整個開發團隊的共同參與和承諾。
