偿还技术债务

作者：伯克哈特·赫夫纳盖尔

对任何己投入实用的项目（也就是说，有客户在使用其产品），无论要修复缺陷，还是要添加新功能，总是必须修改产品的时候。在那点上，会面临两个可能选择：花合适时间“一次做对”或者取巧走“捷径（shortcut）”，争取尽快推出修改后的产品。

一般来说，业务相关人员（销售/市场部门和客户）希望这些修改越快越好，而开发人员和测试人员更期望能够花合适时间进行设计，实现和测试后，再交付给客户。

作为项目的架构师，必须决定怎样做更有意义，并说服决策者采纳你的意见；另外，和大多数架构设计问题一样，要对此进行权衡。如果相信系统足够稳定，那么走“脏但快速（quick and dirty）”的路线也许合适些，能将修改快速纳入产品中。这很好，但是要知道，这样做，项目将招致一些后面必须偿还的“技术债务（technical debt）”。这里所说的“偿还（repayment）”,是指假设能够回到刚开始的时候，而当时的时间和资源又都充足，以在那样的条件下会采取的方式重新进行修改。

那么，为什么修改的时候还有那么多讲究呢？这是由于“脏但快速”的修复有稳定性成本（hidden cost）。金融债务的隐性成本是所谓的“利息（interest）”，大多数使用信用卡的人都知道，信用卡债务的利息是很昂贵的。对于技术债务，它的利息表现为系统的不稳定性，以及由于临时性手段和缺乏合适的设计、文档工作和测试带来的不断攀升的维护成本。而且，和金融债务一样，在本金完全还清之前，还必须定期偿还利息。

现在，对技术债务的实际成本己有了更多了解，你可能会觉得成本很高，负担不起。但是，当面临选择究竟是让开发人员尽快完成修复，还是承受严重冲击时，通常会选择“快点修复吧”。所以，不妨承受些损失，先让修改尽快（ASAP，As Soon As Possible）加到产品中。但是，可千万不能够就此止步。

一旦修复完毕，记得安排开发人员回头去妥善修复解决，纳入下一个计划发布的版本中。这等同于在月底给信用卡还款，还清债务维持账户平衡，这样就不必付利息。这种方式，不但满足业务所需的快速变化，也可让项目免于陷入债务牢笼之中。