An essential step in the software development lifecycle is code review. Code reviews are powerful means to improve code quality, establish best practices, opportunity to learn, and knowledge sharing and mentoring, as well as promotes team cohesion.
What to look for in a code review? Try to look for things such as ๐ฑ๐ฒ๐๐ถ๐ด๐ป (does this integrate well with the rest of the system and are interactions of different components make sense), ๐ณ๐๐ป๐ฐ๐๐ถ๐ผ๐ป๐ฎ๐น๐ถ๐๐ (does this change is what the developer intended), ๐ฐ๐ผ๐บ๐ฝ๐น๐ฒ๐ ๐ถ๐๐ (is this code more complex than it should be), ๐ป๐ฎ๐บ๐ถ๐ป๐ด (is naming good?), ๐ฒ๐ป๐ด. ๐ฝ๐ฟ๐ถ๐ป๐ฐ๐ถ๐ฝ๐น๐ฒ๐ (solid, kiss, dry), ๐๐ฒ๐๐๐ (are different kinds of tests used appropriately, code coverage), ๐๐๐๐น๐ฒ (does it follow style guidelines), ๐ฑ๐ผ๐ฐ๐๐บ๐ฒ๐ป๐๐ฎ๐๐ถ๐ผ๐ป, etc.
Code review is a conversation, not a queue of commands.
Code review checklist
A checklist helps you to create a structured approach to code reviews. Also, they remind you of all the quality checks you need to perform to approve code into the codebase.
๐ญ. ๐ง๐ฟ๐ ๐๐ผ ๐ฟ๐ฒ๐๐ถ๐ฒ๐ ๐๐ผ๐๐ฟ ๐ผ๐๐ป ๐ฐ๐ผ๐ฑ๐ฒ ๐ณ๐ถ๐ฟ๐๐
Before sending a code to your colleagues, try to read and understand it first. Then, search for parts that confuse you.
ย
๐ฎ. ๐ช๐ฟ๐ถ๐๐ฒ ๐ฎ ๐๐ต๐ผ๐ฟ๐ ๐ฑ๐ฒ๐๐ฐ๐ฟ๐ถ๐ฝ๐๐ถ๐ผ๐ป ๐ผ๐ณ ๐๐ต๐ฎ๐ ๐ถ๐ ๐ฐ๐ต๐ฎ๐ป๐ด๐ฒ๐ฑ
It should explain what changes were at a high level and why those changes were made.
๐ฏ. ๐๐๐๐ผ๐บ๐ฎ๐๐ฒ ๐๐ต๐ฎ๐ ๐ฐ๐ฎ๐ป ๐ฏ๐ฒ ๐ฎ๐๐๐ผ๐บ๐ฎ๐๐ฒ๐ฑ
Automate as much as you can
PMD, FindBugs, and Checkstyle are the most popular code analyzers,
Jenkins for CI-CD ,code smells and bugs (SonarQube).
๐ฐ. ๐๐ผ๐ปโ๐ ๐ฟ๐๐๐ต
You need to understand what is changed in every line of it. Read multiple times if required, class by class.
๐ฑ. ๐๐ผ๐บ๐บ๐ฒ๐ป๐ ๐๐ถ๐๐ต ๐ธ๐ถ๐ป๐ฑ๐ป๐ฒ๐๐
Never mention the person (you), always focus on changes as questions or suggestions and leave at least one positive comment. Explain the โwhyโ in your comments and suggestions for improving it.
๐ฒ. ๐๐ฝ๐ฝ๐ฟ๐ผ๐๐ฒ ๐ฃ๐ฅ ๐๐ต๐ฒ๐ป ๐ถ๐๐ ๐ด๐ผ๐ผ๐ฑ ๐ฒ๐ป๐ผ๐๐ด๐ต
Donโt strive for perfection, but hold to high standards.
๐ณ. ๐ ๐ฎ๐ธ๐ฒ ๐ฟ๐ฒ๐๐ถ๐ฒ๐๐ ๐บ๐ฎ๐ป๐ฎ๐ด๐ฒ๐ฎ๐ฏ๐น๐ฒ ๐ถ๐ป ๐๐ถ๐๐ฒ
We should limit the number of lines of code for review in one sitting. Our brains cannot process so much information at once. The ideal number of LOC is 200 to 400 lines of the core at one time, which is usually 60 to 90 minutes.
8. Review logic, not semicolons
Automation reduces the needless checks and letโs you focus on the logic behind the changes rather than syntax errors and typos.
What is your code review process? What works for you, and what does not?
When it comes to code reviews, itโs a common phenomenon that there is much focus and long-winded discussions around mundane aspects like code formatting and style, whereas important aspects (does the code change do what it is supposed to do, is it performant, is it backwards-compatible for existing clients, and many others) tend to get less attention.
To raise awareness for the issue and providing some guidance on aspects to focus on, I shared aย small visualย on Twitter the other day, which I called the โCode Review Pyramidโ. Its intention is to help putting focus on those parts which matter the most during a code review (in my opinion, anyways), and also which parts could and should be automated.
As some folks asked for a permanent, referenceable location of that resource and others wanted to have a high-res printing version, Iโm putting it here again:
FAQ
- Why is it a pyramid?
The lower parts of the pyramid should be the foundation of a code review and take up the most part of it.
- Hey, thatโs a triangle!
You might think so, but itโs a pyramid from the side.
- Which tool did you use for creating the drawing?