The author works for JINGdong, and has a deep understanding of stability assurance, agile development, advanced JAVA, and micro-service architecture
Reading and reviewing code is part of every engineer’s daily routine, but a standard code review process is actually very difficult to implement, requiring that every code change be formally reviewed by another team member before it is deployed to production, or even submitted for incorporation. At LinkedIn, code Review has been a statutory and mandatory part of the development process since 2011, meaning it is an essential part of code quality assurance and knowledge sharing, with the goal of enabling team members to quickly upgrade their skills
Implementation of a corporate code review one of the biggest benefits is to promote the standardization of research and development process, each team in the LinkedIn company use the same tools or code review process, means that any one project can provide a review of the other teams help or contribute code, this eliminates the such as “I can fix errors in the code, But how do you build the code and submit the fix?” This in turn helps to increase collaboration between different teams in the engineering organization
By making code review a statutory process, we have established a healthy feedback culture in the company, where engineers are willing to give and receive feedback in their field, rather than just writing code. In fact, high quality code review experience is important in company promotion references, because it is the most direct objective evidence of engineering skills
Over time, we’ve developed some of the best practices and techniques for code review, as shown below, in the form of questions to get the most value out of both sides of the review
Do I really understand what the purpose of the code change is?
In order to speed up a high-quality code review process and effectively improve team skills, the code file submitted for each change should include a brief summary of the change, stating what the need or motivation was behind it, rather than having to extrapolate from the code change itself. In fact, writing documentation for submitted code is a process of reworking, where you may find that you have complicated the implementation of requirements and need to simplify them further, so you can go back and change the code to improve the design of the existing code, or even develop the habit of deducting things before you do them
Am I giving positive feedback?
Clean code and the height of the test coverage is taken for granted, however some code review too much concerned about the problem of code on how to modify the code to become better, this is very bad, most of them need positive feedback can get inspired and improve motivation, engineer is not exceptional also, we can’t ignore the value of positive praise. When reviewers find good design in code, they should mention it and give it credit. This kind of positive feedback can be contagious and energize the team
Is my code review comment clear?
As with all code submissions, any positive or negative feedback should not be empty talk, but should be explained in a specific way. If you feel that the code submitter may be confused by the feedback, over-explain rather than conciseness, which will cause more problems and require more back-and-forth communication. Of course, comments can also be very succinct, such as “eliminated duplicate code” or “increased test coverage,” which can help clarify the team’s values
Do I need to thank the submitter for his efforts?
Some code quality is not high, need to rework to write, in this case, the important is still to admit his efforts, he before may only be familiar with business degree is not enough, the best way is to provide high quality code review feedback and correct explanation, such as the proposed “thank you, every time always have good design” in the submit code such as words, Instead of writing code for him, it actually replicates your productivity to some extent in the long run
Can we benefit from code reviews?
This question allows us to assess very strongly and rudely whether code review is necessary. At the end of the day, engineers should treat code reviews like a helpful development tool, prioritize them over other work, and remove them if they don’t make a difference. Typical examples of meaningless code review reviews are those related to code formats that should be validated by automated tools and at the time of writing, not by engineers at the end
Is the “Test Completed” section thorough enough?
In code Review, you should not only review the submitter’s code, but also look at the tests that have been done. In addition to some unit tests, some may be manual tests. It is best for submitters to list all tested cases so that reviewers can make more testing recommendations and improve quality
Am I being pedantic in my review feedback?
Some code reviews put forward quite a lot of fixes on important issues rather than strong recommendations, i.e., paying too much attention to details and showing off all skills, slows down the whole progress, or even causes both sides to terrace level. Creating a clear, goal-oriented, proactive, and engaging code review process is a great way to avoid these problems
In conclusion, a standard code review process improves code quality, team skills, and knowledge sharing. When every engineer on the team realizes that other people are going to read my code, and I need to take the reviews seriously and make them better the next time I write code, that’s the key to growth and improvement
Source: www.liangsonghua.me
Liang Songhua, senior engineer of JINGdong, has an in-depth understanding of stability assurance, agile development, JAVA advanced and micro-service architecture
