Somebody toucha my spaghet!

I’m sure you have passed trough a moment like this.

A code review is a process in which the dev team checks up an implementation to come up with ideas on how to enhance it, or maybe refactor it, discovering possible bugs, architecture errors, missing test cases and several things that may happen. Now, you should be wondering: why in the hell someone else has to check my code, I’m such a programming guru… Well, yes, but actually, no.

When you are working in an organization, you should know that you are not the only one working on a project. On this context, socialism actually works (excepting your paycheck) because you are writing code that will be on constant development, enhancement and will require maintenance, all of this given by a bunch of developers in the future. Actually there are a lot of benefits on doing this exercise.

Knowledge is shared

  • People can discover tools, API’s and different ways to solve a problem that they were not aware of.
  • Obtain global knowledge about the system (Not only the components you are working on).
  • When new members join the team, more experienced engineers mentor the newer members. Often, teams have hidden knowledge within the code that surfaces during code review. Newer members, with fresh eyes, discover areas of the code base that need a new perspective. So, code review also helps ensure new insight is tempered with existing knowledge.

Keep in mind, code review is not just a senior team member reviewing a junior team member’s code. Code review should happen across the team in every direction. Knowledge knows no bounds! Yes, code review can help newer engineers, but by no means should it be used solely as a mentoring exercise. 

Code review pretends to

  1. Contribute with different points of view and to fix something that the developer may have forgot.
  2. Enhance the software quality and the code readability.
  3. Get the desired “code collectivity “

Let’s say that the code you wrote is already into production. Unfortunately, there is a bug in some code you wrote. This Math formula is code review in a nutshell:

G stands for how guilty you will fell
R stands for the number of people who reviewed your code.

How to review code?

As a code reviewer, you should ask:

  • Are there any obvious logic errors in the code?
  • Looking at the requirements, are all cases fully implemented?
  • Are the new automated tests sufficient for the new code? Do existing automated tests need to be rewritten to account for changes in the code?
  • Does the new code conform to existing style guidelines?

As a developer, you should ask yourself:

  • Is my code easy to understand?
  • Do I will be able to understand this code in a couple of years?
  • Did I consider every factor that may affect to the system?

But code reviews take time!

Sure, it takes time. But that time isn’t wasted–far from it; when the code review its done right, it actually saves time in the long run.

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: