开发高质量的软件要付出什么样的代价？

点击蓝色“程序猿DD”关注我

回复“资源”获取独家整理的学习资料！

技术债务是 Cruft 的一个常见的比喻。添加功能的额外成本就跟支付利息一样。清理 Cruft 就像偿还本金一样。虽然这一比喻很有用，但它确实鼓励许多人相信，与实际情况相比，Cruft 更容易测量和控制。

我的改变也会影响到未来。我可能找到了一个快速加入这个功能的方法，但这与程序的模块化结构背道而驰，如此一来这就增加了 Cruft。如果我选择这条路的话，那么我今天就可以让它加快速度，但在未来的几周或几个月里，我会让其他所有必须处理这段代码的人都放慢速度。一旦团队中的其他成员做出相同的决定，一个易于修改的应用程序就会快速累积到每个微小的更改都要花费数周时间的地步。

5客户确实关心新功能的快速发展

这里我们看到了内部质量对用户和客户很重要的线索。更好的内部质量使得添加新功能变得更容易，因此开发速度更快，售价也更便宜。Rebecca 和我各自编写的应用程序现在可能有同样功能，但在接下来的几个月里，Rebeca 由于她编写的程序内部质量之高，得以能够做到每周添加新功能；而我却被卡住了，一直在努力突破瓶颈，就为了推出一个新功能。我无法与 Rebecca 的开发速度竞争，很快，她的软件就比我的软件功能强大得多，然后我所有的客户都卸载了我的应用程序，转而购买 Rebecca 的应用程序，即使她提高售价也在所不惜。

6可视化内部质量的影响

内部质量的基本作用是降低未来变更的成本。但是编写优秀的软件需要额外的努力，而这在短期内确实会带来一些成本。

可视化的一种方法是使用如下图的伪图，其中我绘制了软件的累积功能与生成它的时间（以及成本）的关系。对于大多数软件来讲，曲线看起来如下图所显示的那样。

这就是槽糕的内部质量所造成的后果。最初进展很快，但随着时间的推移，添加新功能变得越来越困难。即使进行很小的更改也需要程序员理解大量的代码，而这些代码很难理解。当他们进行更改时，会发生意想不到的破坏，导致测试时间过长以及出现需要修复的缺陷。

而专注于提高内部质量就是为了减少生产率的下降。事实上，有些产品会产生相反的效果，开发人员可以通过利用先前的工作轻松构建新的功能，从而加快开发速度。但这种令人愉悦的情况很罕见，因为它需要一支技术娴熟、训练有素的团队才能实现这一目标。但我们偶尔也会看到这一情况。

这里的微妙之处在于，有一段时期，内部质量较低的产品比内部质量较高的产品的生产力更高。在此期间，质量和成本之间存在某种权衡。当然，问题是，在两条曲线发生交叉之前，这段时间有多长br>

在这一点上，我们遇到一个问题，为什么这是一个伪图。我们没有办法去衡量软件团队交付的功能。由于无法衡量产出，因而也就无法衡量生产率，因此无法对内部质量较低造成的后果（这也很难衡量）给出确切的数字。无法对产出进行衡量在专业工作中相当普遍：我们该如何衡量律师或医生的生产力/p>

我评估曲线交叉的方法是征求我所知道的熟练开发人员的意见。然而，答案让很多人感到惊讶。开发人员发现，质量很差的代码在几周内就会出现显著降低开发速度的现象。所以，在内部质量和成本之间能够进行权衡的地方并没有多少。即使是很小的软件开发工作也会从对良好的软件实践的关注中受益，当然，这是从我经验中所证明的这一点。

7即使是最好的团队也会制造出“Cruft”

许多非开发人员倾向于，认为只有当开发团队粗心大意并出错时才会发生这种事情。但实际上，即使是最优秀的团队也会在工作时不可避免地制造出“Cruft”。

我喜欢用一则我和最好的技术团队领导聊天的故事来说明这一点。他刚刚完成了一个被普遍认为是非常成功的项目。客户对教辅的系统感到非常满意，无论是功能方面，还是构建时间和成本方面。我们的员工对这个项目的工作经验持肯定态度。技术主管也非常高兴，但也承认系统的架构并不是太好。我的反应是“这怎么可能可是我们最好的架构师之一啊！”，他的回答是任何有经验的软件架构师都很熟悉的：“我们做出了很好的决策，但直到现在才明白应该如何进行构建”。

许多人，包括软件行业的一些人，将构建软件比作建造大教堂或摩天大楼，毕竟，我们为什么要用“架构师”来称呼高级程序员呢构建软件存在于充满不确定性的世界，而这一世界不为物理世界所知。软件的客户只对产品需要什么功能有一个粗略的概念，并随着软件的构建了解更多的信息：特别是早期版本发布给他们的用户时。软件发开的构件：语言、库和平台，每隔几年就会发生重大的变化。在物理世界中，类似的情况是，一旦一半的建筑物建成并被占用，客户通常会添加新的楼层，并改变楼层平面图，而混凝土的基本性能每隔一年就会发生变化。

