工程质量-03-理论原则
15 Jan 2022 • 2 min read在后面的文章中，我们将质量体系的建立分为三个阶段，一步一步的迭代加强某一个方面，最终建立起我们的整个体系。这么做是有一些内在的理论逻辑的。可能您并不会完全赞成后面某一些阶段的某一些做法，但是读懂这些流程设计的背后逻辑，这样您可以会根据自己的情况测试更适合您的流程。
3.1. 团队合作
产品研发是一个集体活动，需要避免个人英雄主义的出现。无论一个人觉得自己有多么牛，自己地位多么高，他输出的东西都应该虚心的接受团队其它成员的审查和建议。
我们后面会强调一些流程和规范，它们存在最重要的意义就是让其他人能够以合理的方式参与进来，贡献他的力量。一个人再牛，他的输出也是有限的，只有将一个团队的力量发挥出来，产品才可能更高效的完成研发。
在Google最新出版的《Software Engineering at Google》[5] 提到，在管理Google这群最优秀的工程师中，经常会遇到有一些工程师会想闭关修炼，憋个大招，横空出世，一鸣惊人。(本小节下面的内容大部分出自[5])
真正的天才是通过团队合作诞生的结果
人类有发现偶像，并且崇拜偶像的本能。在计算机的历史上的确出现过一些英雄式的人物。比如林纳斯·本纳第克特·托瓦兹(Linus Torvalds)、吉多·范罗苏姆(Guido van Rossum)、比尔·盖茨(Bill Gates)他们就在计算机软件历史上做出非常重要的贡献。
但是Linux是林纳斯·本纳第克特·托瓦兹(Linus Torvalds)一个人写的么？Linus做的事情仅仅是写了第一个概念验证版本的Unix-Like版本的内核，并且通过邮件将它发了出来进行了共享，当然这也是一个非常厉害的工作。但这仅仅是整个工程中的一小部分，Linux内核的功能现在已经是当初的几百倍的大小了，这些是由上千个非常聪明的人一起贡献出来的工作。Linus真正最重要的贡献是领导了这些人，并且让他们在一起协同工作。Linux已经早已经不是当初Linus的成果了，而是整个Linux社区的成果。
同样的是吉多·范罗苏姆(Guido van Rossum)写了整个Python么？的确是他写了python的第一个版本。但是成百上千的工程师接着他的工作才推动了python的持续发展，包括迭代版本、改进相关的功能、修复BUG等等。Steve Jobs领导了团队建立了Macintosh系统。Bill Gates使用家用电脑写了第一个BASIC的解释器，但是他最大的贡献是建立了微软这个成功的商业公司。这些人的成功都是因为他们成为了一个好的团队领导者。他们被神话是因为人类的一种需求，即我们人类需要将团队的成功归因于一个人/领导者。
是的，程序员都希望自己的天才，像英雄一样力挽狂澜。但是即使你是天才也远远不够，天才也会出错，天才拥有卓越的想法和高超的编程技能也不能够保证能够完全实现这个想法。有可能你会发现，你现在的技术仅仅只能够实现一个最粗糙的版本。真正的天才是通过团队合作来实现自己的想法的。
团队合作才是正道，不要将所有的工作放到一个天才身上，我们需要想办法让整个团队的人参与进来，才能够保证这个项目更加平稳的发展。
3.2 变主观为客观
在整个质量体系中，有很多以人为中心的审查流程。比如代码审查、方案审查等等。但是依靠人来审查的流程有一个很重要的问题是人的输出不是稳定。
- 人有状态：可能一个人的状态比较好，所以这一个方案审查起来效果很不错。但是如果一个人状态不好，那么审查的质量就很有堪忧了。
- 人有侧重：人的审查很多时间是带有一定的人物特色的。有一些人特别容易看出某一类型的问题，而另一些人容易看出其它类型的问题，还不稳定[4][8]。
- 人有情绪：人与人之间的关系比较复杂，有时候审查者给的意见带有情绪，并不是真正的意见。而被审查者有时候也认为有人故意找事，可能并不会认真对待这样的审查。
当然，我们也有一系列科学的方法来尽量规避因为人的因素带来的不稳定的效率。比如在审查过程中建立一系列的审查规则，按照固定的步骤和内容一步一步的审查。比如可以让更多的人参与审查，这样能够尽可能规避个人的偏差带来的影响。比如我们可以让人匿名审查，这样可以尽量规避人与人之间情绪上面的影响。
这些方法其实揭示了一个基本的原则，我们希望让人来审查的时候，抛弃主观的一些判断，能够尽量客观的进行评审。
人的问题只能够尽量避免。所以在质量体系的建立过程中，不能够完全依赖于人，但凡有一点可能性，我们都应该将人的工作交给机器自动来完成。
比如，我们后续的流程有方案审查、代码审查，这些都需要人为的参与。但是在这之间，我们可以尽可能的引入一些工具来自动化检查某一些方面。比如一些静态的代码缺陷扫描工具来规避一些固定代码的问题。使用代码风格自动检查工具来自动检查代码风格问题。比如使用单元测试、自动功能测试来验证必要的逻辑问题。通过这些自动化的工具的辅助，让人只检查那些自动化无法完成的部分。
在质量体系中，我们需要确保的是下限。人的审查如果效率高是能够提高上限的，但是效率不好，就完全保证不了下限。但是固定的自动化流程就可以保证下限。
3.3. 以人为本，长期坚持
我们前面虽然在强调在避免人的主观判断，会建立很多流程。但是研发依然是一个以人为核心的工作。设计各种质量保证流程的目标，并不是为了让研发成为一条固定的生产线，无论谁来了，按部就班就可以完成工作，保证质量。产品研发要有这么容易，软件行业早就这么干了。
工程质量的改进，重要的目标是让参与的人的素质提高，这是一个关于人的问题。如果一个人养成一个新的习惯需要21天，那么一个团队养成一个统一的习惯需要更久。我们后面会讲到代码审查、单元测试这些流程。虽然有一些最佳实践和规范。但是每一个行业，每一个项目的情况都不一样，要做好这些，还是需要参与的人来慢慢体会，学习，总结。
这是重点，以人为本，培养人比流程更重要。
另外，您当前的团队一定已经有了一个输出的效率和质量了，不管它现在怎么样，反正它已经存在了，相互合作的团队也感受到了。这种情况下，如果质量提升很慢，甚至没有提升，并不会产生特别大的问题。但是如果因为想要突然提升质量，引入了很多流程，造成了开发的效率降低，质量提升又不能够立竿见影，那这就成了问题了。
所以，这是另一个非常重要的原则：不要急，科学系统的改进团队工程质量需要时间。
- 个人需要时间来学习消化，形成习惯：如果我们根据我们团队的情况设计了一系列的规则，要让这些规则能够执行下去，核心是依赖于在这个团队里面的人。而学习、理解、消化是需要时间的，养成习惯更需要时间。
- 团队成员之间需要时间来磨合，减少冲突：质量体系建立的主要活动是人与人之间的交流。这里面涉及到不同的人对同一件事情都不同的理解，不同的人要求又不一样。所以整个团队需要在不断的实践中来达成默契，形成一致，这也需要时间。
- 质量改进的反馈周期很长，需要时间来量化：质量的改进并不是立竿见影的，质量的提升反馈周期有时非常长，这也是我们为什么特别容易放弃质量的一个很重要的原因，它太不可见了，也太难被量化了。所以我们想凭着一腔热血一下想把质量升到很高，但是反馈周期太长了，这一点会特点打击积极性。所以不能够操之过急。
- 团队需要时间来明确真正影响质量的问题，制定出适合自己的改进规则：
- 您的团队目前处于什么样的质量水平，影响您团队质量最重要的因素是什么，优先解决哪些重要紧急的流程？这需要你在产品迭代中不断思考，才能够回答。这需要时间。
- Google公开了他们自己内部的工程师最佳实践的文档《Google Engineering Practices Documentation》，我们能够按照他的要求直接应用到我们团队里面么？可以是可以，但是一定很难达到Google的效果。这份文档是Google根据自己的实际经验总结出来的，但是我们每一个团队组成的人都不一样，团队成员之间的水平不一样，信任度不一样，每一个团队所处于的业务压力都不一样。这个世界没有一套完全符合自己团队的通用规范，所有符合自己的规则需要自己去探索，而且它也不是一成不变的，需要随着团队的发展不断的演进，这需要时间。
我下面推荐的一些流程，根本目前的估计，想要真正应用到团队中来。最少需要跟随三次版本迭代才能够见到效果。最快至少需要半年，正常情况下至少需要一年才能够见到成效
引用
- [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.