软件质量是否重要
概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。高质量软件的生产成本更低。这句话足以证明软件质量对于企业来说是很重要的。关于软件质量是否重要的具体内容我们将在文章中展开描述。
如果我要谈论软件质量，我需要解释它是什么。这是第一个复杂性 - 有很多事情可以算作软件的质量。我可以考虑用户界面：它是否可以轻松引导我完成我需要完成的任务，使我更有效率并消除挫折感？我可以考虑它的可靠性：它是否包含导致错误和挫折的缺陷？另一个方面是它的架构：源代码是否划分为清晰的模块，以便程序员可以轻松找到和理解他们本周需要处理的代码？
这三个质量的例子并非是详尽的清单，但它们足以说明一个重要的观点。如果我是该软件的客户或用户，我不会欣赏我们称之为质量的某些东西。用户可以判断用户界面是否良好，主管可以判断该软件是否使她的员工的工作效率更高，用户和客户会注意到缺陷，尤其是当它们损坏数据或使系统无法运行一段时间时。但是客户和用户无法感知软件的架构。
因此，我将软件质量属性分为外部 （例如 UI 和缺陷）和内部（架构）。区别在于用户和客户可以看到是什么使软件产品具有较高的外部质量，但无法区分内部质量的高低。
内部质量使软件增强更容易
为什么软件开发人员会因为内部质量而提出问题呢？
程序员大部分时间都花在修改代码上。即使在新系统中，几乎所有的编程都是在现有代码库的上下文中完成的。当我想向软件添加新功能时，我的首要任务是弄清楚该功能如何适应现有应用程序的流程。然后我需要更改该流程以让我的功能适应。我经常需要使用应用程序中已有的数据，因此我需要了解数据代表什么，它与周围数据的关系，以及我可以使用哪些数据需要为我的新功能添加。
所有这些都是关于我对现有代码的理解。但是软件很容易让人难以理解。逻辑可能会变得混乱，数据可能难以理解，用于指代事物的名称在六个月前对托尼来说可能有意义，但对我来说就像他离开公司的原因一样神秘。所有这些都是开发人员所说的cruft 的形式——当前代码与理想情况下的差异。
cruft 的一个常见比喻是技术债务，添加功能的额外成本就像支付利息，清理垃圾就像支付本金一样。虽然这是一个有用的比喻，但它确实鼓励许多人相信 cruft 比在实践中更容易测量和控制。
内部质量的主要价值之一是让我更容易弄清楚应用程序的工作原理，以便我可以了解如何添加内容。如果将软件很好地划分为单独的模块，我不必阅读所有 500,000 行代码，我可以在几个模块中快速定位到少数的几百行。如果我们全力进行清晰的命名，我可以快速了解代码的各个部分的作用，而不必费解细节。如果数据明智地遵循基础业务的语言和结构，我就可以轻松理解它与我从客户服务代表那里得到的请求之间的关系。Cruft 增加了我理解如何进行更改所需的时间，也增加了我犯错误的机会。如果我发现了我的错误，那么就会损失更多的时间，因为我必须了解错误是什么以及如何解决它。如果我没有发现它们，那么我们就会出现生产缺陷，并且以后会花更多的时间来修复问题。
我的改变也会影响未来。我可能会看到一种快速添加此功能的方法，但它与程序的模块化结构背道而驰，增加了 cruft。如果我走这条路，我今天会做得更快，但会减慢在未来几周和几个月内必须处理此代码的其他所有人的速度。一旦团队的其他成员做出同样的决定，一个易于修改的应用程序会迅速积累到每一个小的变化都需要数周的努力的地步。
客户确实关心新功能很快交付
在这里，我们看到了为什么内部质量对用户和客户很重要的线索。更好的内部质量使添加新功能更容易，因此更快、更便宜。Rebecca 和我现在可能有相同的应用程序，但在接下来的几个月里，Rebecca 的高内在质量使她每周都能添加新功能，而我却被困在尝试剔除繁琐程序，只推出一个新功能。我无法与 Rebecca 的速度相提并论，很快她的软件就比我的功能强大多了。然后我所有的客户都删除了我的应用程序，取而代之的是 Rebecca，即使她的价格更高。
可视化内部质量的影响
内部质量的根本作用是降低未来变革的成本。但是编写好的软件需要一些额外的努力，这在短期内确实会带来一些成本。
将这一点可视化的一种方法是使用以下示意图，我绘制了软件的累积功能与生成它的时间（以及成本）的关系。对于大多数软件工作，曲线看起来像这样。
这就是内部质量差的情况。最初进展很快，但随着时间的推移，添加新功能变得越来越困难。即使是很小的改动也需要程序员理解大范围的代码，那些难以理解的代码。当他们进行更改时，会发生意外损坏，导致测试时间过长和需要修复的缺陷。
专注于高内部质量是为了减少生产力的下降。事实上，一些产品看到了相反的效果，开发人员可以加快速度，因为可以通过利用以前的工作轻松构建新功能。这种愉快的情况很少见，因为它需要一支技术娴熟、纪律严明的团队才能实现。但我们偶尔会看到。
这里的微妙之处在于，有一段时间，低内在质量比高内在质量更有效率。在此期间，质量和成本之间存在某种权衡。当然，问题是：在两条线交叉之前的这段时间有多长？
这一点也是为什么这是一个示意图的原因。我们没有办法衡量软件团队交付的功能，由于无法衡量产出，因此无法衡量生产力，因此无法对低内部质量（这也难以衡量）的后果给出可靠的数字。无法衡量产出在专业工作中很常见——我们如何衡量律师或医生的生产力？
我评估线路交叉点的方法是征求我所知道的熟练开发人员的意见。而答案却出乎很多人的意料。开发人员发现低质量的代码会在几周内显著降低他们的速度。因此，内部质量和成本之间的权衡适用的跑道并不多。即使是小的软件工作也受益于对良好软件实践的关注，这当然可以从我的经验中证明。
即使是最好的团队也会创造出cruft
许多非开发人员倾向于认为 cruft 仅在开发团队粗心并犯错误时才会发生，但即使是最优秀的团队在工作时也不可避免地会产生一些 cruft。
我喜欢用我与我们最好的技术团队负责人之一聊天的故事来说明这一点。他刚刚完成了一个被广泛认为取得巨大成功的项目。客户对交付的系统感到满意，无论是在功能还是构建时间和成本方面。我们的员工对项目的工作经验持积极态度。技术负责人大体上很高兴，但承认系统的架构并不是那么好。我的反应是“这怎么可能——你是我们最好的架构师之一？” 他的回答是任何有经验的软件架构师都熟悉的：“我们做出了很好的决定，但直到现在我们才明白我们应该如何构建它”。
许多人，包括软件行业的不少人，将构建软件比作建造大教堂或摩天大楼——毕竟我们为什么要对高级程序员使用“架构师”这个职位名词？但是构建软件存在于物理世界未知的不确定性世界中。软件的客户对他们需要产品中的哪些功能只有一个粗略的想法，并在软件构建过程中了解更多信息——尤其是在向用户发布早期版本之后。软件开发的构建块——语言、库和平台——每隔几年就会发生很大的变化。现实世界中的等价物是客户通常会在建造和占用一半的建筑物后添加新楼层并更改平面图。
DORA精英团队研究
质量和速度之间的选择并不是软件开发中唯一具有直观意义的选择，这是错误的。还有一种强烈的想法表明，在快速开发、频繁更新系统和可靠的系统之间存在双模式选择，不会在生产中中断。DevOps状况报告中的细致科学工作证明这是一个错误的选择。
几年来，DORA使用调查的统计分析来梳理高绩效软件团队的实践。他们的工作表明，精英软件团队每天多次更新生产代码，在不到一个小时的时间内将代码更改从开发推向生产。当他们这样做时，他们的变更失败率明显低于速度较慢的组织，因此他们可以更快地从错误中恢复。此外，这样的精英软件交付组织与更高的组织绩效相关。
鉴于这种程度的变化，软件项目总是在创造一些新颖的东西。我们几乎从来没有发现自己在处理一个以前已经解决的很好理解的问题。自然地，我们在构建解决方案时对问题的了解最多，所以我经常听到团队只有在他们花了一年左右的时间构建软件之后才真正最了解他们的软件架构应该是什么。即使是最好的团队在他们的软件中也会有缺陷。
不同之处在于，最好的团队不仅创建的垃圾要少得多，而且还删除了足够多的他们创建的垃圾，以便他们可以继续快速添加功能。他们花时间创建自动化测试，以便他们可以快速发现问题并花更少的时间来消除错误。他们经常重构，这样他们就可以在多余的东西堆积到足以妨碍他们之前去除它。持续集成最大限度地减少了由于团队成员在不同目的下工作而造成的麻烦。一个常见的比喻是，这就像清理厨房的工作台面和设备。做饭时不能不弄脏东西，但如果不快速清洁东西，污垢就会变干，更难去除，所有脏东西都会妨碍下一道菜的烹饪。
高质量软件的生产成本更低
总结所有这些：
1、忽视内部质量会导致垃圾快速堆积；
2、这种垃圾会减慢功能开发的速度；
3、即使是一个伟大的团队也会产生垃圾，但通过保持内部质量的高，能够控制它；
4、高内部质量将杂物保持在最低限度，使团队能够以更少的精力、时间和成本添加功能。
最后，推荐我们的管理工具给大家