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