本文介绍了阿里巴巴在Code Review方面的实践，强调了CR在提升代码质量、统一规范、防止架构腐烂、知识分享和团队共识形成等方面的重要性。文章列举了某大厂的CR准则和原则，包括关注代码设计、功能、复杂性、测试、命名和注释等。同时，分享了阿里内部如何进行CR，如发起时机、代码行数限制和评审注意事项。最后，文章指出了避免CR流于形式的策略，并列举了实践中常见的代码问题，如重复代码、基本类型偏执和分布式锁的处理建议。
作为卓越工程文化的一部分，Code Review其实一直在进行中，只是各团队根据自身情况张驰有度，松紧可能也不一，这里简单梳理一下CR的方法和团队实践。
一、为什么要CR
-
提前发现缺陷
在CodeReview阶段发现的逻辑错误、业务理解偏差、性能隐患等时有发生，CR可以提前发现问题。 -
提高代码质量
主要体现在代码健壮性、设计合理性、代码优雅性等方面，持续CodeReview可以提升团队整体代码质量。 -
统一规范和风格
集团编码规范自不必说，对于代码风格要不要统一，可能会有不同的看法，个人观点对于风格也不强求。但代码其实不是写给自己看的，是写给下一任看的，就像经常被调侃的“程序员不喜欢写注释，更不喜欢别人不写注释”，代码风格的统一更有助于代码的可读性及继任者的快速上手。 -
防止架构腐烂
架构的维护者是谁？仅靠架构师或应用Owner是远远不够的，需要所有成员的努力，所谓人人都是架构师。架构防腐最好前置在设计阶段，但CodeReview作为对最终产出代码的检查，也算是最后一道关键工序。 -
知识分享
每一次CodeReview，都是一次知识的分享，磨合一定时间后，团队成员间会你中有我、我中有你，集百家之所长，融百家之所思。同时，业务逻辑都在代码中，团队CodeReview也是一种新人业务细节学习的途径。 -
团队共识
通过多次讨论与交流，逐步达成团队共识，特别是对架构理解和设计原则的认知，在共识的基础上团队也会更有凝聚力，特别是在较多新人加入时尤为重要。
二、他山之石
2.1 某大厂A
非常重视Code Review，基本上代码需要至少有两位以上Reviewer审核通过后，才会让你Check In。
2.1.1 代码评审准则
-
如果变更达到可以提升系统整体代码质量的程度，就可以让它们通过，即使它们可能还不完美。这是所有代码评审准则的最高原则。
-
世界上没有“完美”的代码，只有更好的代码。评审者不应该要求代码提交者在每个细节都写得很完美。评审者应该做好修改时间与修改重要性之间的权衡。
2.1.2 代码评审原则
-
以客观的技术因素与数据为准，而非个人偏好。
-
在代码样式上，遵从代码样式指南，所有代码都应与其保持一致，任何与代码样式指南不一致的观点都是个人偏好。但如果某项代码样式在指南中未提及，那就接受作者的样式。
-
任务涉及软件设计的问题，都应取决于基本设计原则，而不应由个人喜好来决定。当同时有多种可行方案时，如果作者能证明（以数据或公认的软件工程原理为依据）这些方案基本差不多，那就接受作者的选项；否则，应由标准的软件设计原则为准。
-
如果没有可用的规则，那么审核者应该让作者与当前代码库保持一致，至少不会恶化代码系统的质量。（一旦恶化代码质量，就会带来破窗效应，导致系统的代码质量逐渐下降）
2.1.3 代码审核者应该看什么
-
设计：代码是否设计良好？这种设计是否适合当前系统？
-
功能：代码实现的行为与作者的期望是否相符？代码实现的交互界面是否对用户友好？
-
复杂性：代码可以更简单吗？如果将来有其他开发者使用这段代码，他能很快理解吗？
-
测试：这段代码是否有正确的、设计良好的自动化测试？
-
命名：在为变量、类名、方法等命名时，开发者使用的名称是否清晰易懂？
-
注释：所有的注释是否都一目了然？
-
代码样式：所有的代码是否都遵循代码样式？
-
文档：开发者是否同时更新了相关文档？
2.2 某大厂B
-
在开发流程上专门有这个环节，排期会明确排进日程，比如5天开发会排2天来做代码审核，分为代码自审、交叉审核、集中审核。
-
有明确的量化指标，如8人时审核/每千行代码，8个以上非提示性有效问题/每千行代码。
2.3 某大厂C
-
推行Code Owner机制，每个代码变更必须有Code Owner审核通过才可以提交。
-
所有的一线工程师，无论职级高低，最重要的工程输出原则是“show me the code”，而Code Review是最能够反应这个客观输出的。
-
尽量让每个人的Code Review参与状况都公开透明，每个变更发送给项目合作者，及转发到小组内成员，小组内任何人都可以去Review其他人的代码。
-
明确每个人的考评和Code Review表现相关，包括Code Review输出状况及提交代码的质量等。
三、我们怎么做CR
3.1 作为代码提交者
-
发起时机：发起Code Review尽量提前，开发过程小步快跑
-
代码行数：提交Code Review的代码行数最好在400行以下。根据数据分析发现，从代码行数来看，超过400行的CR，缺陷发现率会急剧下降；从CR速度来看，超过500行/小时后，Review质量也会大大降低，一个高质量的CR最好控制在一个小时以内。
-
明确意图：编写语义明确的标题（必填）和描述（选填，可以包括背景、思路、改造点和影响面、风险等）
-
善用工具：IDEA打开编码规约实时检测，减少代码样式、编码规约等基础性问题
（阿里编码规约插件：https://github.com/alibaba/p3c/tree/master/idea-plugin）
3.2 作为代码评审者
3.2.1 评审范围
主要从两方面来评审：
-
代码逻辑
-
-
功能完整：代码实现是否满足功能需求，实现上有没有需求的理解偏差，对用户是否友好；
-
逻辑设计：是否考虑了全局设计和兼容现有业务细节，是否考虑边界条件和并发控制；
-
安全隐患：是否存在数据安全隐患及敏感信息泄漏，如越权、SQL注入、CSRF、敏感信息未脱敏等；
-
性能隐患：是否存在损害性能的隐患，如死锁、死循环、FullGC、慢SQL、缓存数据热点等；
-
测试用例：单元测试用例的验证逻辑是否有效，测试用例的代码行覆盖率和分支覆盖率
-
最低0.47元/天 解锁文章
扫一扫
2599
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
