Code reviews are great for ensuring best practices and educating developers. If you follow a basic set of principles, such as:

  • Favoring small pieces of code to review (no longer than 500 LOC),
  • Checking the code meets requirements before submitting a review (unit tests OK, documentation updated, …),
  • Being kind and respectful when providing comments and recommendations,

then you’ll likely enjoy the benefits of code reviews.

Code reviews should not be a burden

People practicing code review sometimes feel it gets time-consuming. This can be due to an inappropriate work distribution if one developer is assigned to review all the Pull/Merge Requests (PR/MR).

But it can also be explained by the frequent repetitions of explanations on best practices and coding standards. If a developer did not follow a best practice, you would write a comment in the PR. The PR author will then fix the problem, and finally, you’ll merge and close it.

However, you can’t be sure that another developer won’t make the same mistake later, and you’ll have to write down the same comment again. This happens because most of the code reviews remain within the scope of 2 persons: the author et the reviewer.

I’m sure you already thought:

“This comment I’m writing would be insightful for everyone in my team.”

However, developers who are not involved in a PR don’t really get through it.

Gain efficiency with your team on GitHub

Let’s find out a simple way to overcome that problem. First, you can just install the Promyze web browser plugin for Chrome, Opera, Edge, or Firefox. Once the plugin is ready, you’ll see this new button during a PR review:

In the Promyze terminology, a “best practice” is a coding principle that should be followed in your context regarding either language/framework usage, an architectural principle, any rules regarding performance, security, green-IT, testing. Thus, it could be any relevant knowledge in the context of your project or your organization.

In our example below, we highlighted that using the framework “moment.js” is not a bad practice, but we should use a dedicated service that manipulates dates in our context.

This simple action you’ve made will send the best practice proposal to the Promyze platform. Then, you’ll gather with your team for a workshop (1-hour max), usually happening twice per month (but of course, you decide on it), to review all contributions made by you or anyone in your team. Each contributor will explain their point of view, and in case this best practice is new in your Promyze workspace, you’ll have to either validate it or not. Such discussions are beneficial for learning from each other and making sure knowledge is spread across people.

Bonus: Promyze also offers plugins for IDEs (VS Code, JetBrains suite, Visual Studio, and Eclipse) to do the same job 😉

How do we save time next?

Thanks to this workshop, you made everyone in your team benefit from your knowledge and code review comments. For the following PRs, you’ll save because:

  • Promyze provides automatic suggestions in IDE and Web browsers by learning from your current knowledge base. So authors or Pull Requests could be notified if they don’t follow some best practices.
  • In case developers missed best practices, you can easily use the Promyze extension to include in your PR comment a link to an existing best practice defined in Promyze.
  • Developers will simply have a better knowledge of the best practices to follow since you and your team discussed it all together, thanks to a collective workshop in Promyze.

Want to give it a try?

Simply create your workspace on Promyze and start your trial with your team. If you have different teams in your company, you should know that Promyze has been designed to share best practices within a team and a whole organization.

Leave a Comment

Derniers articles

Technical Debt
Code Review Comment
Team communication
GitHub Pull Request
©2020 Promyze – Mentions légales