Code review, also known as code review, if a team is using a task branch workflow, the code review is started after all the code has been written and passed the automated test, and before the code is merged. The common purpose is to find system defects, ensure the overall quality of the software and improve the level of developers themselves, all the tools and processes of code review are built for this purpose. The role of code review for agile teams is as follows:
Code review sharing knowledge
Work evaluation can be better done through code review
The code reviews will allow you to take a vacation
Guide the new engineer through code review.
Since code reviews require a lot of checks, it's important to find a good reviewer. Generally, different reviewers review different parts of the change list carefully. Of course, if pair programming, and your teammates can conduct high-quality code reviews, then the code written in this way can generally be considered to have been reviewed. In addition, we can also conduct face-to-face reviews, where reviewers ask developers some questions.
According to Google's project description, the Code Audit Specification consists of two separate sets of documents, representing best practices in two areas:
Some of the terms used in some of these documents are as follows:
CL: means "change list (changelist)", meaning a separate change that has been committed to version control or is in the process of being checked. Other organizations are often referred to as "change" or "patch"
LGTM: means "(Looks Good to Me) looks good to me," which code reviewers said when they approved CL.
Next, let's look at the main contents of the two documents.
1. Code reviewer's Guide - how to conduct code reviews
The Code Reviewer's Guide was originally a complete document, but the author divided it into six parts, which the reader can read as needed.
2. CL Author's Guide - CL Author's Approval Code Review Guide
CL Developer's Guidelines include some of the best practices of developers who perform code reviews that can help you complete reviews faster and better.
In Google's view, the goal of code review is to ensure the overall code health of Google's code base. Google uses the following rules as the criteria for code review:
Generally speaking, once CL improves the overall code health, reviewers should also be inclined to approve the list even if the CL is not perfect. This is a high-level principle in all code review guides. It also has some limitations. For example, if CL adds features that reviewers don't need, reviewers should not pass even if the code is well designed.
There is no so-called "perfect" code, only better code. The reviewer should not require the author to be too perfect with every small part of the CL before approval. Instead, reviewers should weigh the need to move forward and the importance of revising proposals. Reviewers demand continuous improvement, not completion.BeautifulCode. CL as a whole, if it can improve the maintainability, readability and comprehensibility of the system, then don't postpone updates for days or weeks because it is not perfect.
Reviewers should often leave comments to express practices that lead to better performance. If these practices are not very important, the prefix "Nit:" needs to be added so that the coder knows that the content is negligible.
Code review has an important function, that is, to teach developers some development experience, whether it is language, framework or general software design guidelines. Leaving some comments will always help developers learn some new knowledge. Sharing knowledge is also an important part of improving the health of system code. Of course, if the reviewer's comments are merelyeducationThe prefix "Nit:" should be added if it is not so important to the standard requirement.
Criteria for evaluation
Technical facts and data take precedence over opinions and personal styles.
In terms of code style, Google's Code Style Guide is the most authoritative reference. Any code habit that is not included in the style guide is personal style, but we should ensure that the basic style is consistent with the Google style guide.
There are hardly any pure stylistic or personal habitual problems in software design. Many style problems are based on some basic criteria, which are not simply determined by personal opinions. In addition, if the coder proves that several methods are equally effective through data or basic engineering principles, then the reviewer should accept the author's style. Otherwise, the choice of preferences depends on the standard principles of software design.
If there are no other applicable rules, the reviewer can ask the author's preferences to be consistent with the current code base without affecting the overall code health level.
In code review, if any conflict occurs, the first step should be for developers and reviewers to reach a consensus based on the CL guidelines for this project. When consensus is very difficult, developers and reviewers should communicate face-to-face, not just through reviews. If the meeting discussion can not be solved, then we need to expand the meeting. We can reach a final consensus by communicating with code maintainers, engineering managers and other developers.
If you want to know more about Google's code review specifications, you can see the project. The address is as follows: