Code Reviews are an essential component of the development cycle at almost every company. If you are not doing code reviews, you should probably start it.

Code Reviews is a process where before the code goes into production (or merged in master), some feedback is given on these code changes by a fellow developer. It is quite often the case when the developer misses out on some cases or unintentionally reduces code quality, with an extra pair of eyes such mistakes are avoided before they get to users.

Let’s answer the Why before How!

Why❓

• Identifying naive issues like debug statements, comments in commits.
• Helps in following best coding practices and principles 💻 resulting in a quality, maintainable code.
• Eliminates bug 🕷 which got introduced unintentionally.

Checklist 🚀

• No compilation errors, automated pipelines like code quality (which does static analysis + build) are passing.
• All tests are passing 💚 - both Unit and Integration and coverage is above threshold. (Run the code and test offline as well)
• No debugging statements or irrelevant comments 🤖
• Proper git log with proper messages. See, it commits are squashed.
• Check if PR clearly states what it does and there are no additional changes in code.
• See if there can be a simplified implementation for a function/feature.
• Are there are extra dependencies added? Can they be removed? Are they stable?
• Does it follow engineering practices like KISS, DRY, YAGNI?
• Check if any edge cases are missed.
• Proper logging and metrics is done. Are the logs relevant?
• Error is handled properly and not causes any fatal crashes ❌. (No downtimes, right! ). Code should be failure tolerant and should have a graceful shutdown.
• Ensure configurations are not hardcoded
• Check if API Documentation, README,md and Changelog 📄 are updated or not?
• Do these changes hamper the performance 📈 in any way? Is the response time increasing or are more DB calls are made?
• Do these changes need to be conveyed to other teams who consume this product/service.
• Are any security vulnerabilities 💣 introduced (usually there is separate whitelisting, but it’s good to do basic checks here as well)

Practices and Tips 💡

• Ask for shorter PRs. Shorter the PR -> Fewer issues + Easy to review -> Less time is taken to resolve if there are any issues. Don’t do reviews for more than 60 minutes!
• Clearly explain in comments what you think is missing or how can this be improved!
• Code should be as simple as possible. If it’s easy to understand and review, it will be easier to debug later as well.
• Code is properly broken into small functions, it follows engineering principles like SOLID, YAGNI, KISS and others.
• Proper naming and description for commits, code variables.
• Automate whatever you can. Use static analysis tools. Add CI/CD pipelines for compilation, build and testing.
• Don’t do code reviews in a hurry ⏰ Take your time - you never know even a small condition may introduce fatal bugs.
• Don’t be rude, show respect! Everyone makes mistakes 🤓

Resources 📚

• IBM practices
• Code Review Tools

Liked the article? Consider supporting me ☕️

I hope you learned something new. Feel free to suggest improvements ✔️

I share regular updates and resources on Twitter. Let’s connect!

Keep exploring 🔎 Keep learning 🚀