作者：冬哥
信用卡的故事
在开始使用人生的第一张信用卡时，许多年轻人在查看他们的第一张月度账单时会有类似的反应，“什么情况！？我现在可以选择一次性全额偿还10,元，于此同时我也可以选择只支付元......？哈哈！这些‘笨蛋’是怎么做生意的？！”
最终他们当然会了解到这些“笨蛋”的经营机制......如果还不算太晚的话。
有没有想过，在你的软件产品中，类似的机制每天都在背后发挥作用。
什么是技术债务？
如果不是新入行软件开发，你很有可能听说过“技术债务”这个词。技术债务也称为设计债务或代码债务，在技术领域被广泛使用。
究竟什么是技术债务？为什么我们这样称呼它？
信息与软件技术周刊如此定义技术债务：技术债务描述了某些软件开发行为所产生的后果，这些行为有意或无意地优先考虑客户价值和/或项目限制，例如交付期限、更多的技术实施和设计考虑……从概念上讲，技术债务是金融债务的类比，有着相似的概念，例如债务水平、随着时间的推移产生的利息及其可能的后果，以及在某个时间点偿还债务的压力。
之所以称之为技术债务，是因为它就像贷款一样，你当前可以完成比正常更多的工作，但最终会付出额外的代价。
技术债务一词最初是由WardCunningham创造的，他不仅是敏捷宣言的17位作者之一，还因发明了Wiki而闻名于世。Cunningham首先用这个比喻向非技术的利益相关者解释为什么需要为重构活动预留资源。Cunningham没有意识到自己创造了一个新的流行词，此后，技术债务成为无数学术研究、辩论和企业讨论的主题。
技术债务一词的流行与它所带来的便利有关，DonaldG.Reinertsen强调采纳经济视角，技术债务的隐喻，用易懂的金融词汇描述了一个艰深但普遍存在的技术难题。与此同时，技术债务也明确的指出不完美的设计、代码的拥有成本、延误成本、长期持续的利息这几者之间的关系。
技术债务包罗万象，涵盖了从代码缺陷、架构不足、遗留代码、脚本、配置文件、基础设施，再到文档的所有层面。较为常见的代码和系统的技术债务包括：
已知的未修复缺陷
不充分的测试覆盖
低代码质量和不良设计导致的问题
不再使用但没有清理的代码/制品/功能开关
团队缺乏领域知识，无法高效调试和维护
未完成的迁移
废弃的技术
未完成或过期的文档或注释缺失
·
当你为了更快地实现目标，在编写代码时走了捷径，就会发生技术债务，代价是代码更丑、更难维护。
想象一下你有一个模块，因此前走的捷径，导致结构不够清晰导致维护和更新不便，当下新增一个功能需要6天的时间，如果结构清晰的话则只需要4天时间，那么额外增加的2天就是因为技术债务所产生的额外利息。重构这段代码也许需要10天，所以这10天就是债务的本金。是偿还10天的本金，还是持续每次背负2天的利息，这是一个技术选择，也是一个投资选择。投资的衡量来源于当下是否有本金可以偿还，这部分本金如果投资于其他领域是否可以获得更高的收益。
对技术债务的进一步分析
7年，SteveMcConnell提出有两种类型的技术债务：有意的和无意的。在他看来，有意的技术债务是人们有意识地将其作为一种战略工具来承担的技术债务。无意的债务则相反，他称之为“工作做得不好的非战略性结果”。
几年后，MartinFowler将McConnell的概念更进一步，发表了“技术债务四象限”，根据意图和上下文将技术债务分为4类。Fowler说技术债务可以首先根据意图进行分类：是有意的还是无意的？然后进一步区分是谨慎的还是鲁莽的债务。
谨慎的债务是经过深思熟虑的，因为团队知道他们正在承担债务，因此会考虑较早发布的收益是否大于还清成本。一个对设计实践一无所知的团队承担的是鲁莽的债务，甚至没有意识到自己陷入了多大的困境。
团队可能知道什么是好的设计实践，甚至能够实践它们，但决定保持“快速而肮脏”，因为他们认为负担不起编写干净代码所需的时间。这通常是一笔不计后果的债务，好的设计和干净的代码的意义在于让你走得更快更稳。
MartinFowler的技术债务分类框架并未直接匹配债务的具体性质，年一些学者提议根据技术债务的性质而不是它是否具有战略意义进行分类，由此得到13种不同类型的技术债务，每种类型都对应一组关键指标：
需求债务
架构债务
构建债务
代码债务
测试自动化债务
测试债务
缺陷债务
设计债务
文档债务
基础设施债务
人员债务
流程债务
服务债务
技术债务的是与不是
技术债务不是一团糟的代码
不良代码不属于技术债务，长期担任软件开发顾问的RobertC.Martin（俗称Bob大叔）（同时也是《代码整洁》的作者）在一篇态度鲜明的博客中写道：“一团糟不是技术债务，一团糟只是一团糟。技术债务决策是根据实际项目限制和需要做出的。它们是有风险的，但可能是有益的。弄得一团糟的决定从来都不是理性的，是基于懒惰和不专业，并且在未来没有机会获得回报。一团糟总是一种损失。”
技术债务应该是人们经过深思熟虑，决定采用长期不可持续但会产生短期收益的设计策略。核心关键是债务会更快产生价值，但需要尽快安排偿还。
技术债务不是缺陷
讨论缺陷是否是债务，是一个错误的论题。很多人误解了债务的比喻，将其与浪费混淆了，技术债务容易与缺陷混为一谈。大多数程序员会说：“好吧，我只需要在最后期限之前快速完成，稍后我会回来修复它。”很多人认为只要目的是更快的做好工作，就可以编写充满缺陷的代码，并认为这就是技术债务的主要来源。
编写糟糕的代码从来都不是什么好事，但我们赞成基于当前对问题的理解来编写代码，以尝试获得反馈进行验证，即使这种理解是片面的。明智的做法是该软件尽可能清晰地反映你当下的理解，以便在需要重构时，很清楚编写它时的想法，从而更容易将其重构为你当时的想法。换而言之，偿还债务的能力，取决于你编写的代码是否足够干净，以便在你理解问题时能够进行重构。这也是为什么鲍勃大叔的《整洁代码》和MartinFowler的《重构》一书同样的重要。
技术债务是有意而为之的
正如明智的金融债务可以帮助更快地实现主要的人生目标一样，并非所有技术债务都是坏事。管理好它可以为公司带来巨大的收益，对于快速发展的公司来说尤其如此，迫切需要尽早并经常发布以确定产品/市场契合度，满足客户需求并抓住市场机会。
技术债务描述了当开发团队采取行动以加快交付，稍后再进行功能或产品重构的场景。换句话说，这是优先考虑快速交付而不是完美代码的选择，或者说是在速度与质量之间的权衡中倾向于前者。既然是选择，就应该是有意而为之的，而非无意识或下意识的举动。
ShaunMcCormick对技术债务的定义更多地
转载请注明：http://www.0431gb208.com/sjszyzl/7839.html
