工程质量-01-引言

一问到怎么提高软件团队的工程质量，我们天然的会蹦出一堆方案。方案审查、代码审查、单元测试、功能测试……。如果将这些事情都做好了，工程质量显然问题不大。但真实情况是，我们大部分团队的资源是有限的。大部分时候，我们都处于疲于奔命、到处救火、各种延期的状态。这些方案审查、代码审查、单元测试听起来很美好，但是真正能够贯彻执行下去的团队，却少之又少… …

造成这种现象，有两方面的原因

• 一方面：产品和市场永远希望研发的产品能够快一点完成，无论从哪个层级或多或少都会压榨研发时间。当资源不能够增加、时间又非常紧、产品功能又不能够减少的情况下。质量就变成了唯一可以妥协的特性了，因为质量的反馈周期很长，短期内降低质量，看不出来有什么特别大的问题。如《人件》里面提到：当员工处于时间压力之下时，质量就开始被牺牲了。他们会把问题藏到脚下面，或者直接扔给产品的最终用户。[1]
• 另一方面：质量问题最重要还是一个技术问题。我们很多团队并不是争取不到时间和资源去提高质量。而是不知道如何做。
  • 方案审查：怎么写好一个方案，怎么高效评审一个方案？
  • 代码审查：代码审查的形式是怎么样的，怎么保证代码审查的质量，如果项目特别紧张的情况下，还能够坚持么？
  • 单元测试：我应该写单元测试么？功能开发的时间本来都非常紧，甚至连功能测试的时间都没有，哪里有时间去写单元测试？即使要写，我应该怎么开始？
  • 功能测试：搭建一个测试环境都很复杂了，还怎么测，测啥？

这一篇文章内所定义的工程质量主要是指的代码质量。无论你对自己领域内的业务理解有多么深刻，产品设计得多么好，架构设计得多么完美，如果代码写不好，代码管理不好，发布之后BUG不断，每一次版本迭代都鸡飞狗跳，那么最终的显现的效果都会大打折扣。

Talk is cheap. Show me the code

这一篇文章讲什么？

很多企业也研发出了很多看起来非常优秀的产品，但是从这些企业开源的一些工程里面的代码，就可以明显感受到他们的代码质量也非常一般。很多公司保持产品质量的方法完全是通过投入巨量的人力资源、通过长的时间修修补补达到的。这并不是研发能力的体现，这只是企业无可奈何的被动选择。

提高效率永远是一个研发企业的永恒追求。特别是对于一些资源本身有限，竞争比较激烈的行业和团队来说这一点更加重要。如何在有限的资源内尽可能的提高软件质量呢？在哪些流程上做建设，能够获得最大的收益？这就是这一篇文章回答的问题。

这一篇文章主要将质量体系限制在从需求分析到开发、再到测试的三个主流程之间。假设需求是正确的，我们需要的是将需求以高质量的方法完成。

需求分析->【方案】->代码开发->【版本】->软件测试

我们会提到方案审查、代码审查、单元测试… …这些具体的流程如何做。但是我们更加会侧重于描述如何在当前团队现状的情况下引入这些流程。

文章结构

这一篇文章将会通过三个阶段来逐步建立团队质量体系。全文一共分为四个部分

• 第二章、第三章、第四章：主要讲提高软件质量的意义以及引入各项流程的基本原则和理论依据。
• 第五章、第六章、第七章：将质量体系的建立划分为三个阶段，三章分别讲每一个阶段的具体内容。
• 第八章：主要做一下总结以及未来的一些演进方向

预期读者和收益

这一篇文章是为每一个关心软件质量的人写的

• 如果你的团队目前本身已经有了一套成熟的质量体系。希望这一篇文章能够带给你一些新的视角来审视当前的流程。
• 如果你的团队目前虽然有一些质量流程，但是还不够完善，或者遇到了瓶颈。希望这一篇文章能够带给你一些新的思考和建议，找到突破点。
• 如果你的团队目前还没有建立起有效的质量流程。你可以尝试一下这一篇文章的方法。
• 这一篇文章主要是写给面向TB企业的研发，面向TC互联网企业的质量观不一样。可以看看最后一章对这个话题的分析。

这一篇文章目前还处于完善阶段，后面会随着具体的实践有进一步的更新。文章最开始有一个版本更新历史，未来的更新可以关注这个版本号的变化

引用

• [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.