关于CodeReview的一些思考

在日常开发中，Code Review 的重要性日益凸显。它不仅有助于提升代码质量，还促进了团队成员之间的知识共享和技能提升。本文将主要聚焦于 Code Review，分享在这个过程中的一些心得和思考。

CodeReview常用到的一些术语

之前看到公司的大佬经常说的一些codereview的术语很头大，所以先列出来，大家参考，其实还有很多，最常用的就这几个。
CR: Code Review. 请求代码审查。
PR： pull request. 拉取请求，给其他项目提交代码。
MR： merge request. 合并请求。
LGTM： Looks Good To Me.对我来说，还不错。表示认可这次PR，同意merge合并代码到远程仓库。
WIP: Work In Progress. 进展中，主要针对改动较多的 PR，可以先提交部分，标题或 Tag 加上 WIP，表示尚未完成，这样别人可以先 review 已提交的部分。

CodeReview的重要性

首先，要明确代码评审虽然会增加项目成本和影响合并到主分支的速度，从而可能延长发布时间，但为什么团队普遍认为这个过程是必不可少的呢？特别是在像谷歌这样的大型工程中，为何将代码评审视为一项长期的利好？

代码评审流程实际上是质量管理中的一项左移策略，它致力于在问题进入主代码分支之前及时发现和解决。这就像制造业中的质检员一样，在开发过程中，代码评审担当着确保代码质量的重要职责。

代码评审带来的好处：
1. 检查代码正确性
2. 确保代码变更能够被其他工程师理解
3. 增强整个代码库的代码风格一致性
4. 心理上促进团队的责任感
5. 知识共享，相互学习
6. 提供代码评审本身的历史记录

随着时间推移，这些好处对团队都至关重要，其中不仅对代码作者有益，而且对评审者同样是有益的。通过严格的CodeReview能够帮助团队成员养成良好的编程习惯和规范，从提高整个团队的代码质量和团队认知拉齐。之前也遇到过没有代码review的项目，可能项目本身也并不是特别重要，所以去掉了审核的流程。但是带来的影响就是随着人员的增加或者替换，代码就像经常说到的shi上堆shi，一团乱麻，难以维护。

CodeReview实践经验

随着编程经验的增加或者阅读开源代码的数量增加，自然会有自己的代码风格和心得，但是每个人都有自己的心得，所以首先要有统一的代码风格大家遵守，这个风格可以借鉴谷歌编程风格或者阿里巴巴的风格等，或者自己团队总结出新的风格都可以。最重要的就是有统一指导思想。

代码规范质量

CodeReview过程中首先要关注代码的规范和质量问题，而且出现问题也是最多的，包括命名、注释是否合理、日志打印规范、异常处理是否合理等等，接下来主要阐述一下主要遇到的一些问题点以及哪些是合理的方案。

命名

关注点：变量命名、方法命名、类命名、包命名
案例：命名拼写错误、命名与实际含义不符（超出或小于）、用词不准

注释

关注点：是否有注释、注释是否合理
案例：通篇无注释、注释不准确

日志打印

关注点：日志打印级别、日志打印参数、日志格式、异常打印、是否应该打印日志
案例：日志打印级别误用、日志参数未打印、日志格式不规范、异常信息未打印、打印日志过多

异常处理

关注点：异常是否抛出、是否规范的异常编码等
案例：异常该抛出未抛、肆意的使用RuntimeException等

逻辑正确

关注点：业务逻辑是否正常
案例：空指针问题、逻辑不正确等
这个问题不像其他问题一样，一方面可能需要了解业务然后才能更容易看出逻辑相关的问题。

代码风格一致

关注点：代码风格与应用整体风格一致
案例：代码风格不一致，比如新来的人不知道新建包存放类，但是这个类归属其实已经有对应包了，新人可能不清楚。

代码复杂度

关注点：圈复杂度
案例：大量嵌套if导致非常复杂等

架构设计

