El código de cualquier proyecto de software se va degradando, es algo con lo que tenemos que convivir diariamente en nuestra profesión.

Existen diferentes factores por lo que esto se produce como puede ser: tener poco conocimiento del problema a resolver, conocimiento del equipo en las tecnologías utilizadas, alta rotación en el equipo, prisas, presiones, cambios funcionales y muchos otros factores.

Para combatir la degradación que todo código sufre con el tiempo es muy útil aplicar la regla del Boy Scout.

La Regla del Boy Scout

EL Origen de esta regla proviene de los Boy Scout, de ahí su nombre, consiste en dejar el sitio donde se realiza el campamento un poco mejor de como se encontró al llegar.

Aplicado al mundo del desarrollo de software consistiría en que cada vez que tocamos un método, clase, o cualquier componente, deberíamos dejarlo un poquito mejor de lo que lo encontramos.

En muchas ocasiones puede consistir en pequeños cambios como renombrados, hacer más semántico el código, aplicar alguno de los principios SOLID, dividir un método grande etc...

Un arma de doble filo

Aplicar la regla del boy scout es un hecho subjetivo que depende mucho de la persona y su experiencia.

El problema surge cuando la interpretación que hacemos de esta regla nos lleva a realizar refactors de forma individual que no tocan en ese momento, con complejidad excesiva, sin pensar en el equipo o para satisfacer necesidades personales.

Según la interpretación que hagamos de la regla de boy scout puede ser una arma de doble filo.

Perdiendo la visión de equipo

Normalmente en un proyecto somos parte de un equipo y es importante ser conscientes de ello.

Cualquier decisión que tomemos al refactorizar cierta parte de código no solo va a afectar al proyecto, donde en teoría será para mejor sino también al equipo.

Hay ciertas decisiones que se toman a nivel de equipo como pueden ser de arquitectura, tecnologías a utilizar etc.. y es un error que empecemos a hacer la guerra por nuestra cuenta.

Algo que a mi modo de ver no sería correcto es que aplicando regla del Boy Scout por ejemplo decidir utilizar una tecnología distinta a la acordaba por el equipo porque nos gusta más o nos parece mejor opción y sin consensuarlo con el resto del equipo.

Sin refactor globales

Otra situación donde aplicar la regla del Boy Scout me parece un error es realizar refactors parciales y no comunicarlo de ninguna forma.

Por ejemplo imaginemos que tenemos grupo de clases en nuestro proyecto que siguen algún tipo de estrcutura en común, extienden de una clase base, implementan un interface o algo similar.

Creo que si identificamos una carencia o mejora en este tipo de clases, el mejor escenario es hacer ese cambio para todas.

Siendo realista la mayoria de las veces se podría considerar que me voy a desviar bastante de la tarea que estoy realizando, en este caso creo que lo mejor sería realizar el refactor en la clase o clases que afecta en mi tarea pero de alguna forma comunicarlo al resto del equipo.

Hay muchas formas de comunicar, la mejor forma de comunicar es no tener que comunicar porque estamos haciendo pair programming por ejemplo y de por si hay otro compañero que esta al tanto.

En las rotaciones de pair programming ese conocimiento se irá transmitiendo a medida que necesitamos pasar por un código similar.

Pero si no hacemos pair programming deberiamos evitar que ese refactor parcial quede en un hecho aislado donde solo nosotros estamos al tanto.

Elegir el momento

Para refactors menores renombrados etc.. casi siempre es buen momento.

Sin embargo en muchas otras ocasiones nos vamos a encontrar código que aunque es mejorable, es mejor no tocarlo en ese momento por no ser el más oportuno.

Para refactors que no son menores, hay infinidad de situaciones donde es mejor no involucrarnos en un refactor como puede ser el día de una release, cuando no conozco bien esa parte del código, cuando acabo de entrar a un proyecto y no tengo el conocimiento suficiente para estar seguro del cambio, cuando hay que resolver un bug de forma urgente, cuando no hay tests de esa parte y no voy a poder validar el refactor etc..

Para tomar este tipo de decisiones la experiencia juega un papel importante.

La Comunicación

La comunicación en un equipo es un pilar fundamental para que este tenga buena salud.

Si no hacemos pair programming, en muchas ocasiones antes de afrontar un refactor que no sea menor pedir ayuda o comentarlo con un compañero nos puede ahorrar tiempo.

Conclusiones

La regla del Boy Scout puede ser un gran aliado para luchar contra la degradación del software con el paso del tiempo.

Sin embargo también puede ser una arma de doble filo.

Creo que la clave es tener siempre presente cuando se está aplicando es para aportar valor al proyecto y comunicándolo de alguna forma.

La experiencia juega un papel importante a la hora de aplicar esta regla.

Realizar Pair Programming de forma frecuente y aplicar la regla del Boy Scout es la mejor combinación para mantener nuestro código limpio.