Poorshad Shaddel

Posted on Sep 12, 2023 • Originally published at levelup.gitconnected.com on Feb 28, 2021

10 Important Things That Improve Code Review

#softwareengineering #programming #softwaredevelopment

This is a summary of a few articles that you can find in the reference part.

0. Build and Test — Before Code Review

Use CI tools to check If tests are passing and the app can be built before starting the review process.

1. Use A Code Review Tool

Using these tools can save a lot of time. These tools can highlight changes and also you are able to interact with the developer or reviewer using these tools.

2. Set Early Expectations

The developer should annotate their source code before the review process. By having the authors carefully read through and annotate their own code, prior to giving it to their team for review, fewer defects were found.

3. Know What to Look for in a Code Review

You should have some questions in mind and you should look for answers. These are some questions you might ask yourself like these questions listed here:

Do I understand what the code does?
Does the code function as I expect it to?
Does this code fulfill regulatory requirements?
Think about libraries or existing product codes. When someone re-implements existing functionality, more often than not it’s simply because they don’t know it already exists. Sometimes, code or functionality is duplicated on purpose, e.g., in order to avoid dependencies. In such cases, a code comment can clarify the intent
Does the change follow standard patterns? Established codebases often exhibit patterns around naming conventions, program logic decomposition, data type definitions, etc.
Think about how you would have solved the problem. If it’s different, why is that? Does your code handle more (edge) cases? Is it shorter/easier/cleaner/faster/safer yet functionally equivalent? Is there some underlying pattern you spotted that isn’t captured by the current code?
Does the code adhere to coding guidelines and code style?
Does this code have TODOs? TODOs just pile up in code and become stale over time.
Does this code need integration tests? Sometimes, code can’t be adequately tested with unit tests alone, especially if the code interacts with outside systems or configurations.
Was the external documentation updated? If your project maintains a README, CHANGELOG, or other documentation, was it updated to reflect the changes?
Does this change break backward compatibility? If so, is it OK to merge the change at this point or should it be pushed into a later release?

4. Do A Certain Amount Of Code Review Each Day

Even If It’s Not Every Line. A developer will be more conscientious of their own code before code-complete is declared, it’s known a team of developers will be reviewing the code daily.

5. Don’t Review Code For Longer Than 60 Minutes

In many resources it is mentioned that you should not review for longer than 60 minutes at a time. Performance and attention-to-detail tend to drop off after that point.

6. Check No More Than 400 Lines at a Time

If you try to review too many lines of code at once, you’re less likely to find defects.

Defect Density vs LOC

7. Communicate Goals and Expectations

You should have goals and expectations in your code review process and an easy way to do this is by creating a code review check list that all developers should follow when they are reviewing each others codes. You can find examples of these check lists here:

8. Include Everyone in the Code Review Process

Usually people code better when they know someone is going to look at their code. No matter how senior the developer is, his/her code should be reviewed. The least benefit it has is that junior developers can learn from that senior developer by asking questions during review process and understand the code.

9. Give Feedback That Helps and Foster a Positive Culture

5.1 Feedbacks

It is groovy idea to ask questions instead of making statements. By giving praise you are telling your colleges that you are aware his/her effort so that person does not feel bad about your feedbacks.

5.2 Upset developers

Reviewers sometimes believe that the developer will be upset if the reviewer insists on an improvement. Sometimes developers do become upset, but it is usually brief and they become very thankful later that you helped them improve the quality of their code. Usually, if you are polite in your comments, developers actually don’t become upset at all, and the worry is just in the reviewer’s mind. Upsets are usually more about the way comments are written than about the reviewer’s insistence on code quality.

5.3 Fostering a positive

Fostering a positive culture around reviews is important. What matters is the bug was caught before it went into the product. And that should be celebrated. It is up to the manager to foster a positive attitude about finding defects. Code reviews offer an opportunity for all team members to correct bad habits learn new tricks, and expand capabilities.

5.4 Mentoring

Code review can have an important function of teaching developers something new about a language, a framework, or general software design principles. It’s always fine to leave comments that help a developer learn something new. Sharing knowledge is part of improving the code health of a system over time. Just keep in mind that if your comment is purely educational, but not critical to meeting the standards described in this document, prefix it with “Nit: “ or otherwise indicate that it’s not mandatory for the author to resolve it in this CL.

10. Establish a process for fixing defects found

Create a process to be sure that defects are fixed. In some code review tools like Github you can request changes and you can approve those changes only if the defects are fixed.

References

DEV Community