之前我觉得CodeReview中不需要关注架构设计，理论上应该在评审阶段提前确定好的，但是在实际过程中还是会有一些不合理的地方：比如分层是否合理，是否具备扩展性、业务域划分是否清晰等等。

关注分层

关注点：分层是否合理、是否存在跨层调用
案例：分层混乱、跨层调用

关注扩展性

关注点：扩展适配
案例：硬编码扩展性低

业务区域划分

关注点：业务域划分清晰
案例：业务域划分混乱

性能问题

性能问题容易被忽视，由于大量的业务代码的编写性能问题往往潜藏在大量的业务代码之后，在CodeReview阶段并不一定能够及时的发现问题。

慢SQL

关注点：索引设计、是否存在慢SQL语法
案例：索引未设计、慢SQL用法如like %xxx语句等

缓存设计

关注点：添加缓存、是否存在缓存击穿问题
案例：该加而未加缓存、缓存击穿问题等

安全问题

安全性是很容易忽视的问题，比如典型的无登录校验的上传接口、越权访问问题、SQL注入风险等等。
SQL注入：例如当前代码中使用的是字符串拼接的方案构造成完整的SQL，然后直接调用数据库连接执行SQL，该方案比较典型的问题就是SQL注入的问题，攻击者可以通过注入条件OR 1=1等条件即可实现对表拖库。

是否存在安全风险

文件上传验权、越权访问等问题

借助工具

Sonar

通过Sonar可以方便的扫描出以上这些问题，所以提交cr前，我们自己先扫描一遍，尽量避免低级错误。

代码风格插件

如何做好一个Reviewer

在做review的时候，虽然我们只关注代码层面的问题，但其实我们更应该关注人这个层面。不能将CodeReveiw变成批斗大会，每个人的编程思想各异，CodeReview是相互尊重相互学习非常好的场景，甚至于可以认为是被推动成长的一个很好的地方。所以要尊重对方，提升自我修养，推动CodeReview的文化建设和落地，从而提高自己作为CodeReviewer的各方面的成长和代码质量提升。

站在CodeReviewer角度

作为CodeReviewer一方面是代码的质检员，借助团队的代码规约来严格把控代码质量；另一方面作为学习者，通过团队的cr代码学习代码中的优秀设计。

1.学习心态： 代码CR的过程并不是一味的从代码中找问题的过程，也是相互学习的过程，要尊重对方。从代码CR中汲取优秀的设计思想，学习被CR的代码中设计优秀的地方，每一份代码中都有一些不错的地方，内化为自己的设计理念。比如一个简单的场景：一处复杂设计的代码在当前的代码中被重构设计的更加优秀，可读性更好。

**2.专业的知识储备：**在CodeReview之前我们需要储备对应的知识，知道为什么要这样做，为什么不能那样做，以及那样做会有什么样的坏处（如性能损耗等），了解底层的实现细节锤炼自身扎实的知识储备，此外不断加强学习新技术打开视野，拓展知识储备的边界，快速的成长。

**3.关注细节耐心CR：**作为CodeReviewer要充分的关注代码细节，包括命名、注释、异常处理、日志等等，甚至于代码中的一个空格。同时要有耐心，CodeReview是很耗费时间和精力的，要保持耐心和长期坚持。

**4.有深度的CR意见：**很多情况下，我们喜欢提CR的时候一步到位这一句要改成什么，却很少会关注为什么要这样写，对于复杂一些/少见一些的场景，我的建议是应该在CR意见中进行阐述，讲清楚前因后果，此时就成功的将知识储备输出给了被CR的同学，在CR的过程中获得了成长。

**5.尽可能了解业务背景：**没有业务背景往往只能看看代码的规范性问题，然而对于业务逻辑中的问题如果没有深入的了解清楚业务诉求是比较难做出高质量的CodeReview意见的。

站在被CodeReviewer角度