鉴于存在这种程度的变化，软件项目总是创造一些新颖的东西。我们几乎从未发现自己在处理一个以前已经解决过的、大家都能理解的问题，当我们构建解决方案的过程中，我们对这个问题了解得最多，因此，我常常听到团队只有在花了一年左右的时间去构建软件之后，才能真正理解软件的架构应该是什么。即使是最好的团队，他们的软件也会出现“Cruft”。

不同之处在，最好的团队创造出来的“Cruft”，但也消除了足够多的“Cruft”，这样，他们就可以继续快速添加功能。他们花费时间创建自动化测试，以便能够快速发现问题，并花更少的时间来消除 Bug。他们经常进行重构，这样他们就可以在 Cruft 积累到足以碍手碍脚之前就清除掉。由于团队成员是在不同目的上的工作，持续集成可以最大限度地减少 Cruft 的出现。一种常见的比喻是，这就好比清理厨房的台面和设备。要知道，在你做饭的时候，你不可能不把东西弄脏，对吧。但如果你不赶快把东西清理干净的话，那脏东西就会变干，这样就很难清理，所有的张东西都会妨碍你烹制下一道菜。

Dora 对精英团队的研究表明，质量和速度之间的选择，并非软件开发中唯一具有至关意义的选择，但这却是错误的。还有一种强烈的观点认为，在快速开发（如系统的频繁更新）和在生产中不会中断的可靠系统之间，存在双模选择（Bi Modal）。其实这是一个错误的选择，这点在《State of Dev Ops Repot》中严谨的科学研究中得到了证实。

几年来，他们一直使用调差的统计分析来梳理高效软件团队的实践。他们的工作表明，精英软件团队每天多次更新产品代码，在不到一个小时的时间内，即可完成将代码从开发状态更改为生产状态。当他们这样做时，他们更改失败率明显低于低效团队，因此他们从错误中恢复的速度要快得多。此外，这些精英软件交付组织与更高的组织绩效相关。

8高质量的软件生产成本更低

综上所述：

• 忽视内部质量，会导致 Cruft 快速形成。

• 这种 Cruft 降低了功能开发的速度。

• 即使是优秀团队也会制造出 Cruft，但通过保持较高的内部质量，就可以使它处于受控状态。

• 较高的内部质量使 Cruft 降至最低，使团队能够以更少的工作量、时间和成本来添加功能。

遗憾的是，软件开发人员通常并不能很好地解释这种情况。我曾无数次与开发团队交谈过，他们说，“他们（管理层）不会让我们编写出高质量的代码，因为这需要花费太多的时间。”开发人员通常需要通过适当的专业性来证明对质量的关注是合理的。但是，这种道德主义的观点暗示这种质量是以牺牲他们的观点为代价的——注定他们的观点会失败。令人讨厌的是，由此产生的粗制滥造的代码不仅让开发人员的日子更难过，也给客户带来了金钱上的损失。在考虑内部质量时，我强调我们只应该讲它作为一个经济论点来看待。较高的内部质量降低了未来功能的开发成本，这意味着花时间编写优秀的代码实际上就是降低了成本。

原文链接： https://martinfowler.com/articles/is-quality-worth-cost.html

推荐阅读

• 7月编程语言排行榜来了，为什么不同媒体 道的结果不一样/span>

• 装x撩m必备的16条Linux 命令，了解一下/span>

• 使用 Optional 摆脱 NullPointException 的折磨

• 史上最易懂的Kubernetes儿童插图指南

• 要想下班早件少不了！

群讨论

前段时间推了一个保险讲座的广告，结果很多朋友还来私聊我关于保险方面的一些建议，甚至还有要直接拷贝我目前购买方案的（感谢大家的信任）。就个人而言，之前在购买保险的时候确实做了非常多的功课，但是主要还是基于个人情况去考虑的（收入结构，家庭情况等），另外小编家里因为有癌症的家族史，所以在在购买上都会有不同的偏向性，没有具体哪一款最好，还是要多看多交流，找到最适合自己的再下手！基于以上目的，所以建了个保险交流群。只需要添加微信：zyc_enjoy，发暗 ”保险交流“，加入讨论群（纯交流，广告勿加）。同时，我还给大家准备了一份超详细的重疾产品横向对比表给大家参考！

签到计划

活动介绍：自律到极致-人生才精致：第10期

活动奖励：《Spring 5企业级开发实战》、我的星球会员

扫描下面二维码签到参与

关注我，加个星标，不忘签到哦~

2019

与大家聊聊技术人的斜杠生活

点一点“阅读原文”小惊喜在等你