This content originally appeared on Level Up Coding - Medium and was authored by Poorshad Shaddel
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.
- Review Board
- Crucible
- GitHub
- Phabricator
- Collaborator
- CodeScene
- Visual Expert
- Gerrit
- Rhodecode
- Veracode
- Reviewable
- Peer Review for Trac
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.
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:
- Code Review Checklist - To Perform Effective Code Reviews
- Your Code Review Checklist: 14 Things to Include
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
- 9 Code Review Best Practices | Perforce Software
- 12 Steps for an Effective Code Review Process [INFOGRAPHIC]
- The Standard of Code Review
- Best Practices for Code Review
- The Standard of Code Review
- Code Review Best Practices
- 12 Best Code Review Tools for Developers (2021 Edition)
10 Important Things That Improve Code Review was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Poorshad Shaddel
Poorshad Shaddel | Sciencx (2021-02-28T16:28:26+00:00) 10 Important Things That Improve Code Review. Retrieved from https://www.scien.cx/2021/02/28/10-important-things-that-improve-code-review/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.