5 Code Review Tricks the Experts Use - Based on 3.2 Million Lines of Code

for more like this, visit the takipi blog .

getting started with code reviews: here are a few tips to help you do it right

one of the work methods you’ll find in a growing number of companies is code reviews. while some might not like the idea of co-workers going through their code, others embrace it as a way to grow, learn, or simply prove how awesome their code is.

in the following post, we’ll go over some of the concepts of code review, highlight a few of the tools that are used in the process, and share our own experience with it. get ready to examen your coding skills.

what is a code review?

a code review is “systematic examination of computer source code.” this process aims to help find errors that might have been missed during the development phase, and improve the overall quality of the code and the product.

it’s like getting a second opinion on your code before you decide to move on with it. there are a number of review types, and the top 4 are:

• pair programming – 2 developers that work together writing and observing the code, as it’s typed, switching positions as they progress
• informal walkthroughs – the developers are lead through the product, allowing them to ask questions and comment on issues before they happen.
• tool-assisted – the review is done through code review tools.
• formal inspections – looking for defects using a defined process.

it doesn’t matter which type of code review you choose, the workflow stays the same: writing code, reviewing it, applying changes and so on until it’s ready for the next phase. the amount of cycles needed for each piece of code can alter according to deadlines, the importance of this specific feature, or the amount of nitpicking included.

how do you do it?

a few years ago cisco did a large (some might say, the largest) case study on lightweight code review processes. the 10-month study is based on 2,500 reviews and 3.2 million lines of code, that were written by 50 developers. it elaborates on the values and method of code reviews, as well as how they should be handled inside the company. here are a few takeaways we learned from it:

1. set the tone

first of all, since the code review process might sound a little intimidating at first – asking others to find the errors and issues in your code – it’s important to know what you’re doing.

you have to build a plan, talk with the dev teams about it, and explain how to give and receive a good or a bad review. in order for this process to work, it’s important to keep a non-threatening, collaborative environment in the team.

a good place to start is by letting everyone know that there’s no harm in finding errors. the goal is not to bring a certain developer down by “bashing” his code but help everyone understand how they can write it better.

2. comment all the things!

the first few code reviews might be harder, but not just for those who are being reviewed. if you want to help your teammates understand your code and workflow better, you should add comments to your source code.

not only will it help others review you better, it will make the code smarter and those who’ll arrive after a few weeks, months, or even years will know what you were trying to do.

3. line and time management

code review is important, but it’s critical to remember that it’s not the most important thing you have to do. there’s a long list of features to build, lines of code to write, and you don’t want yourself or your team to spend the whole day reviewing each other.

according to cisco, in order to get optimal effectiveness, developers should review fewer than 200-400 lines of code (loc) at a time. it also affects the ability to find defects within the code itself. the following graph shows the defect density against the number of lines of code under review that supports this rule.

in addition, cisco points out that the optimal inspection rate is less than 300-500 loc/hour. this rate allows developers to take their time with the review, analyze it, and find the issues that might be in it.

when reviewing at a faster rate of 400-500 loc/hour, the graph shows a severe drop-off in effectiveness, and when the rate goes over 1000 loc/hour, you can be pretty sure the reviewer is just scrolling through the code without actually checking it.

how much time should you actually assign to each review? 60 minutes is a good, round number that you should focus on. also, after an hour you’ll simply grow tired of the task and won’t be as efficient in finding errors and defects.

4. goals, goals, goals

getting the team on board with code reviews is a hard task. it has to be a part of the daily schedule, and go hand in hand with the existing tickets and assignments each team member has. we know the drill – there’s always something much more important to do.

one method of overcoming this is assigning a review as part of the ticket. that way, a reviewer has to go over the code in order to mark the task as completed. it helps the team to gain a wider view of the daily/weekly tasks, know what everyone is working on and, of course, add the code review to their workflow.

another method is setting goals and measurements for the review process itself. once you define specific goals, it will be easier to see when peer review is really achieving the results you require.

these goals can be anything, from “reduce support tickets” through “get lower bounce rate.” the only rule here is that it has to have a quantifiable measure, and not a vague “fix more bugs.”

once you’ve set the goals, each member of the team will be able to create his own checklist of points he should address when writing and reviewing code. keep in mind that goals are dynamic and adjustable, and as your code review process grows you’ll have a better idea of what you’re looking to solve with it.

5. see it through

the team is on board, everyone is sharing their knowledge, and code is being reviewed. that’s awesome, but what happens next? the review part is pointless unless the code is actually being modified and fixed accordingly.

it might be silly to point out the fact that you have to fix the errors in the code, but it’s important. issues that are found during the review are not a part of your usual testing process, and they might “get lost” and not be fixed.

make sure that every issue found as part of the code review is known by the original developer who wrote it, and that they actually fix it. this part might be a little tricky if you’re just getting started with code review, but important nonetheless.

this can be accomplished by reviewing tools such as github’s code review, review board, upsource by jetbrains, and others that show the changes in the code, allowing you to comment on them, change, or simply decline them.

why should you do it?

there are a lot of reasons why you should apply a code review routine in your team. it helps you see design issues and fix them before deploying the code, adjust the code according to the company’s design (if it exists) and it helps to make your code and application better. it also takes part in the company’s culture, helping juniors interact with the seniors and vice versa while creating a nurturing and a patient work environment.

while some dev teams prefer to have the tech lead review every piece of code, others might embrace the peer review concept. in the latter case, teammates review each other’s code before pulling it into production, or before handing it to the tech lead.

getting started with code review is not an easy decision and an even harder task. it’s even harder when you’re thinking about letting the teams review each other, and you have to build your game plan beforehand.

how do we do it?

full disclosure: we at overops had to do a lot of research before “opening up” our code review routine to peer code reviews. we talked with other companies, read some case studies, and found various opinions and methods on the web.

our conclusion was that it’s important enough for us to give it a go, and started doing peer code reviews in our teams. we’re still taking our first steps, but we’ve collected some guidelines to help everyone get on board. it’s heavily based on cisco’s research, along with ‘ code review best practices ’ by kevin london and ‘ the zen of code reviews: best practices ’ by michael sorens.

final thoughts

code reviews can be a big part of your company’s workflow and culture. not only will it help creating code standards for current and future team members, it will also allow everyone to think of the design before writing new features or adding lines to existing code.

with that being said, it might not be a good fit for everyone. smaller teams with tight deadlines, startups working in bootstrap models, or even big companies who simply don’t know how to do it right. it’s not a decision you should take lightly, and just like it can help your team, it can also cause it to break over ego wars.

spend the time to do the right research, talk with your team members and understand – is this the right move for your company and product?

for more like this, visit the takipi blog .