Code reviews take an increasing place among software developers' teams. Recent reports on that topic indicate this is the No 1 way to improve code quality and has also social aspects such as mentoring and knowledge sharing. However, reports also highlight that around 45 to 49% of developers in the past few years were satisfied with the code review process.
Several factors can lead to this situation:
- High workload
- Tight deadlines and pressure
- Lack of workforce
- Reviews are time-consuming and repetitive
Let's focus on the last point in this post.
What takes time during code reviews?
If you're practicing code reviews, you're probably aware that this is often a 1:1 process involving a submitter and a reviewer. For instance, you're likely to use merge/pull features offered by Github, Gitlab, or Bitbucket and thus regularly write down comments to explain how the code could be improved.
Thus, you spend time explaining some concepts or some best practices (standards) in your team or your organization. However, we observe a common pattern with merge/pull requests: once they're closed, you seldom retake a look at them, meaning there is no capitalization process on their content.
And here comes the feeling of repetition: developers doing code reviews often have to explain the same concepts and same best practices during a 1:1 conversation, to multiple developers. At Promyze, we met plenty of Tech Lead confessing they're tired of this situation.
Code reviews have limitations for best practices sharing
As code reviews usually involve 2 developers, the scope of the discussions are limited to keep the focus on the code submitted. But the reviewer and the submitter may disagree on some coding standards or best practices and often postpone this discussion to later because all the team should be here to debate. As most teams don't have in their schedule such meetings dedicated to technical improvement and decisions, later means never.
Foster knowledge-sharing to save time in code reviews
The idea is simple: if we can improve the appropriation of best coding practices for software developers, they're likely to produce common mistakes in the code they submit for review, saving time for the reviewer.
That's how we designed Promyze, a collaborative platform dedicated to best practices definition and sharing. Developers can easily identify everyday best practices, followed or not, from the code :
- In their IDE (VS Code, JetBrains suite, Visual Studio)
- In their Web browser during code reviews (Github, Gitlab, Bitbucket, Azure DevOps)
Developers contribute to Promyze with examples and counter-examples extracted from their code.
Then, a 1-hour workshop takes place, gathering all the team. Note that such workshops can be organized within each team, across teams, within a community of practices, etc. In any case, they should be organized regularly, like every week or every two/three weeks, depending on your context.
In this workshop, all the contributions from the participants are reviewed one by one.
The team will discuss whether to validate each new practice or new example of best practice while sharing knowledge during this session dedicated to continuously improving our coding methods.
Promyze's plugins for code reviews can be used to identify best practices, followed or not, during code reviews so that everyone in the team will benefit from that.
A will to improve the code review process
Such workshops dedicated to best practices definition and sharing are not designed to end code reviews in companies. They are complementary since they help developers leverage their technical knowledge and avoid common mistakes in their code.
As best practices are better known, the overall process of back and forth between the submitter and reviewer is shortened. The code review can now focus on other aspects, and reviewers will progressively lose this feeling of repetition.
Top comments (0)