作为被CodeReviewer，一方面作为学习者，通过团队同学的CodeReview意见从中学习优秀设计思想和代码规范；另一方面，也可以作为规范的输出者，通过良好的代码设计输出自己的代码设计理念，通过CodeReview等场所对外输出。

**1.学习心态：**面对CodeReviewer提出的意见，我们要保持良好的学习心态，思考下他意见背后的原因，汲取其中的设计和规范理念从中获得成长，敢于拉齐自己认知与团队内不一致的地方，快速的融入并遵从团队统一的代码规范体系。

**2.虚心接受建议：**被CodeReviewer要学会接受建议，应该尊重别人的思考和想法，对于好的意见我们要虚心的接受，进而不断的提升自己的编程能力。

**3.有自己的主见：**接受建议并不是说所有的都要接受，很多时候多种方案是都可以的，也有时候意见也有考虑不足之处，此时，被CR的同学需要保持主见，避免因为一味的接受别人的建议而引入了新的问题。

**4.开放包容的心态：**有时候CR者并不一定提出的全部是合理的意见，此时，还是要保持开放包容的心态，保持友好的沟通与对方将问题讨论清楚即可。

**5.对自己的代码负责：**虽然CodeReview能够起到保证代码质量的目的，但是作为代码的开发者尽量不要将还未测试过的代码丢给CodeReviewer，CodeReview的过程不能保证所有的问题都能够被发现，一定要为自己的代码负责，当确定自己的代码没有问题的时候再提交CodeReview，这也是对CodeReviewer的一种尊重。

CodeReview文化建设

CodeReview文化也是团队文化的一部分，需要长期坚持和迭代，才能使这种文化流传下去。

1. 明确目标和价值观： 在团队中明确制定 Code Review 的目标和价值观。明确指导原则，如代码质量、知识共享、团队协作等，有助于团队成员理解 Code Review 的重要性。

2. 设立明确的标准和规范： 制定一套清晰的代码审查标准和规范，确保所有团队成员在审查中遵循相同的指导方针。这有助于确保一致性，提高代码可读性和可维护性。

3. 培训团队成员： 提供培训和资源，确保团队成员了解如何进行有效的 Code Review。包括技术方面的培训，以及如何提供和接受建设性反馈的培训。

4. 鼓励积极参与： 鼓励团队成员积极参与 Code Review 过程。认可和奖励那些在审查中提供有价值反馈的成员，激励团队共同努力提高代码质量。

5. 设定合理的时间期限： 为 Code Review 设置合理的时间期限，确保审查过程不会拖慢开发速度。同时，也要保证足够的时间用于深入审查，以提高代码质量。

6. 采用自动化工具： 利用自动化工具进行代码静态分析和自动化测试，以帮助发现一些常见的错误和潜在的问题。这有助于减轻人工审查的负担，使其更专注于复杂的逻辑和设计问题。

7. 定期审查和反馈： 确保定期进行 Code Review，并提供及时的反馈。通过定期审查可以及早发现问题，同时也能帮助团队成员快速学习和改进。

8. 建立安全的反馈文化： 建立一个安全的环境，鼓励开发者提供和接受反馈。团队成员应该理解，Code Review 不是对个人能力的评判，而是为了共同提高团队和代码质量。

9. 持续改进： 不断评估和改进 Code Review 过程。收集团队成员的反馈，了解他们的需求和痛点，并相应地调整和改进 Code Review 流程。

总结

CodeReview是保障代码质量的关键步骤。作为CodeReviewer，我们需遵循团队规范，严格审查代码，确保质量和规范符合标准。同时，作为被评审者，我们要尊重他人的时间和意见，共同维护团队的代码规范。通过CodeReview，我们能学到他人的见解和设计思路，促进个人成长。本文分享了在CodeReview过程中的一些体会，强调了良好的CodeReview文化对团队成长的推动作用。希望大家在前进的道路上坚守CodeReview文化，努力使工程实践达到卓越水平，打造出有竞争力的技术团队。