Skip links

Save time during your code review on GitHub

Code review is 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 review 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 not involved in a PR don’t 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 Packmind web browser plugin for Chrome, Opera, Edge, or Firefox. Once the plugin is ready, you’ll see this new button during a PR review:

Code review on GitHub

In the Packmind 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 Packmind 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 Packmind 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: Packmind 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:

  • Packmind 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 Packmind extension to include in your PR comment a link to an existing best practice defined in Packmind.
  • 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 Packmind.

Want to give it a try?

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