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»

La palabras de arriba 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.

Y precisamente esta es la razón por la que hemos creado esta formación.

Aquí tienes un breve resumen de lo que te encontrarás dentro:

✔ Qué es el Legacy Code y qué no. Y las técnicas más importantes para mantenerlo bajo control.

✔ Los 5 principios básicos que tienes que conocer para evitar que el código se te vaya de las manos.

✔ Las herramientas clave para que puedas transformar el código legado en un greenfield de nuevo. Con el tiempo, tendrás la sensación de trabajar como en un proyecto empezado desde cero.

✔ Dos conceptos fundamentales para escribir código simple y fácil de mantener. Dos conceptos que son como las leyes de la física del diseño de software.

✔ Buenas prácticas de refactoring. Aprenderás a distinguir qué puedes (y debes) refactorizar y qué no.

✔ El arte de mejorar la legibilidad y el diseño sin romper nada. Aprenderás a plasmar en el código el conocimiento adquirido sobre el negocio.

✔ Las 3 estrategias más importantes (+1 método) para refactorizar con éxito.

✔ Las 10 técnicas de refactoring con más ROI. Pondremos el foco en priorizar aquellos cambios que producen el máximo retorno de inversión con el menor riesgo.

✔ Un taller práctico, para que pongas a prueba tus habilidades, con ejercicios que muchas veces sorprenden hasta a los desarrolladores más experimentados.

✔ Los 20 Code Smells más importantes, junto con ejemplos reales, para que aprendas a diferenciar qué código puede ser potencialmente un antipatrón y cuál no.

✔ Siempre decimos que los tests son nuestra red de seguridad a la hora de refactorizar, pues en los videos sobre Testing Legacy Code aprenderás 4 estrategias para añadir tests a código difícil de probar.

✔ Una técnica muy simple pero efectiva que te ayudará a validar la calidad de tus tests antes de empezar a refactorizar.

✔ Una masterclass de Refactoring a Arquitectura Hexagonal que sin duda es más completa que muchos cursos de arquitectura que hay en el mercado (bien podría haberla vendido por separado). 

✔ En la sección Refactoring Frontend aprenderás a cómo meterle mano a un proyecto escrito en React muy enrevesado. 

Lo primero que haremos es aplicar algunas estrategias para poder añadirle tests y luego poco a poco iremos refactorizando, sin romperlo en ningún momento, hasta dejarlo encaminado.

Todo esto y lo mismo alguna cosa más (seguro) en la mejor formación que encontrás sobre refactorización.