技術債是什麽、怎麽還？你想知道的都在這一篇文章裏了！
原創
最后编辑：李晓琳 于 2021-03-23 15:05:34
6329次查看
本篇目錄
前兩周寫了關于技術債務的文章，盡管實踐中會堆積技術債，但這個概念並不在我們的工作中頻繁出現。這篇文章就系統性講講技術債，讓大家避免知其然，不知其所以然。
1992年，沃德·坎甯安首次將技術的複雜比作爲負債。第一次發布代碼，就好比借了一筆錢。只要通過不斷重寫來償還債務，小額負債便可以加速開發。但久未償還債務會引發危險。複用馬馬虎虎的代碼，類似于負債的利息。整個部門有可能因爲松散的實現，不完全的面向對象的設計或其他諸如此類的負債而陷入窘境。
技术债务的本质是産品的结构阻碍了进步，表现出来的症状有：无法轻易重构産品以满足市场需求；组件之间的依赖性过多，体系结构不良；缺陷太多，结构不良；难以理解，难以改变。
技术债务的后果有偿还技术债务造成时间浪费，员工满意度降低带来士气低落，因解决遗留代码问题而错过优质项目造成人才流失，産品质量降低造成客户满意度下降，技术债务限制创新能力、扼杀创造性等诸多问题。
技術債不單單是技術債，它就像一個垃圾堆，久而久之不處理，慢慢周圍就會産生更多的垃圾，因此産生的“破窗效應”更加是會對未來的項目環境造成很大的影響，大家也會逐漸喪失維護環境的信心。所以在討論技術債的時候不僅僅是討論技術債本身，技術債對團隊追求質量的信心、對大家維護環境整潔的積極性都會造成很大的影響。
Martin Fowler把技术债分为四个象限，如下图所示：
● 缺少過程和理解：業務人員不清楚不理解技術負債的概念，在決策時就不會考慮到其帶來的影響。
● 模塊之間解耦不夠：功能沒有模塊化，軟件柔性不夠，不足適應業務變化的要求。
● 缺少配套的自動化測試：導致鼓勵快速而風險很大的“創可貼”式的BUG修複。
● 缺少必要文檔：需求和代碼都沒有必要的支撐性文檔或注釋。
● 缺少協作：組織中的知識共享和業務效率較低，或者初級開發者缺少必要的指導。
● 重構延遲：在開發的過程中，某些部分的代碼會變得難以控制，這時候就需要進行重構，以適應將來的需求變化。重構越是推遲，這些已有的代碼被使用的越多，形成的技術負債就越多，直到重構完成。
● 不遵循標准或最佳實踐：忽略了已有的業界標准、框架、技術和最佳實踐。
● 缺少相關技能：開發人員有時候技能缺失，並不知道如何編寫優雅的代碼。
償還技術債時應遵循如下原則：
1）確定已知技術債必須還。
2）發現偶然技術債，立即還。
3）每個沖刺確定一定數量的已知技術債作爲目標技術債，在當前沖刺中償還。
4）无需偿还的技术债是行将就木的産品、一次性原型和短命産品。
旧资产和老方法也往往充斥着安全漏洞，难以集成和自动化，并且很可能不再更新。 Beevers指出：“寻找人才来管理基于复杂或过时的代码构建的遗留应用程序也是一个日益严峻的难题。坚持采用过时技术不仅会消耗宝贵的预算，而且还会阻碍公司创新和保持竞争力的能力。”
敏捷方法认识到项目在生命周期中从未真正完成过，并且也从来都不是完美的。“同时，敏捷方法专注于……针对能力和质量的简化了的开发”，Dodd说。重要功能往往要频繁地开发，测试并投入生产。敏捷团队可能不会发布软件的“全面（Big Bang）”方法，而是每年发布几次重大升级。Dodd指出：“这可以使産品保持相当平稳的发展，还可以帮助用户避免重大的中断事件。”
代碼規範是代碼集體所有權的基礎，會讓結對編程更容易實行，對團隊來說更易內部輪崗、獲得晉升。代碼規範和代碼質量工具有助于發現代碼質量方面的技術債務。
亡羊補牢，爲時未晚。從現在開始把償還技術債務納入backlog，把避免産生技債務作爲工作准則，相信不會出現被技術債務壓垮崩潰的情況。
一、技術債是什麽
技术负债（英语：Technical debt），又译技术债，也称为设计负债（design debt）、代码负债（code debt），是编程及软件工程中的借鉴了财务债务的系统隐喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。1992年，沃德·坎甯安首次將技術的複雜比作爲負債。第一次發布代碼，就好比借了一筆錢。只要通過不斷重寫來償還債務，小額負債便可以加速開發。但久未償還債務會引發危險。複用馬馬虎虎的代碼，類似于負債的利息。整個部門有可能因爲松散的實現，不完全的面向對象的設計或其他諸如此類的負債而陷入窘境。
二、技術債表現
技术债与其他债务本身一样，是一种透支行为，通过牺牲未来来满足当下的一些需求。也跟其他债务一样，技术债务也有利息，而且随着时间利滚利，会成为埋在项目里的定时炸弹。如果産品长期的可持续的发展，那么技术债的重要性是毋庸置疑的。技术债务的本质是産品的结构阻碍了进步，表现出来的症状有：无法轻易重构産品以满足市场需求；组件之间的依赖性过多，体系结构不良；缺陷太多，结构不良；难以理解，难以改变。
技术债务的后果有偿还技术债务造成时间浪费，员工满意度降低带来士气低落，因解决遗留代码问题而错过优质项目造成人才流失，産品质量降低造成客户满意度下降，技术债务限制创新能力、扼杀创造性等诸多问题。
技術債不單單是技術債，它就像一個垃圾堆，久而久之不處理，慢慢周圍就會産生更多的垃圾，因此産生的“破窗效應”更加是會對未來的項目環境造成很大的影響，大家也會逐漸喪失維護環境的信心。所以在討論技術債的時候不僅僅是討論技術債本身，技術債對團隊追求質量的信心、對大家維護環境整潔的積極性都會造成很大的影響。
Martin Fowler把技术债分为四个象限，如下图所示：
三、技術債産生的原因
● 業務壓力：爲了滿足業務的快速要求，在必要的修改並沒有完成時就匆匆發布，這些未完成的修改就形成了技術負債。● 缺少過程和理解：業務人員不清楚不理解技術負債的概念，在決策時就不會考慮到其帶來的影響。
● 模塊之間解耦不夠：功能沒有模塊化，軟件柔性不夠，不足適應業務變化的要求。
● 缺少配套的自動化測試：導致鼓勵快速而風險很大的“創可貼”式的BUG修複。
● 缺少必要文檔：需求和代碼都沒有必要的支撐性文檔或注釋。
● 缺少協作：組織中的知識共享和業務效率較低，或者初級開發者缺少必要的指導。
● 重構延遲：在開發的過程中，某些部分的代碼會變得難以控制，這時候就需要進行重構，以適應將來的需求變化。重構越是推遲，這些已有的代碼被使用的越多，形成的技術負債就越多，直到重構完成。
● 不遵循標准或最佳實踐：忽略了已有的業界標准、框架、技術和最佳實踐。
● 缺少相關技能：開發人員有時候技能缺失，並不知道如何編寫優雅的代碼。
四、如何“還債”？
1.技術債可視化
盡可能公開技術債，一開始就與團隊，利益相關方一起權衡利弊，並明確告知影響與解決方案。平等溝通，相互理解。讓技術債在業務層面、技術層面可見。
可以在组织资产负债表的财产债中新增两列：短期技术债和长期技术债。还可以用用跟踪开发速率的方式体现技术债对于産品的影响。2.不同的債要對症下藥
技術債的狀態可以分類爲偶然技術債、已知技術債和目標技術債。償還技術債時應遵循如下原則：
1）確定已知技術債必須還。
2）發現偶然技術債，立即還。
3）每個沖刺確定一定數量的已知技術債作爲目標技術債，在當前沖刺中償還。
4）无需偿还的技术债是行将就木的産品、一次性原型和短命産品。
五、如何避免“欠債”
與其後期吭哧吭哧還債填坑，不如從一開始就盡量避免欠下技術債務。
1.避免使用過時的技術
遗留应用程序、过时的技术以及不同的平台和流程可能会使组织陷入沉重的技术债务，迫使其推迟基本的现代化计划。DNS和流量管理技术提供商NS1的联合创始人兼首席执行官Kris Beevers说：“技术债务将大量金钱和宝贵的时间浪费在系统和应用程序上，而这些系统和应用程序并不是为现代企业所需的规模和速度而打造的。”旧资产和老方法也往往充斥着安全漏洞，难以集成和自动化，并且很可能不再更新。 Beevers指出：“寻找人才来管理基于复杂或过时的代码构建的遗留应用程序也是一个日益严峻的难题。坚持采用过时技术不仅会消耗宝贵的预算，而且还会阻碍公司创新和保持竞争力的能力。”
2.參考敏捷實踐
有越来越多的组织渐渐接受敏捷软件开发，这是将方法交给协作、自行组织的团队和跨职能团队的一系列方法和实践。如果这种方法得到严格应用，敏捷开发使组织可以避免技术债务，其方法是快速且以迭代的方式创建和发布新産品。Dodd说：“这一过程将新産品和新功能尽快并逐步地交到用户手中。”随着新版本的交付，各种改进和问题都得到了解决，这使技术债务的积累不太可能产生。敏捷方法认识到项目在生命周期中从未真正完成过，并且也从来都不是完美的。“同时，敏捷方法专注于……针对能力和质量的简化了的开发”，Dodd说。重要功能往往要频繁地开发，测试并投入生产。敏捷团队可能不会发布软件的“全面（Big Bang）”方法，而是每年发布几次重大升级。Dodd指出：“这可以使産品保持相当平稳的发展，还可以帮助用户避免重大的中断事件。”
3.遵循代碼規範
是否遵守了編碼規範，是否遵循最佳實踐也是影響技術債的一個方面。代碼規範在研發項目團隊中有著重要作用，團隊統一代碼規範，有助于提升代碼可讀性以及工作效率。統一的代碼規範是代碼集體所有權的基礎，會讓結對編程更容易實行，對團隊來說更易內部輪崗、獲得晉升。代碼規範和代碼質量工具有助于發現代碼質量方面的技術債務。
亡羊補牢，爲時未晚。從現在開始把償還技術債務納入backlog，把避免産生技債務作爲工作准則，相信不會出現被技術債務壓垮崩潰的情況。
技術相關
