idea 谷歌代码标准_Google启发的13条代码审查标准

idea 谷歌代码标准

In this article, we will briefly go through 13 code review standards that could dramatically help improve the health of your software as well as keep your developers happy.

在本文中，我们将简要介绍13种代码审查标准，这些标准可以极大地帮助改善软件的运行状况并保持开发人员的满意。

As the name suggests, code review is a process where one or more developers review or screen the code written by another developer (the author) to ensure that:

顾名思义， 代码审查是一个过程，其中一个或多个开发人员审查或筛选另一位开发者(作者)编写的代码，以确保：

• the code does not have any mistakes, and there are no bugs or issues
  该代码没有任何错误，也没有错误或问题
• it meets all the quality and styling guide requirements and standards
  符合所有质量和样式指南要求和标准
• the code does what it is intended to do
  代码执行了预期的操作
• when merged, it will leave the health of the codebase in a better state
  合并后，它将使代码库的运行状况保持更好的状态

This is why code review is a critical part of software development. The code reviewer is acting as the gatekeeper who decides whether the code is in a state to be part of the codebase and reach production.

这就是为什么代码审查是软件开发的关键部分的原因。 代码审阅者充当网守，负责确定代码是否处于要成为代码库的一部分并进入生产状态的状态。

Google is known for its technological excellence, and they have effective code review standards that seem to highlight some vital points to keep in mind when reviewing code. At Google,

Google以其卓越的技术而著称，它们具有有效的代码审查标准，这些标准似乎突出了审查代码时要记住的一些要点。 在Google，

“The primary purpose of code review is to make sure that the overall code health of Google’s code base is improving over time.” — Google’s Engineering Practices documentation

“代码审查的主要目的是确保Google代码库的整体代码运行状况随着时间的推移而不断改善。” — Google的工程实践文档

Here is a list of things to keep in mind when you are reviewing a change list (pull request).

这是您查看更改列表(拉动请求)时要记住的事项列表。

守则审查标准 (Code Review Standards)

1.该代码改善了系统的整体运行状况 (1. The code improves the overall health of the system)

Every change list (pull request) improves the overall health of the system. The idea is that as a result of such small improvements, the health of the software or codebase will improve after every merge.

每个更改列表(拉动请求)都会改善系统的整体运行状况。 想法是，由于进行了如此小的改进，每次合并后，软件或代码库的运行状况都会得到改善。

2.快速的代码审查，响应和反馈 (2. Quick code reviews, responses, and feedback)

First and foremost, do not delay pushing (merging) better code. Don’t expect the code to be perfect. If it’s in a condition that improves the overall health of the system, then ship it.

首先，不要延迟推送(合并)更好的代码。 不要指望代码是完美的。 如果它的状况可以改善系统的整体运行状况，则请发货。

“A key point here is that there is no such thing as ‘perfect’ code — there is only better code.”— Google’s Engineering Practices documentation

“这里的关键是没有'完美'的代码，只有更好的代码。”-Google 工程实践文档

If you are not in the middle of a focused task, then do the code review shortly after it comes; however, one business day is the maximum time it should take to respond to a pull request (change list). It is expected for a change list (pull request) to get multiple rounds of partial/full code review in a single day.

如果您不在一项重点任务的中间，那么请在代码完成后立即进行检查； 但是，一个工作日是响应拉取请求(更改列表)所需的最长时间。 预计变更列表(拉取请求)将在一天之内获得多轮的部分/完整代码审查。

3.在代码审查期间进行教育和启发 (3. Educate and inspire during the code review)

Provide mentorship during code reviews by sharing knowledge and experience wherever possible.

通过尽可能共享知识和经验，在代码审查期间提供指导。

4.审查代码时遵循标准 (4. Follow the standards when reviewing code)

Always keep in mind that the style guide, coding standards, and such documents are the absolute authority during code reviews. For example, to enforce consistency between tabs vs. spaces, you can reference the coding conventions.

始终牢记，样式指南，编码标准和此类文档是代码审查期间的绝对权威。 例如，要在制表符和空格之间保持一致性，可以引用编码约定。

If Java is your language of choice, then you might find the following article useful that provides a summary of Java coding best practices at giant tech companies useful: “A Short Summary of Java Coding Best Practices.”

如果您选择Java，那么以下文章可能会很有用，它提供了对大型科技公司的Java编码最佳实践的总结 ：“ Java编码最佳实践的简短摘要 ”。

5.解决代码审查冲突 (5. Resolving code review conflicts)

Resolve conflicts by following the agreed-upon best practices in the style guide and coding standards documents as well as seeking the advice and suggestion of others who have more knowledge and experience in the area of the product.

通过遵循样式指南和编码标准文档中商定的最佳实践，并寻求其他在产品领域具有更多知识和经验的人的建议，来解决冲突。

