How to do CodeReview in team development?

preamble

Have you ever written a very simple requirement or optimization? And you thought it didn't need to be reviewed and you could just merge it into the master branch. Maybe after a few days or weeks you suddenly realized that you made an obvious or undeserved mistake. If someone else had come to review the code, then the problem might have been caught and dealt with in time.

CodeReview (Code Review) is a quality assurance mechanism used to confirm the solution design and code implementation, through which we can check the code, testing process and comments, mainly used to improve the quality of code in the software engineering development process.

You may think that you must be an expert in the field or a senior engineer to review other people's code, but in the author's experience: in fact, this is not the case, the reviewer does not need to fully understand the business needs of the project or how rich the coding experience, but only need to review the code to provide a new, reasonable, and comply with the specifications of the perspective.

The following author to their own practical experience to share with you, how to do a good job of code review in project development.

---

I. Why do it

The primary purpose of code reviews is to bring a fresh set of eyes to theA new perspective on those potential problems.

In the case of the team I am currently working with, code review is a critical step in the development process. By identifying and resolving issues early on, it not only improves the quality of the product, but also ensures the consistency and reliability of the code; it also allows the development team to agree on the way the product is built to the standards required for the product.

So while code reviews may be time-consuming and labor-intensive at the moment, the role they play will become more and more apparent as time goes on.

---

II. What are the benefits

Maintaining the CodeReview habit and actively participating in your team's CodeReviews will have at least the following obvious benefits:

• Improve code quality: Code reviews can help team members identify potential defects, vulnerabilities, and performance issues, thus ensuring code stability and maintainability. Through reviews, team members can learn from each other, learn from others' good practices, and improve their own coding skills.
• Promote teamwork: Code review is a way to improve teamwork and help team members better understand each other's work and progress. During the review process, team members can communicate with each other and share their experiences, thus improving the technical level and problem solving ability of the whole team.
• Ensure project progress: Code reviews can identify and resolve issues in a timely manner, avoiding serious technical debt at a later stage of the project. Reviews can ensure that the project progresses according to plan and improve development efficiency.
• Cultivate team culture: Code review helps to cultivate the learning atmosphere and enterprising spirit of the team. By reviewing each other, team members can make progress together and form a positive team culture.

---

III. What to do

3.1 Conditions of evaluation

• Pre-requisite: The code has passed the code check of Alibaba Java Coding Guidelines (idea plugin);
• Large projects: If you add/modify more than 10 files or more than 200 lines of code, you need to organize a CodeReview meeting and invite relevant colleagues and senior/senior development colleagues to participate;
• Small projects: small requirement changes (e.g. less than 10 file changes or less than 100 lines of code) require at least 1~2 colleagues to help review and suggest changes;
• Focused Logic: It is recommended to invite colleagues who have been responsible for the project to review it together, or to review it in pairs during development.

3.2 Focus of the review

• Integrity checks: function points, business logs, exception logs, etc.
• Consistency check: whether the code logic conforms to the design document, whether the code style is uniform, etc.
• Correctness checks: technology selection, accuracy of annotations, definition and use of variables, etc.
• Modifiability checks: e.g. magic value 123, use of specialized constant classes or enumerations, etc.
• Predictability checks: dead loop, infinite recursion, array out of bounds, null pointer, etc.
• Comprehensibility checks: naming conventions, clarity of comments, git commit descriptions, etc.
• Logic checks: not overly complex implementation, code splitting, readability, extensibility, etc.
• Security checks: including prevention of injection attacks, protection of sensitive data, interface authentication, etc.

3.3 Form of evaluation

• Meeting review: Gather the relevant reviewers together and conduct code review through meeting discussion, which is recommended once a month if there are no other emergencies. This method is suitable for small and medium-sized teams or important code changes.

  As:

  • The head of the department organizes a review meeting, which can be fixed on a certain day of the month and lasts about 15-20 minutes;
  • The venue can be a small meeting room, which can accommodate about 10-15 people and needs to have projection equipment;
  • Attendees can be the entire back-end team of the department, draw up a lead reviewer and everyone can participate in the discussion

• Random sampling: a random portion of code is selected for review to verify the quality and standardization of the code. This approach can be part of the team's daily routine.

• Tool support: Use code review tools to automate some of the review process, such as code static analysis tools and code specification checking tools. These tools can provide some important indicators of code quality and help identify potential problems.

---

IV. What else can be done

4.1 Presentation of highlights

• It is important to present not only areas for improvement, but also the highlights of this code review, which can start with the following points:
  • Performance optimization: whether there is optimization of performance, rational use of database connections, time/space complexity, memory operations, etc.;
  • Design Patterns: Whether there is an abstraction of common design patterns that significantly improves module reuse, scalability, etc;
  • Tools/plugins: the availability of tool classes that improve efficiency, including plugins that can be published as well as customized annotations.

4.2 Rotational review

• It is important to note that the lead reviewer should be every member of the team, not just the department head or senior engineer for the following reasons.
  • Brainstorming: the most important aspect of each code review is to introduce new perspectives on potential problems; everyone will have their own perspective, and this helps the team to unify their understanding;
  • Equal Opportunity: Young engineers, while they may be inexperienced, may be more motivated and it would be good for the team to take this opportunity to get some exercise.

4.2 Documentation deposition

• With all of the above specific practices, then ultimately it is important to document and persist the results, which can be done specifically:
  • Before the review meeting, the main reviewer will prepare a document based on the template and present it at the meeting, including code snippets, suggestions for improvement, highlights, etc., so as to facilitate timely discussion and supplementation at the meeting;
  • After the meeting, it can be uploaded to the team's document space or work set, so that team members can learn and review at any time.

---

V. Summary of articles

On how to do a good job in the project development of CodeReview (code review) to share with you here, I hope to be able to help you some.

In conclusion, please correct any shortcomings and errors in the article. Or if you have something else to say, please feel free to share it in the comment section!