Effective code review: 9 tips from a reformed skeptic

I knew the theory. A code review helps:

• Find bugs
• Provide readability and maintainability of the code
• Spread code knowledge to the whole team.
• Faster entry to work for new team members
• Show everyone new approaches to solving problems

Or, it’s just a waste of time. At least, this was my first impression of the review code.

I was a newly released newbie developing plugins for a software company in London.
After some time, I had to provide blocks of identical or similar code. They were supposed to be viewed by an unhappy guy (“He’s the best at this,” my manager said. Not a single good deed ... ( does not go unpunished ) process.
Worse, the code inspections lasted for days, if not weeks. When I received the code back, I could hardly remember how I wrote it. That was not the fault of that guy. He asked for a developer level senor, but got me. He was sick of the mistakes that inexperienced developers make, and reviewing the code was a way to get rid of this disappointment.
Add to this the time lost on synchronizing the branches, switching between contexts ... I was not a fan of this, there were none of them in the rest of the team, as it turned out.
Skipping a few years ahead, I find myself agreeing with Jeff Atwood's tweet:

“Collective review of the code is more you can do to improve your code.”

When I evaluate the past years, I realize that no review of the code was bad. The code review was bad. And, man, we spent it badly.
I learned it the hard way. And, of course, understanding does not come instantly. After a while, I realized that reviewing the code saved me from more than awkward, breaking assembly changes! But after I worked in other places, I gained experience in various and better ways to work. This gave me the opportunity to directly see the benefits of revising the code, which I had not previously recognized. So now I consider myself a reformed skeptic.
So you can avoid such pains: check out our video and then read the tips that will bring you closer to an effective review of the code.

9 tips on reviewing

For all:

• View only the most important, let the tools do the rest.
  You do not need to argue about formatting and code type. There are many tools that consistently resolve these issues. It is important that the code is correct, understandable and supported. Of course, style and formatting are part of it, but you have to give the tools a check on these things.
• Everyone must view the code
  Some people are better at this than others. A more experienced person may well find more errors, and this is important. But it is more important to maintain a positive attitude towards the verification of the code as a whole, and this will allow you to avoid the “We are against them” relationship, or that it is burdensome for someone to review the code.
• View all code
  No code is too short or too simple. If you are viewing everything, nothing will be left out. Moreover, it makes review part of the process, a habit, not a demand.
• Understand the positive attitude
  This is important for both reviewers and code authors. Code review is not the time to get all the fives and influence your coding skills.
  You do not need to take a defensive position. Come to the positive attitude of constructive criticism, and you can build trust in this process.

For reviewers:

• Code review should be frequent and short sessions.
  The effectiveness of your review decreases after about an hour. So postponing a review to view them all in one huge session will not help anyone. Find time during the day that coincides with your breaks - so as not to disrupt the flow condition and form a habit. Your colleagues will thank you for it. Waiting can be unpleasant, and they can resolve issues faster while the code is still fresh in their heads.
• Say “everything is good” is normal
  Do not be picky, you do not need to look for a problem in every review.
• Use the checklist
  Checklists for reviewing code provide consistency — they make sure everyone keeps track of important and common errors.

For authors of the code:

• The code should be short
  After 200 lines of code, the efficiency of the code is significantly reduced. By the time you look at the 400 lines, they are almost meaningless.
• Provide context
  Give links to any related tickets or specifications. There are tools for reviewing Kiln type codes that will help with this. Give short but useful commit messages and a lot of comments in the code. This will help the reviewer and you will get fewer questions.

Register now for the Kiln Review Code webinar.

Join our next online webinar. It will help beginners learn the basics about code inspections in our product.
We will discuss:

• What is code review?
• Why use code review
• When to use it
• What to watch during the review
• Create Review
• Comments in the review and responses to them
• Work with existing reviews
• Code review process

To take a seat, register now .
')