Code audit standards
The core purpose of the audit is to ensure that the code Google code development process of continuous improvement can be sustained to ensure health. All code review processes and tools are designed to ensure this goal.
To achieve this goal, we do a lot of trade-offs.
First, researchers must be able to on a personal mission to make improvements . If you never submitted code improvements, and that the product can not be improved. Similarly, if the code reviewer for any submission are set very high threshold change will also affect the developer in the future also submit improve enthusiasm.
From another aspect, said, code review's responsibility is to ensure that each list of changes (CL) 1 content are able to ensure code quality on a global, rather than over time lead to quality continues to deteriorate. This is actually more difficult, weakening the overall quality of the code because the code is actually very small degree of health problems caused by accumulating, especially when a team under a clear schedule pressure to take some shortcuts to be able to achieve their goals .
Auditor for audit of the code they have rights and responsibilities. They need to ensure that the code is consistent baseline style, maintainable, and other content in the article mentioned in the "What should review code review."
So, we expect to review the code contains the following standard rule:
Under normal circumstances, the audit needs to identify a list of changes to the overall system code must be some quality improvement, even if it is not yet perfect.
In the code review rules to guide, this is the most important principle.
Of course, there are many limitations to this rule. For example, it contains a list of changes the characteristics of a system are not allowed to join, even though the code of good design and quality audit can also directly denied.
There is a very important concept, "perfect" code does not exist, there will only be betterCode. Reviewers should not be required before accepting submissions, it is necessary to submit the list of changes were polished in every little detail. Audit recommendations need to continually improve and to make a balance between the important changes in the system. Instead of requiring perfect, reviewers should pay attention to is continuous improvement . When a list of changes have improved overall system for maintainability, readability, understandability, should not because "not perfect" but was rejected a few days or weeks.
Audit should have been able to freely leave comments on areas for improvement advice, but if this is not very important, you can add a prefix, such as in front of the "Nit:" This will allow the submitter know it's just that they can ignore a small optimization points.
Note: This document does not submit to any deterioration in the health of the code to make excuse, and only under certain economic circumstances you may consider doing so.
Mentoring
Code reviewers have a very important role is to guide developers of new knowledge about the language, framework, or a common rule of software design. Can leave some comments to help developers learn something new is always a good thing. Sharing knowledge is a good thing to improve code quality. You need to remember that if your comments are purely educational in purpose, rather than criteria mentioned in this document, please add "Nit:" prefix or prompt submission of these modifications are not required to force changes in the list.
in principle
- Professional reality and data negative opinion and personal preference.
- For style issues, "style guide" is the absolute authority. Any pure style point of view (such as spaces) in the style guide does not mention is personal preference. This part of the style should also be standardized, if not agreed in advance to receive the submitter's style.
- Aspects of software design would be almost impossible purely personal preference or style issues. These are based on the fundamental principles of construction, it should rely heavily on these principles, not personal opinion. Sometimes there are some limited options. If the submitter can prove that these practices are similar (or by the actual data based on engineering principles), reviewers should receive preference submitter. Otherwise, depending on the standard rules of software design.
- If there are no other rules applicable, reviewers should be required to be submitted by the existing code base consistent, as long as the content changes will not affect the health of the system.
Resolve conflicts
Code review in the face of any conflict, the first step should always be developers and reviewers agreed, in principle, is based on this document and other documents, such as "Change the submitter's Guide" and "Audit Guide."
When it is difficult to reach agreement, the submitter and reviewer face to face communication or voice communication is very necessary, rather than to resolve conflicts through the code review comments. (But remember that the results can be discussed recorded in the form of comments in the change submission for future ease of reference)
If the above method does not solve conflicts, a common approach is to upgrade issues. Upgrade method is usually initiated by team meetings, technical leadership required to participate, consult the maintainer or the views of managers, to make the final decision. Do not submitters and reviewers can not agree on an idle submitted.
Next notice: The code review, we should look for what.
Summary:
Google code review, we must first establish the principle is the principle, coding style, software design and so on. Based on these principles in order to determine the extent of the health system code, not personal preferences or use some kind of framework.
Reviewers have the right to refuse to submit, but burdened with system improvements to enhance and maintain a healthy degree of responsibility. To be familiar with the principles of various companies to produce their own judgments, and their opinions are divided into necessary and recommended two levels.
When faced with conflict, it should not be the responsibility of the submitter or the reviewer particular aspect, but argue both sides should try to convince the other side, when you can not convince each other upgrade issues, requesting superiors or external to judge.
In the inside, all the characters have a very important principle: a real respect for the code, the code love . And not just fool the task, just submit random audits, and just by the merger. This depends on the team's culture and health to support.
CL: is "changelist" acronym refers to the change submitted a complete self-contained version control or submit to the code review. In other organizations (non-share reform) called the change (change) or patch (patch). ↩