代码审查指南：不要只关注细节
极客时间编辑部
讲述：初明明大小：4.08M时长：04:28
你好，欢迎收听极客视点。
代码审查是软件开发中常用的手段，被公认为是一个可以提高代码质量的有效手段。但想要成功实施代码审查却不是一件轻松的事情，很多人在执行过程中会过于专注在细节上，尤其是在不知道上下文的情况下。
针对这个问题，开发者帕特里克·斯图德尼亚克（Patryk Studniak）撰文分享了自己的经验与做法。极客视点摘录了其中的关键内容，供你参考。
如果只是从“整洁代码”的层面来考虑代码审查的话，我们所做的可能只是一些表面的打磨工作。举个例子，指出方法中的嵌套条件或者多参数问题的确是有意义的，我们也应当继续这样做下去，但说实话，这些并不是代码审查的最大价值所在。即使有上面列的这些错误，程序也还是会正常运行的，如果能有位经验丰富的程序员来做维护的话，它基本就不会出什么问题。我们的关注点更应该放在经过审查的代码所处的上下文中，并在那里排查潜在问题。
架构是软件中最关键的部分之一，它要能反映业务逻辑，同时也是代码审查中的重点关注对象。如果我们能在这个核心中发现问题并迅速做出反应，就会为产品带来最大的价值。
那具体怎么做呢？一般来说，我们可以根据代码审查各个层次的重要性和效果来区分出三个层级。
1. 架构
第一层是以架构为中心的代码审查，这也是最重要的一层。在这层，我们要考虑项目的具体情况以及之前曾达成的共识。
这个层级的代码审查主要应由最有经验的程序员来完成，因为他们了解项目架构。就算是新手也可以尝试，这是一种很好的锻炼方式，但如果感到吃力也不用太过勉强。
在这个阶段，找出潜在的命名泄露和违规是至关重要的。某个规则在你看来是理所当然的，因为你对这个项目了如指掌，但对其他人来说就不一定了。这样的情况可以作为讨论的一个很好的起点，从而弄清楚代码作者的动机。
架构师和工程师在做架构层面的代码审查时，也应牢记提交的拉取请求在扩展和重复利用方面的需求，要知道这一点可以无条件地更改实现。同样，应用安全也是需要重点关注的关键因素之一。
架构层面上的代码审查需要考虑的问题还有很多，相信你也认识到在这一阶段能够提前发现潜在问题的价值有多大了。
2. 代码清理
在代码审查的第二层，我们可以深入到代码本身，更加注重细节。这一阶段被称作代码清理审查。
在这里，我们可以开始就内聚程度和类的组成进行争辩。将所有的疑问和困惑摊开来讨论，有助于我们更好地理解代码背后的思考过程。批判他人之前先要了解情况，也许这只是别人走出来的，我们暂时还看不懂的捷径。
说起“整洁代码”，就不得不提一句 SOLID 原则和测试。如果有哪里没有遵守这些规则中的任何一条，我们都应该迅速找出原因。工程师可能会出于某些原因不按规则出牌，但更有可能只是犯了个错。
编程中最艰难的部分之一大概要数命名了。如何合适地为变量、方法、函数、类和数据结构命名很是考验人。有的名字对你来说可能很顺手，但在其他人看起来可能就是云里雾里了。即便如此，我们还是要努力找到最优的“名字”，这也是二级审查应当关注的点。
3. 打磨表层
第三阶段也就是最后一层，我们要做的是代码审查中的打磨抛光阶段。在这一阶段我们面对的是一些通常可以被 linter 或者编译器自动捕捉到的小错误，例如代码格式、缺失分号等其他琐碎问题。
这时我们也可以做一些细小的排序 / 分组更新，抱怨下代码作者使用的数据结构，到底是该用 List<> 还是 Set<> 还是别的什么。
无论是谁提交了拉取请求并不重要。代码审查应该始终一视同仁，再有经验的软件工程师也不是什么都懂，哪怕是关于他们手头上正在做的项目，他们也不一定全都会。说到底，我们只是人，人都会犯错。
以上就是帕特里克分享的做好代码审查的三个层级，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
- walnut架构层面的命名泄露和违规指什么？
收起评论