高质量软件值得投入成本吗？为什么代码质量能降低软件开发成本

在软件开发项目中，人们经常会争论一个问题：时间究竟应该花在提升软件质量和代码质量上，还是应该用来发布更多有价值的功能？现实中，交付功能的压力往往占据上风。于是，许多开发者会抱怨：他们根本没有时间关注架构、内部质量和代码质量。

有一条著名的“贝特里奇标题定律”说：任何以问号结尾的标题，通常都可以用“否”来回答。熟悉我的人都知道，我一直想打破这条定律。但这篇文章还要更进一步——它要挑战这个问题本身。这个问号隐含着一个常见假设：质量与成本之间必然存在取舍。本文要说明的是，这种取舍并不适用于软件的内部质量。事实上，高质量软件的开发成本反而更低。

虽然我的大多数文章都写给专业软件开发者，但本文不会假定读者了解软件开发的具体机制。我希望这篇文章能帮助所有参与软件开发决策的人，尤其是那些作为软件开发团队客户的企业管理者。

我们为什么习惯在软件质量和开发成本之间做取舍

正如开头所说，我们早已习惯在质量和价格之间做权衡。比如更换智能手机时，我可以选择更贵的型号，获得更快的处理器、更好的屏幕和更大的存储空间；也可以放弃一些配置，以节省开支。

当然，这并非绝对。有时我们也能买到物美价廉的产品；更多时候，人们对“质量”的定义也并不相同——有些人根本感受不到屏幕素质的差别。但在大多数情况下，更高的质量通常意味着更高的价格。

软件质量包含多个层面

要讨论软件质量，首先需要说明“质量”究竟指什么。而这立刻带来了第一个难题：软件质量的内涵非常广。

例如，用户界面是一种质量：它是否能顺畅地引导我完成任务，提高效率，并减少挫败感？可靠性也是一种质量：软件是否存在会导致错误、崩溃或数据损坏的缺陷？还有一种质量体现在架构上：源代码是否被清晰地划分为模块，使程序员能够轻松找到并理解当前需要修改的那部分代码？

这三个例子远不能涵盖软件质量的全部内容，但足以说明一个重要事实：如果我是软件的客户或用户，我并不一定能感知到所有通常被称为“质量”的因素。

用户可以判断界面是否友好，管理者可以判断软件是否提升了员工效率。用户和客户也会注意到缺陷，尤其是当缺陷导致数据损坏或系统暂时不可用时。但客户和用户通常无法直接感知软件架构的好坏。

因此，我把软件质量属性分为两类：外部质量和内部质量。用户界面和缺陷属于外部质量，因为用户和客户能够直接感知；架构、模块化和代码组织方式属于内部质量，因为用户和客户无法直接判断其优劣。

乍看之下，内部质量似乎并不重要

既然内部质量对客户和用户不可见，那它真的重要吗？

假设我和丽贝卡都开发了一款用于追踪和预测航班延误的应用。我们的应用拥有相同的核心功能、同样简洁美观的界面，而且几乎没有缺陷。唯一的区别在于，丽贝卡的源代码组织得井井有条，而我的代码则混乱不堪。还有一个区别：我的应用售价 6 美元，而她的售价 10 美元。

既然客户看不到源代码，而且代码组织方式也不影响应用的实际运行，为什么会有人愿意为丽贝卡的软件多付 4 美元呢？

更一般地说，这似乎意味着：为更高的内部质量支付更多成本并不值得。

换句话说，为外部质量付费是合理的，因为用户能够判断更好的界面、更少的缺陷是否值得额外付费。但用户看不到软件内部的模块结构，更无法判断它是否更好。既然如此，为什么要为一种无法直接感知的东西付出更多成本？软件开发者又为什么要花时间和精力改善代码的内部质量？

内部质量让软件更容易改进

那么，为什么软件开发者会如此在意内部质量？

原因在于，程序员的大部分时间都花在修改代码上。即便是在一个新系统中，几乎所有编程工作也都是在既有代码库的上下文中完成的。

当我想为软件添加一个新功能时，第一步是弄清楚这个功能如何融入现有应用的运行流程。随后，我需要修改这些流程，让新功能能够顺利实现。很多时候，我还需要使用应用中已有的数据，因此必须理解这些数据代表什么、它们与周围数据之间是什么关系，以及新功能可能需要新增哪些数据。

这一切都依赖于我对现有代码的理解。

