工程质量-02-提供工程质量意味着什么
13 Jan 2022 • 2 min read提高软件质量是一个非常复杂且艰难的过程，需要非常强大的决心和耐性才有可能完成。支撑这些的决心和耐心的前提是要对质量的意义有一个深刻的认识。只有深刻的意识到软件质量对于一团队意味着什么，会带来什么样的收益和价值，才可能坚持得下去。
这一章节就是专门来回答这个问题：质量到底意味着什么？高质量软件的收益是什么？是需要真的花大力气投入么？
2.1. 成本下降、效率提高
2.1.1. 只有质量能够自闭环
大部分质量相关的书，都会灌输一个最基本的道理：发现问题越早，修复这个问题的成本就越底。反之，越晚发现问题，修复这个问题的成本就越高。同样的，这一篇文章首先也会强调这个观点。在《Code Complete》中，有这样的一副图，清晰的描述了这种现象[2]。
- 从纵轴来看：从需求到架构再实现，前期的流程出的问题，越晚发现，修复的代价会越来越大。
- 从横轴来看：更早期发现问题，修复的代价越小。如果已经发布了，那么修复问题成本，将会非常大。
前期投入越多，收益越大。这个理念听起来很有道理，但是做起来却很难。现代的软件工程发展已经充分的证明，快速反馈迭代才是最高效的形式。产品，研发，运营、市场形成一个周期闭环，通过快速的迭代反馈来动态适应变化的市场，动态的提升各方面能力。
要想要一次性的将战略规划、需求分析、架构设计做好非常难，投入的资源会显现很快的边际递减效应。
一个企业的战略规划、产品设计、研发能力、市场与运营能力又呈现着明显的木桶效应。哪一块比较弱，则会严重的限制其它能力的拓展。
但是与木桶效应又不一样的是。如果我们能够在上面的任何一个环节提高，同样也会对其它能力有提升作用。
站在研发的角度来讲，指望需求分析一次都很到位，指望一下就能够设计出完美的架构，基本上是不可能的，有一些能力是必须要放到大的周期中迭代演进更新。但是有一些能力却是我们研发内部自己可以闭环提升的，比如工程质量。
在研发体系内，提高输出质量，对后续的测试流程就可以形成很好的促进作用。可以让测试更加聚焦新功能测试，不需要将大部分精力花在基本的业务上面，不需要在反复出现的问题上来回折腾。测试就容易形成稳定生态系统。这样整个研发的效率就提升起来了。
研发效率的提升，可以为后面的市场和运营起到积极的推动作用。也可以进一步提升产品和战略的想象力，这样整个大闭环的效率都因此而受益。
这一篇文章不会一味的强调需求分析、架构设计很重要这些废话。这一篇文章的重点是放在我们能够在研发中更能够把握的层面。重点在实现阶段，比如代码审查、比如单元测试这些能够自闭环的流程。
这些偏后的流程并不需要对业务深刻的理解就能够做到。将这些流程做好，为软件打下一个能够快速迭代的基础。对未来的需求分析以及架构迭代演进将会是更重要的。
2.1.2. 研发的效率在于迭代
研发的效率并不完全在于某一次的版本开发，而在于可维护性。在随着项目代码量增加，后续的迭代中保持稳定的效率输出才是最重要的。如果一个项目的代码混乱，技术负债很高，那么后续的迭代会很慢，这种情况下，效率将会越来越低，至到不得不放弃，或者重构。
除此了迭代效率之外，差的软件质量也会让研发花更多的时候去修复各种各样的问题，近一步降低了效率。根据Coralogix一项统计报告数据显示[3]
- 平均而言，一个开发者每千行代码，会引入约70个BUG
- 这其中每千行代码，至少有15个BUG是在最终的客户环境中发现的
- 修复这个BUG所需要的时间是写这行代码的30倍的时间
- 75%的开发者的时间都在修复各类BUG上面
这个统计虽然非常夸张，但是认真想一想我们的日常工作，相差很远吗？当我们的产品从第一天发布开始就进入了无尽的定位修复BUG时间了，这些时间不仅仅会会吞噬后续新迭代功能开发的时间，还会占用主力的开发人员。同时为了修复这些BUG，又会引入新的BUG……
这些都是成本。上面的数据让我们很容易算一笔帐。在合理的情况下，如果我们愿意在前期质量多投入20%的精力，那么我们就有可能在后面流程上面节省40%的时间。这样，我们总体就会节省出来20%的成本。
2.2. 开发时间缩短
我们一直有一个直经验上的误区，觉得追求质量，势必需要投入更多的资源，需要更多的时间。特别是需要时间，这在很多快节奏的公司是难以接受的，他们更愿意尽快的推出一个有些问题的产品到市场上看看，然后再来做下一步市场产品决策。
快速将产品投向市场，这是一个很正常的行为。但是追求高质量的软件，一定会耗费更多的时间么？
如果上前面所说的，我们质量都是通过累人累时间给磨出来的，在这种场景下追求质量，的确是让人难以接受。
这个问题类似于读书，同样的时间，有些人很容易得到满分，而有一些人连及格都很难。这里面很多很原因，但是一个决定性的原因是学习的方法和个人的素质造成了这么大的差异。研发也是一个高度讲方法的事情。
在软件质量领域也是一样的，培养一个团队先进的质量流程方法和提高团队素质。也会让同时时间内的产品的质量有天壤之别。
NASH在1987年，通过审查50个项目近400个工作年大约300万行代码的工作得出结论。通过引入一些方法，提高软件质量并不会降低整体的开发时间[2]。IBM在20世纪70年代的早期研究中加入了审查（方案审查、代码审查）技术对涉及1000个功能点的软件项目，进行了对比，得到了如下的表[4]
可以看到
- 通过引入审查的技术，大幅度提高了软件的质量，让整体的缺陷率降低了非常多。
- 从最后的时间来看，没有使用审查之前，整体的测试使用了6.5个月。而使用了审查之后，审查虽然占用了2个月，但是测试只花了3.5个月。最终整体时间节省了1个月。
其实看软件质量相关的文章，它们也会表达同样的理念。提高质量，并不会花更多的研发时间，反而会降低研发时间。这是一个团队基本流程和习惯问题，只要使用正确的方法，同样的时间做出更高质量的软件是可以实现的。
这也是这一篇文章主要的目标，通过引入正确的流程在提高研发效率，降低开发时间的同时提高软件质量。
2.3 提高研发人员信心
在《人件》里面提到[1]：对于研发人员来说，我们通常会倾向将我们的自信与生产出的产品质量（并非产品数量）紧紧关联。（因为某一些原因，生产出大量质量马虎的产品带来的满足感很小，尽管在某些情况下需要这么做。）
如果研发人员发现自己做的东西质量并不高。这种情况下马上就会体会到一个很坑的现象：做得越多，错得越多。这会给人带来非常不好的安全感。
- 低质量的软件会让研发人员会天然的抗拒变更，害怕改变，拒绝重构。明明已经知道某一些代码已经很混乱了，但是依然不敢去重构它。因为那些代码已经在生产线上跑起来了，重构可能会带来长时间的混乱。产品和市场没有办法接受，没有必要去承受这样的压力。
- 低质量的软件会让研发找各种理由拒绝产品的正常需求，限制了产品的发展，最终伤害到市场，最终也伤害到了研发。
- 低质量的软件让研发将将宝贵的时间浪费在与产品市场扯皮、甩锅上、修复各类问题上面，一些新奇的想法和创造力，也会在这些无休止的修复问题中消耗逮尽。最终会让研发团队走向平庸，
现在行业里面流传着这样的经验之谈：编程的第一法则：如果你的代码以莫名其妙的方式运行起来了，那建议你就不要再动它了。软件质量成了这样，还讲什么效率，需求，变更、迭代呢？真是可笑而又无可奈何的嘲讽。
低质量软件带来最核心的问题是研发人员害怕去修改里面的代码逻辑，每一次添加功能胆战心惊。回到我们最初的讲的战略、产品、研发闭环上去。只有通过不断迭代改进，才是根本的解决之道。如果我们研发自己的代码已经很乱了，每一次添加新功能，每一次迭代都很麻烦。那么整个环路都会因此而阻塞
低质量软件带来的损失是很难以评估的，但它远远比上面所列的那此现象更触目惊心。软件质量是体现一个研发团队永远的追求，是一个软件研发团队的生命指标，是评估一个研发团队水平最好的量化指标。
引用
- [1] Demarco T, Lister T. 人件[M]. 3. 机械工业出版社, 2016 :22-23.
- [2] McConnell S. Code Complete[M]. 2nd ed.. Microsoft Press, 2004.
- [3] Ariel Assaraf. This is what your developers are doing 75% of the time, and this is the cost you pay[EB/OL]. 2015 https://coralogix.com/blog/this-is-what-your-developers-are-doing-75-of-the-time-and-this-is-the-cost-you-pay/.
- [4] Jones C, Bonsignour O. 软件质量经济学[M]. 1. 机械工业出版社, 2014.
- [5] Fournier C. Software Engineering at Google[M]. First Edition. United States of America:O’Reilly, 2020 :27-42.
- [6] Capers Jones. Software Defect Removal Efficiency[EB/OL]. 2011. https://www.ppi-int.com/wp-content/uploads/2021/01/Software-Defect-Removal-Efficiency.pdf.
- [7] 阿里技术. 如何选择 Git 分支模式？[EB/OL]. 2020-07-10[2022-01]. https://zhuanlan.zhihu.com/p/158463879.
- [8] P. C. Rigby and C. Bird, “Convergent contemporary software peer review practices,” in Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering. ACM, 2013, pp. 202–212.
- [9] IEEE Standard for Software Reviews and Audits, IEEE Std. 1028-2008.
- [10] T. Baum, O. Liskin, K. Niklas and K. Schneider, “A Faceted Classification Scheme for Change-Based Industrial Code Review Processes,” 2016 IEEE International Conference on Software Quality, Reliability and Security (QRS), 2016, pp. 74-85, doi: 10.1109/QRS.2016.19.
- [11] A. Porter, H. Siy, A. Mockus, and L. Votta. Understanding the sources of variation in software inspections. ACM Transactions Software Engineering Methodology, 7(1):41–79, 1998.
- [12] Baum, Tobias & Leßmann, Hendrik & Schneider, Kurt. (2017). The Choice of Code Review Process: A Survey on the State of the Practice. 111-127. 10.1007/978-3-319-69926-4_9.
- [13] Fowler M & 熊杰. 重构-改善既有代码的设计[M]. 2. 人民邮电出版社, 2010.
- [14] Khorikov V. Unit Testing-Principles, Practices, and Patterns[M]. 1. Manning Publications, 2020.
- [15] Martin R C. Clean Code-A Handbook of Agile Software Craftsmanship[M]. 1. Prentice Hall, 2008.