Learning how to write code is easy; it is writing maintainable code that is difficult. So what is this big fuss about maintainability all about? Every software developer starts out in their career as an individual contributor. Individual contributors have a fairly simple job: you get a set of development tasks which you must complete in a given amount of time.
While a lot of teams
focus on timely deliveries of their product/features, they do not focus on the
quality of the code being written. These so-called 'Agile' teams are okay to
pay the price in the long run. Ensuring that the code written is efficient,
error-free, and maintainable in the long run is the most vital part of
developing software. Two essential practices in this realm are code review and
refactoring. Both of these contribute equally towards the long-term
sustainability of the product, hence these practices must be a vital part of
the SDLC, and individual contributors must be made aware and take part in
these practices. Let's delve more into the importance, benefits, and best
practices.
What is Code Review?
Code review is a collaborative process where developers examine and evaluate
each others code to identify issues and improve the quality of the code-base.
This is also an opportunity for developers to share knowledge and key insights
from their personal experience. Code review should be done with the following
objectives in mind:
- Error detection: catching logical errors or bugs early.
- Knowledge sharing: team members should learn from each other's experiences.
- Design improvements: team members can suggest structural improvements in code.
- Consistency: ensuring that the coding style and use of utilities are consistent throughout the code-base.
- Maintainability: ensuring that the code is readable and extensible for future modifications.
It's a process:
Code reviews must be part of the shipping process. Once a feature is ready,
the developer should raise a PR / MR of their branch for merging upstream.
This should be assigned to a relevant senior development member on the team.
They should go through the ticket first and then should go through the PR / MR
raised by the developer. It is better if they involve the developer who wrote
the code during the review. This will help if the reviewer has any queries,
they can resolve those on the spot instead of waiting for a reply over Slack
or Teams. Whatever changes are required must be mentioned in the PR / MR as a
comment by the reviewer. The developer will then work on the changes and once
done again he will re-raise a MR / PR. Once this gets approved by the
reviewer, the ticket should move to a tech lead or any other senior most
technical person on the team. They will then review it one more time and if
everything is alright, they will go ahead and merge the code into the upstream
branch.
Benefits of code review:
Enhanced code quality: code reviews will help to reduce the chances of production incidents by eliminating the bugs before code merges.
Increased productivity: since there will be lesser bugs in the software, time for bug fixing and production issue fixes can be saved and used for something better.
Improved team collaboration: team members can learn from each other and gain insights into different parts of the code-base.
Comments
Post a Comment