Alex Hill 亚历克斯·希尔

If your review comments are optional or minor, then clarify that in your review comments and leave it to the author to decide whether to address or ignore them.

如果您的评论是可选的或次要的，请在评论中进行说明，然后由作者决定是解决还是忽略它们。

As a code reviewer, you can at least suggest that the change list (pull request) remain consistent with the rest of the codebase in the absence of a style guide or coding standards.

作为代码审阅者，您至少可以建议在没有样式指南或编码标准的情况下，更改列表(请求)与其余代码库保持一致。

6.演示UI更改是代码审查的一部分 (6. Demo UI changes as a part of code review)

If the change list (pull request) changes the user interface, then in addition to the code review, it’s necessary to have a demo to ensure that visually everything looks as expected and matches the mocks.

如果更改列表(拉请求)更改了用户界面，则除了代码查看之外，还必须进行演示以确保外观上的所有外观均符合预期并与模拟匹配。

For the front-end change list (pull requests), it’s always recommended to do a demo/walkthrough or make sure that the change list also includes the necessary UI automation tests that verify the functionality added/updated.

对于前端变更列表(拉动请求)，始终建议进行演示/演练，或确保变更列表还包括必要的UI自动化测试，以验证添加/更新的功能。

7.确保代码审查伴随所有测试 (7. Ensure that the code review accompanies all tests)

Unless it’s an emergency, the pull request (change list) should accompany all the necessary tests, i.e., unit, integration, end-to-end, etc.

除非紧急情况，否则拉取请求(更改列表)应伴随所有必要的测试，例如单元，集成，端到端等。

An emergency could be a bug or security flaw that needs to be fixed as soon as possible, and tests can be added later. In cases like this, make sure that appropriate tickets/issues are created and that somebody has taken ownership to get it done right after the hot -ixing or deployment is done.

紧急情况可能是需要尽快修复的错误或安全漏洞，以后可以添加测试。 在这种情况下，请确保创建了适当的票证/问题，并确保有人在完成热固定或部署后立即拥有所有权才能完成。

Ethan Vincent 伊桑·文森特(Ethan Vincent)

There is no reason good enough to skip the tests. If due to time constraints, some of the goals are at risk of not being delivered, then the solution is not to skip tests but to descope the deliverables.

没有足够的理由跳过测试。 如果由于时间限制，某些目标有无法实现的风险，那么解决方案不是跳过测试，而是要对可交付成果进行范围界定。

8.专注时，不要打扰自己进行代码审查 (8. When focused, do not interrupt yourself to do code review)

If you are in the middle of a focused task, don’t interrupt yourself, as it might take a long time to get back on track. In other words, the cost of interrupting a focused developer is more than making a developer wait for a code review. Do the code review after your planned breaks, i.e., lunch, coffee, etc.

如果您正处于重点工作中，请不要打扰自己，因为这可能需要很长时间才能恢复正常。 换句话说，打断专注的开发人员所付出的代价比让开发人员等待代码审查要高得多。 在计划的休息时间(例如午餐，咖啡等)之后进行代码检查。

Credit: Jason Heeris

图片来源：Jason Heeris

The expectation is not always to get the entire code review process done and merged on the same day. What matters is to give the author some feedback quickly. For example, you might not be able to do a complete review, but you could quickly point out a few things that could be looked into. This would significantly help reduce frustrations during code reviews.

期望并非总是在同一天完成并合并整个代码审查过程。 重要的是Swift给作者一些反馈。 例如，您可能无法进行完整的检查，但是您可以快速指出一些可以研究的内容。 这将极大地减少代码审查期间的挫败感。

9.复习一切，不要做任何假设 (9. Review everything, and don’t make any assumptions)

Look at every line of code that is being assigned to you to review. Don’t make any assumptions about human-written classes and methods, and you should make sure that you understand what the code is doing.

查看分配给您检查的每一行代码。 不要对人工编写的类和方法做任何假设，并且应该确保您了解代码在做什么。

Manu 马努

Make sure to understand the code that you are reviewing. If you don’t, then clarify it or ask for a code walkthrough/explanation. If there is a part of code that you are not qualified to review, then make sure that there are other qualified developers who could review those parts of the code.

确保了解您正在检查的代码。 如果没有，请进行澄清或要求代码演练/解释。 如果您有部分代码不具备审阅的资格，请确保还有其他合格的开发人员可以审阅代码的那些部分。

10.回顾代码时要牢记大局 (10. Review the code with the bigger picture in mind)

It’s often helpful to look at the changes from a broader context. For example, a file was changed, and four (4) lines of code were added. Don’t only review the four (4) lines of code; instead, consider reviewing the entire file and check the new additions. Do they degrade the quality of existing code, or do they make the existing function a candidate for refactoring?

