如何更好地检查代码？

首先，我坚信代码审查过程，始终希望其他人来审查我的代码。我的问题确实围绕着如何在为他人执行代码审查方面做得更好？

我知道要执行代码审查，您需要了解现有代码的工作方式以及本地标准是什么，我都非常了解这两个方面。我仍然觉得自己从来没有对其他人做过足够好的代码审查。我也知道某些人似乎比其他人做得更好，所以我想知道对于那些优秀的代码审阅者来说，您使用什么技术？

没有办法进行更好的代码审查。您唯一能做的就是随着学习和经验的不断改进。

通常我会遵循

- Use variables judiciously
- Keep things in scope loose boundaries will generate more errors
- Orient your language of coding in domain specific terms, they make more sense
- Keep loops to minimum 2 for each method if needed
- use ternary operators
- Arrange methods alphabetically
- Keep errors at handling ease
- write less but efficient code

我认为您可以添加很多东西。

问自己，是什么使别人成为您的优秀评论者？

另外，当您浏览代码时；

• 停在您不了解的地方，写下需要评论
• 识别是否符合编码标准：空格，方括号，camelCase..etc
• 检查它是否包含所有功能
• 对逻辑进行简单测试，以查看其是否通过边界条件等。

我只是为了

• 解释为什么需要建议的更改。确保我不仅了解解决问题的原因
• 同意代码格式-以便每个人的代码看起来相同/熟悉
• 共享要维护的代码特征的列表。将其放在Wiki上，这样每个人都不必一次犯所有错误。经常更新。

除此之外，“知道要寻找什么”只是伴随着经验，实践和阅读。

以我的经验，最好的方法是让漏洞小组进行代码审查。我们在每个项目中使用一个提交邮件列表，您可以在其中跟踪对版本控制系统进行的每个代码更改。我们的大多数开发人员都订阅了他们的项目特定邮件列表，因为他们对代码更改感兴趣。

当有人注意到新源代码中的一种不好的方式时，他要么向提交者说明他如何才能做得更好（如果提交者是受训者），或者如果他是一位经验更丰富的提交者，则他开始对此进行讨论。

当然，这种方法不能保证所有新代码都得到审查，特别是在压力大的时候，团队成员中没有人有空余时间来关注每个代码更改。同样，并非每个开发人员都有责任确保每个开发人员都能做好自己的工作，仅此一项您就不能保证对其进行审核。但是，至少在我们的团队中，总会有一名技术经理负责技术质量。

如果代码审查符合以下分数，我是代码审查的忠实拥护者：

• 每个开发人员都有可能查看所有代码和他的观点
• 没有人有权滥用他人的代码
• 不仅错误的代码可以激发讨论，而且良好的代码也可以
• 讨论以每个参与人员的幸福结束
• 审查几乎实时进行，至少在功能完成之前

我了解到的是，如果您是审查每一行代码的人，并认为必须根据代码格式或代码效率来控制诸如代码质量之类的事情，那么您的效率很低，因为您做的事情是机器可以做的事情您。您的目标应该是使用一个持续集成系统来控制每个代码贡献的构建和代码质量。如果该系统生成报告并将其发送给贡献者，那么一切就完美了。

我必须承认，如果由于必须控制或对程序员的素质进行排名而不得不审查代码，那么我的建议就没有意义了。在这种情况下，我也不会逐行检查源代码。我会评论：

• 是否存在与安全相关的问题
• 是预期使用的API
• 代码是否应用了指定的体系结构
• 他是否编写了有用的测试（但只有在明确指示他的情况下，我才必须学习）
• 文献资料
• 构建过程
• ...还有可能

如果您是一位经验丰富的开发人员，则一定会发现总是可以找到诸如循环之类的东西，而这些事情可以使您获得更好的性能。当然，向其他人解释这样的知识很有用，但这不应该是复习课的一部分。如果存在重大的性能问题，那不是因为他（或她）使用了效率较低的列表类型变体。

因为最初的问题是为什么有些人会像其他人那样做得更好，所以我会回答说，这些人可能在真正的评论开始之前进行了预览，这意味着他们可能已经做好了自我准备，以便他们确切地知道自己想评论什么。

[H]现在我可以在为他人进行代码审查方面做得更好吗？

问他们很多问题

我知道要执行代码审查，您需要了解现有代码的工作原理...

实际上，不，您不必事先知道代码就可以成为优秀的审阅者。

在几项工作之前，我的雇主开始要求所有代码签到都必须由审阅者签名。我主要使用C语言进行GUI工作，而对我来说最好的审阅者之一是我的好友Bill。他精通C语言，但从未做过很多GUI工作，并且在进行审查时，他不知道我的代码应该如何工作。

但是他对此提出了很多问题，并且必须进行解释，这样他才能理解我的代码做了什么以及为什么激发了我很多思考。这使我发现了许多带有边缘情况的怪异小错误，并考虑了我可能采取的其他方法。另外，尽管那时我已经写了22年的C语言，并且认为自己很熟练，但是它很快提高了我的代码质量。

即使我不再在那里工作，我仍要在签到之前检查差异并问自己：“比尔对此有什么疑问？” 很多时候，我最终会改变某些东西。