From the beginning to work up to now, has written seven years of code, most of the code review had been, they would review a lot of people's code. In the company, I was responsible for an interview is devoted to training and experience to talk about the Code Review.
By doing the work in the Code Review / interview process, some of their own wrong practice sharing out tasks, we also welcome to discuss.
What must be done at all times Code Review
Code Review certain whether it is necessary? My answer is not necessarily.
I feel the need to sub-time, sub-project.
In the beginning of entrepreneurial companies, 1,2 two people Hangchihangchi the entire product from 0-1 to build out, Code Review neither condition (no one else can review), it is not necessary, the product will achieve, so that the project was alive is the most important.
Bug out on the line, the loss of hundreds of thousands of times every minute, apparently to emergency-based, such as Code Review lily is cold. Of course, here Points, if it is very obvious bug, for example, you are a well established conditions written backwards, so no nonsense hurry. If this change is not so light, so many eyes see it again tend to greatly reduce the chance of introducing bug again.
Code Review is mainly used to let others check the Bug
Code Review will be considered as a means to check the Bug others for themselves, may represent a considerable part of the programmer's idea.
Troubleshooting is indeed an important purpose in the Code Review, but should not be the only purpose.
In addition to checking Bug, Code Review or:
- Maintain code quality, it means the Uniform Code style. Everyone technical capabilities, diverse backgrounds, laissez-faire play can write a lot of different quality, different styles of code. By Code Review, it will be forced to maintain this level of code quality acceptable to all, and is the project's coding style uniform as possible.
- A mutual learning process. For starters, we can point out deficiencies in their code style, design, directly to "educate" others how to write code. Conversely, when the Review someone else's code, we can learn how the author is writing code, API how to call, what to use design patterns. Not only novice can learn from veterans, veterans who have many opportunities to learn from novices. I just learn some of the Java code for Review of JOOQ framework through graduate colleagues.
- A chance to understand the content of the work colleague. Programmers usually likely you're interested in their own development tasks, while their colleagues what they are doing, how to do, this information Code Review can be the most intuitive understanding. For example, your colleagues and you may need to change the same file, so you can know his thoughts changed to avoid conflict in the code before the merger.
Engineer needs to check the code of the primary Bug, senior code does not need to check Bug
In many cases, the code for junior engineers, we will be very enthusiastic to review, and there will be to find a code Bug and show their "senior" glory. But for a senior engineer to write code, or people do not give you built Code Review, or even if you added in the Code Review, also because of their status did not dare to put forward their views. Or we are all senior engineers gave full trust, Code Review request for their establishment is not how you look closely, directly LGTM (Looks Good To Me).
However, this is not right, junior engineer to write a small bug, senior engineer wrote fatal bug .
Junior engineer to do the task is relatively junior, and senior engineers to do the task will be more important. If you go to look at the company's major production accidents, accidents caused by the possibility of a senior engineer who is far greater than the junior engineer. This is "an accident are older drivers," "are drowned swim" for the same reason, "senior" engineer due to the farsighted focus on the design, but may ignore the details of the code. While the "Advanced" technical engineer for their confidence than enough, tend to ignore some basic self-testing and other sectors.
So, whether primary, senior engineer writing code, Code Review is necessary, but the focus may be different. Bug check on this matter, we believe that my colleagues on the strategic, tactical to suspect colleagues .
Code Review to raise this issue, the better
I met some of these "Code Review sprayer" At work, colleagues submitted a period of less than 100 lines of code, is eloquent raised at ten to twenty questions. Reply colleagues a bit on some issues his opinion, the two sides more than ten-story building built on a number of issues turnip cabbage. Results of the two three days later, debate still going on.
I was in was bombed this "violent" in the Code Review, in order to make all the Reviewer are happy, before and after the change dozens of times, each modification has a different colleague different opinions. And the last minute to a disagreement on the design, the code will be a major reconstruction and eventually was finally accepted (Accept). However, after the merger of code has appeared in low-level Bug, back checked, it is the last big reconstruction of the introduction of this bug. Why is there such a result? The longer a Code Review conducted, Author patience is getting worse, Reviewer increasingly focus only on their "hope" change you make, but belongs to the penny wise and pound-foolish.
If you submit a Code Review in too, for the review process is unfavorable. Each Reviewer memory is limited, it may be modified only remember the first secondary code. Review appeared in multiple submission, review the latest submitted before it will lose the context, I encountered problems can occur if one of the above Code.
Code Review We do not the purpose of the pursuit of perfection Code, the Code is not a perfect world, any code fragments, so long is long enough, can have areas for improvement. Everyone's perfect code is different, some people like to write, some people write like that. Without violating said earlier code quality, on the basis of a unified style, should abide by " Who wrote the code who call the shots principle".