El software es como limpiar la cocina

Uno de las premisas que he escuchado durante mi experiencia laborar en los sistemas informáticos es la siguiente frase: "Si funciona en producción no lo toques", frase escuchada una y otra vez, que nos indica en el buen sentido de la palabra, con letras despampanantes, marcadas en rojo y subrayado, que no toquemos absolutamente nada, para que todo siga tal y como estaba.

Cada vez que lo escucho eso me imagino esto:

Porque no?

la cocina sigue prendiendo fuego, el cuchillo sigue cortando, aah pero claro no toquemos nada!

De alguna manera es verdad, sería lo más lógico que producto de nuestras buenas intenciones algo deje de funcionar.

La manipulación del software genera incertidumbre por parte de los usuario del sistema y sería mal visto que nuestras buenas deseos terminen dejando algo sin funcionar en producción, Entonces pregunto:

¿Vale la pena tocar algo productivo que ya esta funcionando?

Yo creo que si, pero antes veamos algunos antecedentes importantes que vale la pena mencionar para entender más el contexto:

1. Entropía del software

Wikipedia nos indica que "es la medida de desorden del software que refleja la complejidad de su mantenimiento" (https://es.wikipedia.org/wiki/Entrop%C3%ADa_del_software)

1. Manipulación de código por muchos desarrolladores

Una de las grandes realidades de los productos es la manipulación del código por diversos desarrolladores que pasan por el sistema en función del tiempo, los que han tenido que realizar correcciones y/o nuevas implementaciones, adoptando el mismo estilo arquitectónico que poseía el software, implementándolo medianamente bien o de plano de forma incorrecta, o simplemente poniendo su propio sello en el código. Creando un código con muchos estilos y formas de mirarlo.

1. Poca expertis / tiempos de entrega

Un punto importante y no menor es la responsabilidad de muchas empresas en colocar a profesionales de nivel jr en puestos que requieren un conocimiento más alto. Muchos de ellos sin entender del porque están ahí, poniendo su mejor esfuerzo para sacar adelante la difícil tarea de entregar sus desarrollo a tiempo, luchando con tratar de entregar todo para ayer. Predicando la palabra de "stackoverflow es mi pastor", copiando y pegando código muchas veces sin entender, pero al fin y al cabo solucionando el problema puntual, creyendo que por que esta en stackoverflow es ley.

Entonces, ¿Cuales son los beneficios de modificar un código que ya esta funcionando en producción?

yo creo que muchos:

Limpiar la cocina antes de trabajar: antes de todo es muy importante limpiar donde vamos a trabajar. Limpiar el código fuente, factorizar funciones, normalizar nombres de variable, quitar código comentado, quitar código que no se ocupa, nos ayuda a entender que elementos tenemos disponibles para trabajar, a crear una mapa mental de donde va cada cosa tiene su propio lugar.
Quedarnos con lo que realmente importa: te has fijado cuando tienes el pelo largo o no te has arreglado en varios días, luego vas a la peluquería sales como una persona renovada? Esto es exactamente igual. Al quedarnos con lo que realmente es vital para un caso de uso, nos deshacemos de lo que no necesitamos, sacándonos ese peso extra que llevamos en nuestro hombros (en este caso en nuestro código), permitiéndonos una vez más aclara la visión de que tenemos que hacer y dónde lo vamos a hacer.
No trabajamos solos: han escuchado el que significado UX? de breves líneas vendría siendo (espero no me maten mis amigos Uxs): "entregar valor a cada uno de los usuarios del sistema, entendiendo sus dolores, haciendolos participes en la construcción de cambios, haciendolos los principales participes en cada uno de los punto de contacto de nuestros proceso". Dada esta estupenda explicación, tenemos que entender que nuestros pares son nuestros usuarios, y tenemos que hacer que en cada vez que tocan nuestro código fuente, sientan la mejor experiencia que puedan tener mientras trabajan.

Ustedes no se imaginan el dolor de cabeza que puede llegar a ser ver una ensalada de código arrojado, tirado y desparramado sobre una pieza de software. Pienso que si podemos hacer un código más legible para la siguiente persona que tocará el código todos saldremos beneficiado. Porque le haremos su trabajo más placentero y nos quedaremos con la sensación que la experiencia que vivió fue la mejor.

Entonces ya en este punto podemos preguntarnos ¿Cómo es factible asegurar que los cambios realizados no afecten el normal funcionamiento del sistema?.

A continuación te presento de manera breve algunas estrategias y/o principios que aplico cuando me veo enfrentado a este tipo de situaciones.

• Pruebas unitarias: Lo primero que necesitamos dejar en manifiesto es saber el comportamiento de lo que estamos modificando, la mejor manera es por medio de pruebas unitarias. La pruebas unitarias nos permitirá tener la capacidad de dejar en evidencia que los resultados finales no cambien. Esto es importante, porque necesitamos marcar un presedente de lo que estaba cuando comencemos a mover el código.
• Don't repeat yourself : Este principio, nos habla a grandes rasgos que cada elemento de nuestro código es único y dentro nuestro sistema no puede ser repetido. Principio de responsabilidad única: Principio perteneciente a los principios SOLID (wiki), que nos dice que cada una de las parte del código tiene que tener un sólo objetivo, una sola responsabilidad.
• SonarQube: Es importante tener bajo nuestro repertorio un marco de trabajo o estilo de programación. Sonar es el framework perfecto para aprender sobre la calidad del software. Es una herramienta que evalúa nuestro código y nos indica que parte de el se encuentra fuera de regla, regla que ha sido estandarizada por una comunidad que sugiere las buenas prácticas de programación.
• Eliminar código que no se ocupa: Es importante siempre siempre tener en nuestro sistema sólo lo que ocupa, lo no se va ocupar dentro del código a la basura, se ocupa? no. entonces borrelo.
• Eliminar código comentado: git! su mejor amigo es git, es el mejor mecanismo para el código que podría servir en un tiempo que jamás llegará. y si llega? revise el historial de la pieza.
• Tener presente la complejidad ciclomatica: La complejidad ciclomatica es la forma elegante de decir que el código es complejo de leer, dado la cantidad de clausulas ocupadas. Una función no debería tener más de par de líneas de código y debe ser simple de leer a ojo de lectura - Ojalá existiera la regla que indique que toda función sea escrita en lo largo de un tweets -.

Finalmente es importante destacar, que refactorizar un código no es una tarea fácil, siempre puede conllevar sin sabores, pero una vez que se consigue la gratificación es mucho mayor.

Nunca es tarde para intentar trabajar en una cocina limpia y ordenada!!!

Un abrazo.