技术债务偿还计划.doc

技术债务偿还计划.doc什么是技术债务?许多团队都受技术债务困扰,不过,很少有团队能真正地设计一个计划从中挣脱出来。为了更好的理解如何才能摆脱债务,我们首先要正确地理解什么是技术债务。技术债务是由团队为了短期的项目利益故意做了欠佳的技术决策而招致的。例如,为了使一个产品更快的投放市场,团队可能不会像面对一段棘手的代码那样,编写深入的自动化测试。或者,他们可能会决定基于一个很快就会过时的框架构建项目,而不是花钱购买那个框架的一个经过升级、服务支持更好的版本。不管决策是什么,关键是要认识到,真正的技术债务是团队为了获得短期利益故意做了会招致长远债务的决策。这意味着,许多我们通常归咎于〃技术债务〃的事情实际上根本就不是债务。例如,随着系统使用年限增加,团队会无法一直保持最佳编码实践,在那种情况下出现〃位衰减(bitdotr是正常的,不是债务。或者,团队自愿做出的技术决策在随后实现时竟然发现是不正确的,这也不是技术债务。在任何一•种情况下,团队都不是为了获得短期利益而故意做了欠佳的长远决策。这种差别很重要,因为我们只有在究竟是什么组成了技术债务的问题上达成一致,我们才能针对如何减少技术债务做出最佳决策。考虑我们在无意间引入代码库的债务所带来的影响也很重要。不过,由于这类债务不是有意承担的,所以我们无法计划如何提前解决它。在这些情况下,我们一定要在发现的时候优先考虑并解决这种债务……就像团队解决新发现的Bug所做的那样。一个金融比喻我们经常将技术债务与金融债务进行对比。但是,这是一个对等的类比吗?比如,如果不首先确定何时以及如何偿还,银行其会愿意借给我们钱吗?很可能不愿意。既然不首先描述如何偿还债务,我们就确实无法借到金融资木,那么我们也就不应该以这种方式对待技术资本。这个金融比喻确实非常有效,因此,我们将对它进行更充分的讨论。偿还计划正如金融债务一样,在谈论技术债务时,我们需要确定两件事:如何偿还债务和何时偿还债务。如何偿还债务让我们以前文提到的放弃自动化测试为例。如果为了一项功能能够尽快投入生产环境,我们的团队日愿决定放弃为棘手的代码段编竺|'|动化测试,那么我们需要确定我们将如何纠正那块债务。在这种情况下,我们只需要表明,我们会在将来的某个时点I口I到这段代码,然后添加测试。不过,只表明〃我们将在稍后添加测试''并没有合理地解决这个问题。为了帮助干系人真正地了解我们的决策对招致技术债务会有多大的影响,我们需要尽我们最大的能力准确地说明等到后来添加自动化测试的影响。比如,我们应该指明需要添加测试的代码段。我们也需要明确指出,在已有的代码段上增加自动测试比在代码段创建时直接添加测试总是难度更大成木更高。最后这点很重要,因为它明确指出,将这项工作推迟到后来完成,我们实际上要比现在直接完成花更多的钱来做这项工作。换句话说,......债务是会产生利息的。在讨论完偿还方式之后,团队及其干系人可能会意识到,这个问题要比他们是否应该在编写代码时编写自动化测试更复杂。实际上,他们可能会发现,在两个极端之间,他们确实有多种更适合整个项目的选择。比如,他们可能会决定,使用类似〃圈复杂度(plexity)”这样的指标识别出新特性中最夏杂的部分是非常有意义的,并立即添加测试覆盖那些方面,而把简单一些的方面推迟。或者,他们可能会决定,像单元测试这种更简单但同时价值也更低的自动化测试类型可以立即添加,但像