但软件很容易变得难以理解。逻辑可能错综复杂，数据流向可能难以追踪。六个月前托尼觉得某些命名理所当然，如今在我看来却像他离职的原因一样令人费解。所有这些都会形成开发者所说的“代码杂质”——也就是当前代码与理想代码之间的差距。它与人们常说的技术债类似，都会增加后续修改软件的难度。

内部质量的核心作用之一，就是让我更容易理解应用程序的工作原理，从而知道该如何添加功能。

如果软件被清晰地划分为独立模块，我就不必阅读全部 50 万行代码，而只需在少数几个模块中找到几百行关键代码。

如果团队重视清晰命名，我就能快速理解各部分代码的作用，而不必费力钻研细节。

如果数据结构合理地对应底层业务语言和业务概念，我就能轻松理解它与客服人员提出的需求之间有什么关系。

代码杂质会增加我理解变更方式所需的时间，也会增加我犯错的概率。如果我发现了错误，就需要花更多时间定位问题并修复；如果我没有发现错误，缺陷就会进入生产环境，之后仍然需要投入更多时间来修复。

我的修改也会影响未来。也许我能找到一种快速实现当前功能的方法，但它会破坏程序的模块化结构，增加代码杂质。如果我选择这条路，今天对我来说确实更快，但它会拖慢未来几周甚至几个月内所有需要处理这段代码的人。一旦团队中其他人也做出类似选择，一个原本易于修改的应用就会迅速积累大量代码杂质，以至于任何微小改动都需要耗费数周时间。

在实际研发管理中，这种理解和变更并不只发生在代码层面，也贯穿于目标制定、客户反馈收集、需求梳理、评审排期、开发、测试、发布和知识沉淀等环节。像 PingCode 这样的智能化研发管理工具，价值并不是替代高质量工程实践，而是把研发全流程中的数据、知识和协作链路串联起来，让团队更早发现流程阻塞和质量风险，从而更稳定地提升研发效能。

高代码质量能让新功能更快推出

现在我们就能看出，为什么内部质量对用户和客户同样重要。

更高的内部质量让新增功能变得更容易，也就意味着更快、更便宜。现在，我和丽贝卡的应用看起来也许差不多；但在接下来的几个月里，丽贝卡凭借出色的内部质量，可以每周持续添加新功能，而我却还在努力理清混乱的代码，最终只能勉强推出一个新功能。

我无法与丽贝卡的开发速度竞争。很快，她的软件功能就会远远超过我的。然后，我的客户会卸载我的应用，转而使用她的软件——即便她提高价格，他们也可能愿意接受。

用示意图理解内部质量对开发成本的影响

内部质量的根本作用，是降低未来变更的成本。不过，写出优秀的软件确实需要额外努力，因此在短期内似乎会带来一定成本。

我们可以用一张示意图来理解这一点：横轴代表开发时间，也可以理解为成本；纵轴代表软件累积交付的功能。对于许多软件开发项目来说，低内部质量的曲线通常是这样的：初期进展很快，但随着时间推移，新增功能变得越来越困难。即便是很小的改动，程序员也必须先理解大量晦涩难懂的代码；而一旦动手修改，又常常引发意想不到的问题，导致测试时间变长，并带来更多需要修复的缺陷。

关注内部质量的目的，就是尽量减少这种生产力下降。事实上，在一些优秀产品中，情况甚至可能相反：开发者能够复用先前工作的成果，更轻松地构建新功能，从而让开发速度越来越快。这样的理想状态并不常见，因为它需要一支技术精湛且纪律严明的团队，但我们确实偶尔能看到这样的结果。

这里有一个微妙之处：在某个短暂阶段，低内部质量可能比高内部质量显得更“高效”。在这段时间里，质量和成本似乎存在某种取舍。真正的问题是：这个阶段会持续多久？两条曲线又会在什么时候交叉？

说到这里，我们也能明白为什么这只能是一张“示意图”。软件团队交付的功能很难准确衡量。由于无法衡量产出，也就无法准确衡量生产力，因此我们很难精确量化低内部质量造成的后果——更不用说内部质量本身也难以衡量。

这种无法衡量产出的情况，在专业工作中并不少见。我们又该如何衡量律师或医生的生产力呢？

我判断这条分界线的方式，是询问我认识的优秀开发者。而他们给出的答案常常出乎许多人的意料：低质量代码会在几周之内明显拖慢他们的工作效率。

因此，内部质量和成本之间其实没有太多可取舍的空间。即便是小型软件项目，也能从良好的软件实践中受益。我的个人经验也完全印证了这一点。

