Code Review Practices: It’s Not as Difficult as You Think
Introduction
Code review is an essential and widely acclaimed practice when working in a team as a software developer. Approaching code review requires some level of attention, especially when working in a new team or a product you are new to, this inspired me to create a simple ios Code Review checklist which can be used regardless of the product and team structure, this also can be enhanced to help achieve productivity.
The goal of code review is to help teams improve code quality while adhering to the best coding practices. You will realize with time as you pay attention to this, that bugs are caught early in the development lifecycle, knowledge is shared, and estimation skills are improved while reducing development costs overall by following the suggested practice below:
- Make your code readable
Code readability is an extremely important part of code practice that could be underestimated. While paying attention to creating a working feature, it is also of great importance that the person reviewing your code can easily understand what you are doing.
Your code must be self-explanatory such that function and variable names are meaningful in the context of the application. Someone said if you need to add a comment to explain what you have done then probably the code is dirty and not understandable, so you need to check naming and logic to keep it simple.
Also follow the standard naming conventions (Pascal, CamelCase, etc.) as you make sure your code is properly aligned (left margin) while you remove unnecessary white space. Separate methods and functions should be easy to identify by using “MARK:-” where necessary.
2. Keep your code DRY
Checking for repetitions in the code you have written is very important before you submit your code for review. In doing this, always check if there is an existing method to perform something you’re trying to do.
I perfectly understand that sometimes due to strict deadlines, mistakes during design, or the kind of environment one works in, the temptation to make your code WET (Writing Everything Twice) instead of DRY (don’t repeat yourself) will be high. But always try your best to always write code in such a way that it’s reusable by other developers. You can discuss how you can better share resources within the company. The more we try to write and adopt this practice, the better we get at it, and before you know it, it becomes a part of you.
In summary, the same code should not be repeated in most cases, and make sure you remove unused code.
3. Make sure all feature requirements are met
It is of great importance that your PR covers all requirements outlined in a feature ticket. That is why it is of importance that the requirements are clearly outlined.
Have all requirements done before submitting a PR since you do not want to waste a reviewer's time reviewing a code that is still subject to changes before being merged to a staging or production branch.
4. Politeness in giving and receiving feedback
When you are reviewing someone’s work, always keep in mind that it is a presentation of several days of effort. While it's important we all strive for perfection in the quality of work we put out there, it is also of great importance to show some respect if mistakes are seen while reviewing your colleagues' code.
It is suggested that when comments are to be left, they should be in the form of a question or suggestion, because sometimes as a reviewer you might not understand the context of the challenge. Seeking to understand an approach in implementation will help keep arguments out; realizing that every approach has both negative and positive implications; the most optimized approach should always win.
‘’Never force software developers to change the code written by them. It may hurt their ego and they may repeat the same mistake if they do not understand the reason behind the code change recommendation. Highlight the issues in the existing code and its consequences.”
Here’s an interesting quote on this point: “If an egg is broken by an outside force, life ends. If broken by inside force, life begins. Great things always begin from the inside.” — Jim Kwik, Learning Expert.’’
5. Document your implementation process
Finally, whenever a new feature is added, kindly take time to update the existing documentation while making sure your document follows the standard.
Regardless of how clean your code is, without great documentation practice, it might cause an issue in the future. Documentation helps new developers understand an existing code base preventing time wastage while being onboarded into an existing system since it supplements human memory.
In essence, documentation is a bridge between members of a team which increases better communication will working on a project.
Conclusion
Code review is more about how we approach a codebase rather than a strict set of rules. It helps developers learn, improve and share knowledge; hence we should not be defensive or feel criticized when comments are given to make us better.
Finally, I will encourage you to always check your own code first! Examine all changes you’ve made before committing code!
These are the fundamentals that I consider when doing code reviews, which I learned over the years while working with extremely talented and exceptional individuals.
“By writing in a clear and consistent style, your programs become easier to read.” — Douglas Crockford
