Un verdadero Senior no pide permiso para Refactorizar

"Cualquiera es capaz de escribir código que una máquina pueda ejecutar. Los buenos programadores escriben código que otras personas pueden entender".

Estas palabras las pronunció Martin Fowler hace más de 20 años y siguen estando más vigente que nunca.

Aún hoy en día la mayoría de los programadores siguen dejando el código a medias.

Y si ChatGPT, Sonet, Llama (pon aquí el LLM que quieras) también.

Digo a medias porque aunque la funcionalidad esté completa el trabajo está sin acabar.

Me explico.

Que el código funcione no significa que esté terminado.

Y es que los developers muchas veces nos olvidamos de la otra mitad del trabajo.

La que tiene que ver con hacer el código sostenible.

Con sostenible me refiero a fácil de mantener.

Y con fácil de mantener quiero decir sencillo de cambiar.

Si, cambiar. 

Porque hay una verdad absoluta en el software: si un proyecto tiene cierto éxito cambiará.

¿Y cómo se consigue esto?

Pues escribiendo código basado en la simplicidad.

Y es que como decía Steve Jobs: la simplicidad es la máxima sofisticación.

El problema es que escribir código simple es una tarea tremendamente compleja.

Requiere de un nivel de consciencia y pragmatismo a la hora de codificar totalmente fuera de lo común.

Verás.

Cuando programamos desconocemos tantas cosas que vamos acumulando deuda técnica sin darnos cuenta.

A veces porque no nos preocupamos de pensar si la manera en la que estamos desarrollando una funcionalidad es la más simple.

O quizás sea por las prisas y la sensación de urgencia constante.

Otras ni siquiera somos conscientes de que estamos arruinando el código, simplemente ocurre por desconocimiento o falta de entrenamiento.

Desconocimiento unas veces de las necesidades reales del negocio y otras veces de la propia técnica.

La realidad es que nadie escribe el código perfecto a la primera.

Ni tú.

Ni yo. 

Ni nadie.

Por más cuidado que pongas (o por muy bueno que seas) cometerás errores de diseño que solamente se pueden subsanar de una manera:

Mediante la refactorización permanente, diaria. No hay otra.

Esto no lo escucharás nunca salir de su boca.

Lo que sí escucharás es que no hay tiempo para refactorizar, para hacer tests o para dedicar tiempo a un buen diseño.

Es cierto que existe la posibilidad de que cualquiera de nosotros termine dirigido por un micromanager.

Ya sabes, de esos que están todo el día encima de uno tocando las narices.

Aunque admito que esto puede ser un problema, descargar la responsabilidad en otras personas no es la solución.

Tenemos que preguntarnos dónde está el límite entre las tareas de las que somos responsables como programadores y las que son trabajo de otro.

¿A qué no le dices al manager cuantos condicionales o cuantas funciones tienes pensado escribir en el próximo sprint?

Sería ridículo hacerlo, ¿verdad?

Entonces, por qué pedimos permiso para refactorizar, hacer tests o dedicar tiempo a un buen diseño, en lugar de seguir haciendo ñapas…

Déjame adivinar, seguro que te dicen todo el rato:

“Ahora no hay tiempo para refactorizar, ya lo haremos cuando se pueda”.

A ver.

Esta frase tendría sentido si no se abusara de ella.

Hay ocasiones en las que esto es así pero está claro que no es la mayor parte del tiempo.

Y es que un producto de calidad no se puede desarrollar en permanente situación de urgencia.

Importante y urgente no son lo mismo.

Y no todo es igual de importante ni de urgente.

La realidad es que cuando tienes soltura refactorizando desarrollas más rápido que sin hacerlo porque ahorras tiempo depurando.

Verás.

El cuello de botella de los proyectos no está en el teclado.

La mayor parte del tiempo se esfuma tratando de entender el código para averiguar dónde hay que introducir los cambios.

Se malgastan mucho más recursos en leer y depurar el código que en escribirlo.

Por esta razón un verdadero Senior NO pide permiso refactorizar.

Un verdadero senior NO pide permiso para mejorar el código cada vez que tiene ocasión (pero si consensúa las decisiones que impactan en el negocio).

En realidad ningún programador que sepa lo que está haciendo debería pedir permiso para refactorizar.

No tiene que ver con ser junior o senior.

Ahora bien, pedir permiso para formarse es otra cosa…

Si no tienes experiencia ni haciendo tests, ni refactorizando y quieres empezar a hacerlo tienes que comunicarlo.

Sobre esto no hay duda al respecto.

Hay que entender que refactorizar es más que una tarea técnica.

Refactorizar tiene valor de negocio porque su función principal es asegurar que el lenguaje y el conocimiento del dominio están reflejados en el código.