Buscar en este blog....

martes, 10 de mayo de 2016

Code Reviews - Parte 1

Hace pocas semanas que se me ha encargado la implementación de Code Reviews en la empresa para la cual trabajo. Si bien yo ya tenía la idea de hacer esto hace un tiempo, ahora que está "la orden" dispongo de "más y mejor" tiempo para llevarlo a cabo. Y de forma seria, es decir, como un procedimiento formal.


Como suele pasar en muchas de las empresas que desarrollan software para uso interno, la calidad del mismo es más o menos cuestionable. Si bien el software "está funcionando", cuando hay que meterle mano para actualizar, reparar bugs, o agregar nuevas características, comienza la odisea de introducirse en esos códigos de cinco o diez años de antiguedad, sucios, emparchados, manoseados por diferentes personas de las que uno solo recuerda el nombre y con suerte alguna que otra anécdota.

El problema con esto es que cuando urge algun tipo de mantenimiento siempre es un peligro modificar ese código, porque como dije "ya está funcionando" y uno nunca sabe los efectos colarterales que puede producir al modificarlo.

Existen algunas formas de minimizar el impacto de modificar estos códigos, por ejemplo, la cobertura con tests. Si tenemos el código cubierto con tests, cualquier modificación que rompa el comportamiento se verá refejada en los test que fallen. Pero seamos sinceros: casi nunca existen estos tests, o menos aún están actualizados.

Entonces podemos aplicar una segunda técnica, más humana si se quiere, pero que si está bien aplicada puede, a futuro, allanar y simplificar gran parte del camino: los Code Reviews.

Los Code Reviews, o revisiones de código, consisten en sentar a una persona para que revise una porción de código que no escribió ella misma. De esta forma, puede detectar potenciales bugs, y algunas cosas que para los compiladores es más difícil o imposible: legibilidad y calidad del código. Por ejemplo, si un método es demasiado grande, o si recibe muchos parámetros, o si los nombres de los métodos o las variables no son descriptivos, etc. Si hay codigo redundante, o código duplicado, son todos aspectos que una persona puede identificar mejor que una herramienta, y aunque hay herramientas muy buenas, el "ojo humano" tiene ventajas indiscutibles.

En fin, retomando, voy a ir comentando un poco el proceso de code reviews que implementemos, que está basado ni más ni menos que la documentación disponible en internet, ya que convengamos que no hay ningún misterio ni secreto en este tema. En fin, más adelante iré comentando como me va con esta experiencia, y que en otra empresa en la cual trabajé se hacían code reviews, pero eran muy informales, sin ningún tipo de planificación, y sin una cultura organizacional que los acompañara, lo cual no ayuda en absoluto y los hace ver como "una molestia que tengo que sacarme de encima rápido para seguir adelante".

Saludos.

No hay comentarios:

Publicar un comentario

Comments are subject to moderation, only in order to avoid insults and disguising things.

Los comentarios están sujetos a moderación, solo con el fin de evitar insultos y cosas por el estilo.