即使最优秀的软件团队也会产生代码杂质

许多非开发人员倾向于认为，只有当开发团队粗心大意、犯下错误时，才会产生代码杂质。但事实并非如此。即使是最优秀的团队，在开发过程中也不可避免地会产生一些代码杂质。

我喜欢用一个故事来说明这一点。那时，我和一位非常优秀的技术负责人聊天。他刚刚完成了一个公认十分成功的项目：客户对交付的系统非常满意，无论是功能、开发周期还是成本；团队成员也普遍认为参与这个项目是一段积极的经历。

这位技术负责人总体上很满意，但也坦言系统架构并不理想。我脱口而出：“怎么会这样？你可是我们最优秀的架构师之一啊！”

他的回答，对任何经验丰富的软件架构师来说都并不陌生：“我们当时做出了正确的决策。只是直到现在，我们才真正明白当初应该如何构建它。”

许多人，包括不少软件行业人士，喜欢把软件开发比作建造大教堂或摩天大楼——毕竟，我们也把高级程序员称为“架构师”。但软件开发存在于一个高度不确定的世界中，这种不确定性远非物理建筑世界可比。

软件客户对自己需要什么功能，往往一开始只有大致想法，并且会在软件开发过程中不断加深理解——尤其是在早期版本交付给真实用户之后。与此同时，软件开发的基础设施，例如语言、库和平台，也会每隔几年发生显著变化。

如果把这种变化放到建筑行业中，就相当于客户经常在建筑已经建成并投入使用一半之后，才提出增加楼层或更改平面布局；而混凝土的基本属性还几乎每隔一年就会变化一次。

鉴于这种变化速度，软件项目几乎总是在创造新事物。我们很少面对已经被彻底解决、完全理解的问题。相反，我们对问题的大部分理解，都是在构建解决方案的过程中获得的。因此，我经常听到团队在花费一年左右时间构建软件之后，才真正明白软件架构本该是什么样子。

所以，即使是最好的团队，也难免会在软件中留下代码杂质。

区别在于，优秀团队不仅能显著减少代码杂质的产生，还能及时清理已经出现的杂质，从而持续快速地添加新功能。他们会投入时间编写自动化测试，以便快速发现问题，减少修复 bug 的时间。他们会频繁重构，在代码杂质堆积到阻碍开发之前就将其清除。持续集成则可以最大限度地减少团队成员工作方向不一致所造成的杂质积累。

对于不只关注研发流程、还需要处理跨部门协作的团队来说，Worktile 这类通用项目协作系统也能把任务、项目、文档、目标、日历、甘特图、工时和审批等信息放在统一空间中，减少信息分散带来的沟通成本，让团队更容易围绕同一目标推进工作。

一个常见的比喻是：这就像清理厨房的台面和厨具。做饭时难免会弄脏东西，但如果不及时清理，污渍会干结，变得更难清除；而这些脏东西也会妨碍你做下一道菜。

为什么高质量软件的开发成本更低

总结起来：

忽视内部质量，会导致代码杂质迅速积累。

这些杂质会拖慢新功能的开发速度。

即使是优秀团队，也会产生一定代码杂质；但通过保持较高的内部质量，可以让它始终处于可控范围内。

较高的内部质量和较少的代码杂质，能让团队以更少的精力、更短的时间和更低的成本添加功能。

遗憾的是，软件开发者通常并不擅长解释这一点。我无数次听到开发团队抱怨：“管理层不让我们写高质量代码，因为那太耗时间了。”

开发者常常用“专业精神”来说明重视质量的必要性。但这种道德化的说法暗示着：高质量是有代价的。这样一来，他们的论证从一开始就处于不利位置。

真正令人恼火的是，低质量代码最终不仅增加了开发者的工作量，也增加了客户的成本。

在讨论内部质量时，我认为我们应该从经济角度看待它。高质量的内部代码可以降低未来功能的开发成本。这意味着，花时间编写高质量代码，并不是在增加成本，而是在降低成本。

这也正是本文开头那个问题偏离重点的原因。高内部质量软件的“成本”其实是负的。

在生活中的大多数决策里，质量与成本之间确实存在取舍；但在软件内部质量上，这种逻辑并不成立。当然，对于外部质量，例如精心设计的用户体验，这种取舍仍然存在。只是对于内部质量而言，成本与质量之间的关系非常特殊，也非常反直觉，因此常常难以理解。

然而，理解这一点，对于以最高效率开发软件至关重要。