Code reviews play a pivotal role in today’s software development lifecycle, serving as a quality assurance mechanism and code-sharing platform. As software projects grow in complexity, ensuring the reliability, maintainability, and security of the codebase becomes increasingly challenging. Code reviews offer a structured process for developers to collaboratively assess code changes, identify potential issues, and provide constructive feedback when merging new code.
Code reviews potential downside is the time and resources required to conduct thorough reviews, which can introduce delays in the development process and impact project timelines. Additionally, code reviews may sometimes result in interpersonal conflicts or hurt feelings, particularly if feedback is perceived as overly critical or if there are disagreements about coding style or approach. Moreover, enforcing mandatory code reviews can create bottlenecks in the workflow if team members have conflicting priorities.
Another point I want to emphasize is that mandatory code reviews can create the impression that they should prevent production errors and bugs in the workflow. However, this is often not the case. In reality, it’s impossible to catch every aspect of a change without a full QA cycle. In some cases, the pressure of the review process can lead the individual being reviewed to make unnecessary or inconsistent changes simply to appease the reviewer and gain approval for their request.
Code reviews often come too late in the process. It’s a case of “too little, too late.” In the following text, I want to address some of the reasons teams are enforcing code reviews as a mandatory part of the workflow.
Code Review For Style Guide
We don’t have to block the workflow and wait for a code review to validate the style guide. Instead, we can utilize automated tools and adopt a Shift-Left approach, allowing us to receive continuous feedback throughout the development process.
Automating code checks with static code analysis allows us to enforce code styling effectively. By integrating tools into our workflow, we can identify errors at an early stage, while coding instead of blocking us at the end. For instance, flake8 checks Python code for style and errors, eslint performs similar checks for JavaScript, and prettier automatically formats code to maintain consistency.
If you’re actively testing your codebase, which I hope you are, consider integrating a code coverage automatic checker such as codecov. This tool can alert if the coverage drops below a threshold. While I’ve had positive experiences with such tools, it’s worth mentioning that the adoption process may pose some challenges.
It’s worth considering investing time and budget into automatic tools for checks done during the review process by us, particularly the more tedious ones. Consider investing in a code analysis service like SonarCloud, a personal favorite of mine. This approach allows us to maintain focus on achieving our objectives without getting bogged down in repetitive tasks.
Code Review For System Design
Code review validates the system design and ensures proper planning of architecture. reusing existing capabilities, avoiding redundant code flows, preventing duplication, and enhancing efficiency. I argue that evaluating the system design at the end of the process is misguided; investing more time in upfront planning ensures a cycle concludes with a sound design. What are the consequences of changing the design late in the process, and what are the outcomes of such adjustments? A drawback of this is the urge to implement and not invest enough time for planning.
I once had a debate with a colleague about time estimations in a TDD environment. We discussed the complexity of estimating tasks, recognizing that they include more than just writing tests. Tasks involve various elements such as planning, translations, data analytics, rollout plans, and testing is just one component. Evaluating tasks requires a holistic approach, considering all aspects including coding time, testing, and QA. It’s an art mastered by a few.
We need to have enough time for planning changes properly, allowing for discussions and consensus on architectural adjustments or understanding the necessary system modules for a feature. Neglecting proper planning can lead to unforeseen challenges later, resulting in higher costs in the long run.
“R&D stands for Research and Development. Sometimes, we forget the ‘R’.” – unknown
Code Review for Checkup Points
Code reviews frequently serve as checkpoints to ensure the integrity and consistency of feature design and system architecture across the codebase. The question arises is how do we validate changes? My stance is that this is a result of providing context and empowering developers to self-assess, seeking validation from peers when necessary.
We need to build an embracing ecosystem that fosters a sense of responsibility among individuals and empowers team members with a strong sense of accountability. This is a bug challenge that deserves its own post. It involves trusting and empowering to succeed, fostering growth with honesty and candor.
Creating this kind of ecosystem, combined with the context of change, works wonders. It enables team members to consult and offer input on changes beforehand, preventing roadblocks and fostering developer growth. I would argue that, even in the absence of mandatory code reviews, team members will seek reviews when necessary to ensure changes are implemented optimally. Only that way, the process of code review is positive by nature.
Code Review to Prevent Errors and Bugs
When reviewing code, we often hunt for nonsensical segments and offer feedback to clear potential bugs. However, I argue that this approach creates a false sense of confidence as one can not find all the bugs as we are exposed to human error and mental overload.
Code review is not a monitoring tool, but a code quality tool. Yes, it helps prevent errors and bugs. However, doing reviews is done at the end of each change and is inconsistent and costly. Instead, establish rollout plans with feature toggles and KPIs and integrate QA processes pre-production. Optimize the workflow for top developers and work your way so everyone aligns, rather than compromise to the lowest common denominator.
Conclusion
In my experience, I’ve worked in environments both with and without mandatory code review steps, serving in roles as both a developer and a leader. Interestingly, I found that when code reviews were mandatory, the process often felt burdensome and lacked enthusiasm from team members. On the other hand, in environments where code reviews were not mandatory, code reviews still happened often
and was highly valued, yielding significant benefits for the team.
The debate on whether to mandate code reviews continues, but perhaps it’s time to drop the restrictions and embrace a more agile approach. By leveraging automated tools, fostering a culture of accountability, and emphasizing upfront planning, we can simplify the development process without sacrificing quality. So, let’s bid farewell to mandatory code reviews and start on a journey toward more efficient and enjoyable coding experiences!
