软件质量：不仅是工作软件，还包括精心制作的软件
短篇小说
就像其他神话一样，背后也有一个可怕的故事。 在这种情况下的故事是某个公司启动的该软件项目。 经过几个月的思考和计划，该项目的负责人终于获得了预算。 他们开始雇用人们，从这个使他们成为百万富翁的商业想法开始。
刚开始的时候只有几个人，就像每个开始一样，这是一个美好的阶段。 每个人都很高兴，而且非常上进。 团队的所有成员都在同一页面上，开发人员开始提供第一个功能，管理人员可以开始向所有人展示他们的小宝宝的第一步。
但是随着时间的流逝，项目中增加了更多的人，所有团队成员之间的交流有所减少。 老人们还是一样，但是新人们……你知道，那是不一样的感觉。 他们不完全了解产品，不了解代码，也不了解我们过去做出的某些决定。 但是不必担心，让我们给他们一些时间，他们很快就会结盟。
不久之后，团队的生产力开始下降，现在公司中的每个人都注意到了这一点。 也许是由于新员工的缘故，也可能是由于其他原因，但该业务无法达到本季度设定的目标。 开发团队没有发现任何重大问题，因此让我们给他们更多的时间，在下一个季度中，让我们在其中添加更多的资源。
下个季度的情况甚至更糟，我们将开发团队的资源增加了一倍，并且生产力降至最低。 开发团队目前几乎没有交付任何东西，他们交付的一些东西充满了错误，需要花费大量的额外时间来修复。 他们只是抱怨代码库，显然这是一场彻底的灾难。 人们不再高兴，他们对无聊的事情进行了无休止的讨论，有时甚至有激烈的争论。 但这还不是全部，最重要的是两个最有经验的开发人员（对产品了解更多的人）刚刚离开公司。 老实说，我认为其他人也在寻找公司以外的其他选择。
我们不知道发生了什么，我们没有做错任何事情。 我们一切都很好，我们都很高兴，但是突然之间一切都变得一团糟。 我们仍有业务要运行，但是软件不存在。 开发人员无法按时交付任何东西，而且每次发布任何东西到生产环境时，我们都会出汗，因为它有很多错误。 因此，我们的客户抱怨很多，其中许多已经在考虑其他选择。 我们完全失去了帮助我们成立这家公司的创新DNA，现在我们才刚刚开始。
如果您从事软件行业已有一段时间，那么很可能您已经看到或听到过类似的故事。 也许不是那么戏剧性的结局，但其余的听起来很熟悉。
案例公司或其他类似公司出了什么问题？ 为什么有一天他们醒来，发现所有事情都是一团糟的可怕真相？ 好吧，有很多因素。 开始是因为每个公司都不同，环境不同，而且所描述的问题在不同程度上受到影响……但是它们都有共同的原因：低质量的软件。
在此业务案例中，就像每个类似案例一样，开发团队专注于交付业务功能，增加业务价值，但他们完全忘记了所有技术实践。 他们逐渐增加了项目的技术负担，以便按时交付功能，就像流沙一样，开发的越多，它们的速度就越慢。 在这些情况下，向项目中添加更多的人就更糟了，因为有更多的人向堆中添加̶c̶r̶*̶p̶东西，从而使̶m̶u̶d̶雪球变得更快。
不要以为这只会在老式的瀑布项目中发生，在敏捷项目中也会发生，甚至更常见。 在瀑布式项目中，可能是错误的，但至少在项目开始时就已设计了一切。 在敏捷中，我们通常不会将大设计的前瞻性与根本不思考的混淆。 在上述情况下，也许他们正在使用诸如看板或Scrum之类的敏捷实施，也许他们甚至按照自己的意愿进行日常站立，冲刺计划，审查和回顾，但是技术准则却不存在。 敏捷不能解决问题，敏捷可以解决问题，因此您可以对它们做出反应。
劣质软件的一些症状包括：
· 没有测试或测试不足
· 没有可靠的测试
· 没有自动测试
· 没有文档（类图，体系结构图，顺序图等）
· 安装，编译或运行复杂的软件
· 需要花很多时间才能部署（全都是手动操作）
· 有错误或已知问题
· 代码难懂
· 维持或延长费用昂贵
· 软件脆弱，不稳定或不可用
· …
如果您在项目中发现任何这些症状，请开始担心，但不要惊慌。 尽快准备应变和恢复计划。 解决这些问题的时间越晚，成本就越高。 在软件项目中，业务的步伐由开发人员决定，而不是由业务决定，业务的发展速度只能与开发人员一样快。 软件质量很重要，这是项目中每个人都应该关心或启用的东西。
什么是软件质量？
嗯，就像其他任何产品一样，我们一方面具有功能质量（这是我们对有效产品的期望），另一方面具有结构质量（即产品的制造方式）。 与其他行业的区别在于，在软件中，您可以拥有第一个而没有第二个。
篮球球应该是球形的，具有一定的大小，橙色，并带有一些黑色条纹，但是如果将其弹跳15或20次后破裂，我们可以说质量很低。 软件也会发生同样的情况，我们可以拥有一个应用程序，该应用程序可以完成预期的工作，但在内部却一团糟。 只要我们永远不必更改它，就没有问题，但是在我们必须更改任何内容的那一刻，就会出现各种问题。 但是说实话，您知道有多少个项目开发人员从未接触过代码？
软件质量神话
质量总是被认为是昂贵的东西，我们经常说，不可能同时拥有速度和高质量。 但是在软件中并非如此，这是违反直觉的，因为唯一可以保证项目速度和灵活性的是软件的高质量。
当启动质量低下的项目时，我们可以立即交付业务价值。 最初，问题不多，因为我们只有很少的开发人员，并且代码仍然很小，功能也减少了。
但是过了一会儿，随着代码库的增长，尤其是当我们向项目中添加更多人员时，速度开始放慢。 该代码不容易理解，有不同的编码样式。 只有每段代码的作者才能对每个部分有效地工作，而其余部分则无法工作，因为他们不理解。 随着时间的流逝，团队变得越来越慢。
但是高质量的软件会发生什么？ 最初，由于所有技术问题都已正确设置，因此交付的价值不高。 在这里，我们仅专注于技术方面，目前，业务价值是第二要务。 思考我们将如何构建软件以及如何交付软件。
设计的复杂性较高，但可以弥补代码的简单性。 它需要一段时间才能开始产生效果，但是正如您在图像中看到的那样，那时的速度比从未有过的速度快得多。 这条线的步伐将取决于我们的设计和架构的优良程度。 从图像中可以看出，在某个点上，有一个低质量交叉点和高质量交叉点。 不要以为这种情况是用几年或几个月的时间来衡量的，在大多数情况下，我们谈论的最可能是4到8周。
如果我们进一步延长时间线，我们会看到低质量的项目不仅没有改善，而且还在稳定减少。 另一方面，高质量的软件不仅能够保持交付价值的增长速度，而且甚至可以提高价值。 一个原因是因为如果我们有一个好的设计，我们可以在一段时间后开始重用代码段。 第二个是，我们可以在项目中增加更多的人，因为他们了解代码，因此他们的工作效率更高。 这意味着增加团队，按比例增加速度。 当质量低下时，新加入者不得不问几个月的问题，这不仅减慢了他们的速度，而且也减慢了其他帮助他们的人的速度。
良好的品质规范。
在编写代码时，有大量关于最佳实践的文献，但是如果您不知道从哪里开始，我建议您看一下极限编程（XP）的实践：
极限编程是肯特·贝克（Kent Beck）早在1996年就引入的一套行之有效的实践。它可能是结合一些敏捷过程（例如Scrum或看板）使用最多的框架。 它专注于提高软件产品的内部质量，并在短时间内不断为业务创造价值。 试试看。
总结起来，软件质量非常重要，可悲的是，它通常被忽略或直接遗忘。 与直觉相反，软件的高质量是拥有快速交付和灵活的软件产品的关键。 就像其他所有做法一样，好的做法也需要一定的学习时间。 就像学习如何骑自行车或汽车，甚至是乐器一样。 它需要一定的奉献精神和纪律才能胜任。 好的方面是，一旦获得，便永远拥有。 您可以将知识从一个项目带到另一个项目，就像更换自行车，汽车，吉他或钢琴一样。
(本文翻译自Josep Mir的文章《The Software Quality Cost Myth》，参考：https://medium.com/swlh/the-software-quality-cost-myth-6f4e182a98c)