There are many options to improve your software quality.
One of the most effective methods is to do code reviews with other developers.
Code reviews are as much a social interaction as a technical best practice. In a healthy engineering culture (egoless), team members engage their peers to improve the quality of their code and increase their productivity. Developers understand that the time they spend looking at a colleague’s code is repaid when other team members examine their own deliverables. These days, most of the companies (e.g. Facebook, Netflix, Google, Amazon, Uber) are embracing it, so it’s another sign that something is working well here.
The important thing to remember when you are doing a code review is to be kind and to ask questions (clarifications) before you suggesting anything.
Why Ask For A Peer Review?
- The most basic reason is to find bugs.
If you won’t ask for it, you will miss bugs in your code:
a. Accidental errors – typos or mixing variables.
b. Structural errors – dead code, logic or algorithm bugs, performance or architecture concerns. These are often much easier to spot for an external reviewers the see your work from their perspective.
- You preventing from yourself a great way to learn and get better – Committers are motivated by the notion of a viewer who will look over the change request: the committer tends to clean up loose ends, consolidate TODOs, and generally improve the commit.
- Your code is not as clear as you think. Another developer will make it better both from its testability and readability aspects.
Code reviews are very important not only for developers but also to product managers, test engineers, designers and others.
In many cases, developers will be the first ones to see the benefits. It will allow them to move faster and with higher quality.
Benefits for developers
- Cleaner code that is more readable and testable –> Increased productivity.
- Better techniques learned from other developers.
- Reduced unit testing and debugging time.
- Less debugging during integration and system testing.
- Exchanging of information about components and overall system health with other team members.
- Less time spent performing rework and reinventing the wheel.
Data & Research
In the book Code Complete there are several good data points that came from case studies of peer review results:
- The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.
- IBM’s 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.
- A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.
- In a software-maintenance organization:
- 55 percent of one-line maintenance changes were in error before code reviews were introduced.
- After reviews were introduced, only 2 percent of the changes were in error.
- When all changes were considered, 95 percent were correct the first time after reviews were introduced.
- Before reviews were introduced, under 20 percent were correct the first time.
- In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.
What Not To Do
- Do Not ‘skip’ a review because of time pressure.
a. Communicate to your managers that in the triangle of
Time – Quality – Features you should only adjust the features when the time is a constant but never the quality.
b. Make sure that the project contains time for reviews.
- Do not use the reviews’ results to evaluate the performance of developers. You should be supportive and help the developer (and yourself) understand the code and improve its readability.
- Do not give feedback that is not suggesting a solution.
Always lead with a good example.