从更广泛的背景来看变化通常是有帮助的。 例如，更改了文件，并添加了四(4)行代码。 不要只查看四(4)行代码； 相反，请考虑查看整个文件并检查新添加的内容。 它们会降低现有代码的质量，还是会使现有功能成为重构的候选对象？

If such simple additions are reviewed not within the context of the function/method or class, then over time, you will inherit a class that is unmaintainable, super tangled, not easy to test, does everything, and is hard to extend or refactor.

如果不在函数/方法或类的上下文中检查此类简单的添加项，则随着时间的流逝，您将继承一个类，该类是不可维护的，超级复杂的，难以测试的，无法完成的所有工作，并且难以扩展或重构。

Remember, just as little improvements over time add up and result in a great product with the least number of defects, similarly, slight code degradations or tech debts over time will compound and result in a product that’s challenging to maintain and extend.

请记住，随着时间的推移，很少的改进加起来会导致缺陷最少的优质产品；同样，随着时间的推移，轻微的代码降级或技术欠债也会加重并导致产品难以维护和扩展。

11.认可并鼓励代码评审期间的良好工作 (11. Recognize and encourage good work during code review)

If you see something good in the change list, don’t forget to shout out the author for good work and encourage them. This is something that I have personally not done before. The aim of the code review should not only be to find mistakes but also to encourage and mentor developers for the great work they do.

如果您在变更列表中看到了一些不错的东西，请别忘了大喊作者好工作并鼓励他们。 这是我个人以前从未做过的事情。 代码审查的目的不仅应该是发现错误，而且还要鼓励和指导开发人员所做的出色工作。

12.在代码审查中要谨慎，尊重，友善和清晰 (12. Be mindful, respectful, kind, and clear in your code review)

It’s crucial that during the code review, you are kind, clear, courteous, and respectful while also being very clear and helpful to the author. When reviewing the code, make sure to make the review comment about the code and not the developer.

至关重要的是，在代码审阅期间，您要善良，清晰，礼貌和尊重，同时也要对作者非常清楚和乐于助人。 查看代码时，请确保对代码而不是开发人员做出评论。

Here is a guide by Google on how to be respectful during the code review: “Respectful code Reviews: A Guide for Code Reviewers.”

以下是Google撰写的有关如何在代码审阅期间保持尊重的指南 ：“ 尊敬的代码审阅： 代码审阅者指南” 。

13.解释您的代码审查注释，并牢记范围 (13. Explain your code review comments and keep scope in mind)

Whenever the code review comment suggests an alternative approach or flags something up, it’s crucial to explain why and provide an example based on your knowledge and experience, to help the developer understand how your suggestion is going to help improve the quality of the code.

每当代码审阅意见提出替代方法或进行标记时，至关重要的是要解释原因并根据您的知识和经验提供示例，以帮助开发人员了解您的建议将如何帮助提高代码质量。

When suggesting fixes or changes, find the right balance on how to guide the author to fix the code. For example, I appreciate guidance, explanation, and some tips or suggestions, and never the entire solution.

当建议修复或更改时，请在如何指导作者修复代码方面找到适当的平衡。 例如，我很欣赏指导，解释，一些提示或建议，而不是整个解决方案。

进一步阅读 (Further Reading)

For a more in-depth dive into Google’s code review standards, please check out the link below

要更深入地了解Google的代码审核标准，请查看以下链接

The cost of interrupting a focused developer is too high compared to making a developer wait for you to review their code in your next available time slot. For more on that, check out

与让开发人员等待您在下一个可用时隙中查看其代码相比，中断专注的开发人员的成本太高。 有关更多信息，请查看

Alex Hill touches on some really helpful topics on how to give and receive code review feedback in “The Art of Giving and Receiving Code Reviews (Gracefully).”

亚历克斯·希尔(Alex Hill)在“如何优雅地提供和接受代码审查的技巧”中谈到了一些有关如何给出和接收代码审查反馈的非常有用的主题。

Further on code review, Michael touches on some fundamental aspects of what makes an effective and better code review.

关于代码审查，Michael谈到了有效和更好的代码审查的一些基本方面。

结论 (Conclusions)

Thank you for reading, and I hope that you have enjoyed this article. If you have any comments or suggestions, please feel free to share them with the rest of us in the comments section.

感谢您的阅读，希望您喜欢这篇文章。 如果您有任何意见或建议，请随时在“意见”部分与我们其他人分享。

Stay tuned for future articles on similar topics.

请继续关注有关类似主题的未来文章。

翻译自: https://medium.com/better-programming/13-code-review-standards-inspired-by-google-6b8f99f7fd67

idea 谷歌代码标准