临时代码、可持续代码以及二者之间的一切

有些代码经过良好的测试和重构，而且要长久存在下去。有些代码打算在几天内就抛弃掉。在这两个极端之间，有很多灰色地带。人们在开发处于灰色地带的代码时，打算稍后做清理，却从未完成。

William Pietri从开发人员和业务人员的两个角度，分析了代码的相关成本。在William看来，代码可以分为3种类别：

• 临时的——开发的代码打算在短时间内抛弃掉。
• 可持续的——打算长久存在的代码，经过团队的良好重构和理解，还经过有力的单元测试，并且易于维护。
• 半途而废的——一切都没有完成。临时的快速修复从未得到修复，成为永远的麻烦。匆忙之作。

William提出：故事中有一部分很有趣。在开发人员和业务人员之间，对于代码相关的成本感觉不同。他给出了下面的比较：

	业务人员	开发人员
临时的	低	低
可持续的	高	中
半途而废的	中	高

因此，利益干系人最喜欢半途而废的选择，因为成本不高，而且仍能交付他们想要的价值。这是非常严重的错误。William认为，比较代码成本，要看长期成本和短期成本，而不是看角色。他提出：

	短期成本	长期成本
临时的	低	低
可持续的	高	中
半途而废的	中	高

长期来看，半途而废的代码成本要高得多，而且会伤害业务。另一方面，尽管可持续的代码也许在开始时看起来成本高昂，但最终，经过长期运转后，可以说是“物美价廉”。

当然，那对开发人员来说不算糟糕，受影响的是公司整体。如果公司在软件方面的成本不断增加，对于在软件开发方法方面深思熟虑而且规范严谨的竞争对手来说，他们将会获得强有力的竞争优势。

Alex Chaffee评论了上面三个分类，同时指出：在他看来，可持续的代码＝测试＋半途而废的代码＋重构。Chris Sterling同样同意William的看法，他说：

过高业务期望值＋工程人员的弱势反弹＝高昂的技术债务，并导致工程方面的糟糕表现

Alberto Gutierrez做出类似分析，提出看待代码的不同机制。他基于简单性和可扩展性，将代码的打分设定为从A到F。简单性定义了代码理解和阅读的难易程度。可扩展性定义了向现有代码中加入功能的难易程度。A至F的范围定义了从最出色的代码到必须重新来过的代码这两个极端。

分析再次指出一个事实：最好的代码是既简单又可扩展的。这又映射到了William提出的可持续的代码种类。

那么，如何避免处于灰色地带？

在William看来，要让利益干系人知道：代码在长期的表现能够帮助团队交付业务价值。这也有助于团队避免技术债务的陷阱。一旦人们了解了这一点，那就更容易区分可持续的代码和处于中间阶段的代码。

很多项目就像我见过的一样，是半途而废的代码，却像可持续的代码那样得以销售。这很危险，就像牛仔程序员一样，他们冲进来拯救危机，离开时剩下很多半途而废的代码，让别人去解决。

查看英文原文： Temporary Code, Sustainable Code and Everything in Between