Code Reviews are one of the most significant aspects of software development lifecycle. A crucial process where both the reviewer and the developer learns and teaches new things. For junior developers, this is one of the most important ways to get ahead in their software engineering careers. But sometimes reviews can do the opposite of what was actually intended.
Developers many times for the sake of dragging that story from "Under Development" to "Code Review" skip crucial steps that would be necessary for a clean and efficient code review process. Here are some things to check mark before you click that "Create Pull Request" button.
Complete end to end Dev Testing:
Yes we get it, your organisation is large enough to have dedicated QA team for testing each and every feature. But who is aware the end to end operations of the things just developed? Yes, its the developer. You can only explain so much during a KT in case the breadth of things are large. So do your homework and make sure that the thing works exactly you expected it to be before you hand it over to reviewers.
Use Tools like Sonar Lint:
When you pass it for review, you do not want reviewers to be commenting things like "Remove unused imports" or "use Stream api here". Things which can easily be caught using a Sonar scan. Most IDEs have such plugins. Or better ask your GPT of choice about options in which you can make that piece of code better.
Review Your own code TWICE:
Before you ask someone to review your code, you want to make sure that their time is not wasted in finding out something which you could have found out yourself. You want each and every comment on your PR to be a learning, not a mistake or miss from your side. Best way to ensure this is to change sides and review your own code as if it came from another fellow dev. Be strict and question everything. If you can explain yourself, you will be able to explain your reviewer too about a particular choice.
Some things to remember: no PR is perfect and developers should be be discouraged when their 5 line change PR gets 10 comments especially in the initial years of their career. Code reviews should be a discussion and not a "change this" task.
By following some basic practices, code reviews can be a great experience for both the reviewer and the developer.
See you soon. Until then, keep coding. And do not forget why you started.