Let’s start by defining what we mean by code review: It’s a systematic examination of your source code, where basically what you are looking for is:
- Functional review: does the code do what’s supposed to?
- Tech issues/standards: is the code scalable? Is it maintainable? How about the performance? Are all the defined tech/security standards ok?
Sounds easy, right? However, many companies have issues to have a clear, efficient and defined code review process in place. So, what’s wrong?
Defining a code review process it’s not enough, you need to make sure that all your team is on board with the idea and that code reviews actually help the team’s productivity rather than making things even harder.
At Gitcolony, we help companies to build software faster by streamlining their code review process, making it much more effective and efficient.
We want to redefine the way code reviews are done. With this in mind, we wrote some good practices, no matter which tool you are using to manage your code reviews.
Good practices
- Have clear actionable items: it’s not enough to review your code and write emails with a list of bullets of things to improve than later nobody will read! Make sure you write a ticket in your preferred issue tracker, define a mechanism to follow it up or whatever it works for you, but make sure it doesn’t get lost.
- Early feedback & collaboration: don’t wait two weeks for a pull request to start reviewing the code. Partial reviews are very important for companies, so they can tackle issues before it’s too late, do a correct follow up on less experienced devs, get continuous feedback and have everyone in the dev team involved on the daily basis. This makes the review process much more actionable and meaningful.
- Everyone accountable: all the team must be on board, otherwise it will fail. If you have a great code review process in place, but then managers are always running behind schedule and skiping code reviews, it won’t work. Make sure you get buy-in from your team.
- Don’t take feedback personally: Code isn’t personal, you are not your code. Some people cannot take criticism. Some people cannot give feedback. Furthermore, some people take a code review as a time to make it clear to all how superior they are to others. Feedback should always be welcome, it’s a great way to keep learning all the time!
- No witch hunt, focus on the problem: the objetive of code reviews is to detect potential issues/improvements and learn from the process. Don’t allow developers who wrote the code to feel threatened and attacked, it will destroy any defined process.
- Everyone learns from the process, the reviewer and the coder: code reviews should be a forum where everyone can learn. The coder learns from the feedback he receives and the reviewer by reading other’s code. Code reviews are a great way to help junior developers to learn faster, specially about specific company’s tech and security standards, but also to get a better understanding of the business.
- Code review often and for short sessions: The effectiveness of your reviews decreases after around an hour. So putting off reviews and doing them in one almighty session doesn’t help anybody. Set aside time throughout your day to coincide with breaks, so as not to disrupt your own flow and help form a habit. Your colleagues will thank you for it. Waiting can be frustrating and they can resolve issues quicker whilst the code is still fresh in their heads.
- Review the right things, let tools do the rest: don’t spend time reviewing indentation and check style, there are great tools out there to manage that. Focus on the important stuff: functional review, scalability, maintainability, performance and other items that can’t be covered (at least for now) by computers :)
- Document all your comments, history is your friend: write any comment you have in mind, so you can search and get back in the future. If you have informal conversation, put a comment in your code/pull request after that so everyone is on the same page. If it’s not written, it doesn’t exist!
