管理技术债

管理技术债2013-10-06 infoq 张卫滨技术债被广泛视为一件坏事，它应该避免或者要尽快进行偿付。

你应该这样做吗？我们并不这么认为。首先，我们对比了技术债与财务债，阐述了它与战略设计（Strategic Design）的相似性以及它的利益相关者。然后，我们列出了识别代码中技术债的各种可行的方式，这可能是你所关心的。

最后，我们描述了项目中可以偿还技术债的不同方式，并且阐述了当你在决定要偿还债务、转移债务或者只是支付利息哪个方案更好时，必须要考虑的因素。

什么是技术债

开发人员在实现新特性的时候，有两种不同的方式：一种是快速且混乱地完成，这会使得将来的变化很困难。另一种是整洁（clean）和明智的方案，它需要更长的时间来实现但是将来的变化会更为容易（亦可参见Martin Fowler）。不过，如果同一个特性以较为凌乱的方式实现时，能够具有相同的功能和较低的成本，那么项目的赞助者为什么会接受一个较高成本的整洁实现呢？他们为什么会花费金钱在自动化测试覆盖率上呢？测试不是什么特性，因此不会交付业务价值！

如果凌乱的代码和没有测试的代码能够交付期望的业务价值，对于客户来说也会运行得很好，但是这将会导致难以控制的代码基、极其专门化的开发人员并最终形成缺乏灵活性的软件产品。大量的混乱代码有可能会使得整个工程部门停滞（stand-still）。

“技术债”的比喻说法——与“财务债”的相似和不同

1992年，在与非技术的利益相关者沟通这个问题时，Ward Cunningham第一次使用了“技术债”这个比喻说法。低质量的或没有自动化测试覆盖的代码可以与财务债进行类比。这样的代码就像财务负担，它会将所有的利益相关者牵连进来——并不仅仅是开发人员——债务会导致将来要支付的利息。本金就是将代码基重构为整洁的设计所付出的代价，整洁的代码会简化将来发生的变化。如果团队将来工作在混乱的代码基之上，相对于良好的代码基所付出的的额外成本就是利息。

与财务债的不同之处在于，你不一定必须要偿还技术债。有时候将其偿清并没有太大的意义：有些代码是很少甚至从来不会阅读或修改的。因此，技术债也需要考虑发生的概率——混乱的代码将来要接触到的可能性和频率如何？另外一个与财务债的不同之处在于，偿还这个债务的人并不一定是技术债的最初创造者，而是随后维护代码基的开发人员。

类似于财务债，技术债未必是一件坏事。如果你知道如何偿付的话，举债买房也是一种负责任的行为。但是，如果明明知道无力支付账单，依然通过信用卡购买大量的奢侈品，那么通常会导致灾难性的后果。考虑到软件的技术债可能会在提前释放版本方面带来优势，并且组织从中的获益要超过偿还技术债的成本。在财务上，如果本金加利息低于投资的收益，那么举债是一件好事。对于软件来说，这依然是成立的。如果你牺牲了内部质量来获取市场第一的地位，那么相对于市场中稍微靠后的位置但是具备较好的内部质量，你需要获取更高的收益，只有这样才是值得的。但是，这里会有风险，因为很难预先估计这些收益，这里会有一定程度的不确定性。