How To Do Code Reviews, The Right Way
Hey everyone! I’m going to talk about doing code reviews: what I look for, what questions I ask, and how I structure the review. Code reviews are one of the most important parts of developing quality code because of the feedback loop, and I’m always asked how I do them so I decided to share my process. I’m going to show you how I divide code reviews into three high level categories: Dependencies, Organization, and Recommendations. In each section, I’ll provide three questions to guide you towards an accurate assessment of the code.
To add more context: The scope of this article is for anybody who is writing a review of an entire project.
Dependencies
Dependencies are the foundation of your project, so like the roots of a tree, they must be strong. Otherwise the project could fall victim to being very unstable, and in the long run that creates lots of technical debt. If you’re not sure what technical debt is, I like to think of it as technical work / problems that have been identified but may or may not need to be addressed today. The longer you put off addressing technical debt, the more and more it grows. At some point, the project becomes to complex and the time it takes to resolve increases exponentially.
Here it is important to pay close attention to the libraries an app relies on.
For iOS, you will want to look at added frameworks in XCode, a ‘podfile’ for Cocoapods, and or a Carthage directory. On Android, typically Gradle is used and you can find the dependencies inside of the build file. Libraries that are provided by the system are generally considered to be stable, so are for the most part good choices. If the developer has chosen a library for added functionality, it’s important to do the research behind it.
Ask yourself these three questions:
- When was it last updated?
- Who maintains it?
- What are others experiences?
Organization
Developers function by concentrating on problems over several hours. They gradually create a conceptual model of the software and use it to create solutions. Well architected software aids this process. Good structure empowers developers by enabling them to think about problems at a high level.
At a low level every developer is equivalent. Learning to program isn’t actually that difficult. Architectural skill is what separates good and bad developers. Good developers write code that can be easily conceptualized.
Poorly structured code reduces every developer’s ability to contribute useful work. Even good developers lose their advantage. They can no longer reason at a high level and the quality of their work suffers.
Ask yourself these three questions:
- What design patterns do they use?
- Is the application design consistent?
- Is the system easily testable? i.e. Controllable & Observable components
Recommendations
I like to include a section for actionable steps that can be taken to improve the quality of the code. I find this to be one of the most valuable parts of a good code review because it’s more constructive to offer solutions to the identified problems. This is the step that’s most straight forward, least time consuming if you’ve done the previous, and yield the highest reward to the recipient.
Ask yourself these three questions:
- How can they improve the reliability?
- How can they improve the maintainability and efficiency?
- What is my overall assessment of the project?
Asking the right questions is the key to a good code review. I’m hopeful these tips will be useful to anyone who is writing one or curious to what makes a good code review. Thanks for reading!
Clap if you liked this. Comment to share your thoughts. Tweet @_rg2 and let me know what you think.
Visit my personal website: www.rodneygainous.com
