快刀斩乱麻，DevOps让代码评审也自动起来

在Dr.Michaela Greiler的 How Code Reviews at Microsoft一文中提到，微软有140000名员工，其中44%员工是工程师。这意味着，有超过6000名的工程师同时在同一个代码库上开发Office、Visual Studio、Windows等产品。

想要确保不同子团队开发的代码能完美协作，并不是一件易事。那么，如此大的工程师规模下，微软到底是如何确保代码质量的呢？秘密在于代码评审！

微软针对900多名开发人员的调查研究表明，有36%的开发人员表示他们一天回进行多次代码评审。以天为单位和以周为单位的开发人员分别占比39%和12%，仅有13%的开发人员一周内未进行任何代码评审。

微软调查报告

（图片源自微软调查报告）

代码评审是指在软件开发过程中，对编写的代码进行系统检查和评估的过程。这是一种质量控制方法，旨在发现代码中的潜在Bug。由此可见，代码评审起到了不可忽视的重要作用，从而确保代码可以在如此大规模的开发人员内实现顺畅的协作。

一、是什么绊住了你的代码评审？

代码评审有着诸多好处，如提高代码质量、发现代码中的缺陷、知识转移等。代码评审的步骤看似很简单，只需要“提交-修改-完善”，但实际过程往往会发生一些预期之外的事情，而这些事情则会降低整个代码评审的积极性甚至可能影响团队的工作效率。

《软件工程通史》的作者卡珀斯·琼斯（Capers Jones）分析了超过12000个软件开发项目，从实验分析结果看，一般的代码评审速度约是一小时150行源代码。但对于一些关键的软件（例如安全关键系统的嵌入式软件）来说，一小时审查数百行源代码的审查速度太快，可能无法找到其中的问题。

我们不难看出，虽然代码评审对于发现潜在Bug起到了重要的作用，但也需要投入大量的时间，像业务需求不稳定、时间要求紧迫的项目，就难以进行代码评审。

代码评审的好处通常在长期和多次的实践中才能显示出来。通过代码评审，团队成员可以学习和应用更好的编码技巧和设计原则，从而提高自身的编码能力。这种个人和团队的成长需要时间和经验的积累，因此，代码评审的效果在短期内可能不容易观察到。

正是这些原因，导致不少开发人员的代码会出现“管他有几个Bug，能跑就行”的现象。长此以往，就会出现“屎山代码”导致可读性差、可维护性差等情况。

代码评审-2

（当你把代码写成一坨屎，仍然能运行时）

代码评审并不是浪费时间，代码评审一般可以找到并消除约65%的Bug，最高可以到85%。为了解决绊住代码评审的困难，越来越多的团队开始采用DevOps平台来辅助代码评审，DevOps平台提供了一种集成和协作的环境，使得代码评审过程更加高效。

代码仓库通过版本控制系统（如Git）管理代码的不同版本和变更历史。代码评审可以针对特定的代码版本进行，通过对比不同版本之间的变更，开发人员可以更好地理解代码的演变过程和改动内容。同时，代码仓库提供了一个协作平台，团队成员可以在同一个代码库中共同开发和维护代码。

静态代码分析是一种在不执行代码的情况下对代码进行测试的方法，开发人员可以通过DevOps平台管理SonarQube等静态代码分析工具，自动检测潜在的代码Bug，如空指针引用、未使用的变量等。

我们可以将代码评审纳入持续集成和持续交付过程。每当有新的代码提交时，自动触发构建、测试和评审流程。这样可以及早发现问题，并确保高质量的代码被纳入主干分支。

DevOps平台可以收集和分析代码评审的数据，提供有关代码质量和审查效率的指标和报告。这些数据可以帮助团队了解代码评审的效果，并进行持续改进。例如，通过分析代码评审的结果和Bug的修复时间，团队可以识别代码质量问题的瓶颈，并采取相应的措施进行改进。

代码评审-1

一个成熟的团队中，代码评审是整个研发流程中不可或缺的一步。我们注重代码审查的前提是一定要注重代码规范，统一的代码规范才有助于项目研发有效推进。

在此分享一下，禅道团队的代码规范原则：

通过上文，我们不难看出，DevOps在代码评审方面发挥着积极作用，能够提高代码评审的效率。禅道积极响应市场，推出了禅道DevOps平台版，这不仅仅打通了从产品、需求、项目到开发、测试、运维环节，还具有加快交付速度、提高交付质量、减少团队摩擦、实现快速反馈等优势。

禅道DevOps平台

“冰冻三尺非一日之寒，滴水石穿非一日之功”。虽然代码评审会耗费团队不少的精力和时间，但我们不能低估它的长期价值，坚持下去必然会让整个代码库、系统甚至团队更加健康。