Esa búsqueda incansable del código perfecto
Si llevas un tiempo en este mundillo del desarrollo web, seguro que te suena la escena: pasas tres horas debatiendo en una Pull Request si ese componente debería ser un 'smart component' o si esa lógica de negocio debería estar en un servicio, un helper o un hook personalizado. Yo era ese tipo. Si te soy sincero, durante mucho tiempo me sentí más un guardián de la pureza del código que un desarrollador que soluciona problemas reales. Me obsesionaba con que todo fuera SOLID, con no repetir ni una sola línea de código (el famoso DRY llevado al extremo) y con que mi arquitectura fuera tan desacoplada que pudieras cambiar la base de datos por un archivo Excel sin despeinarte. ¿El problema? Que nunca íbamos a cambiar la base de datos y, mientras tanto, el cliente seguía esperando una funcionalidad que llevaba dos semanas de retraso.
Mi experiencia con la parálisis por análisis
Recuerdo perfectamente un proyecto en el que me empeñé en implementar una arquitectura hexagonal para un MVP que apenas tenía tres formularios y un listado. Me pasé días configurando puertos, adaptadores y entidades de dominio. Quería que el código fuera una obra de arte, algo de lo que sentirme orgulloso en una charla técnica. Pero la realidad me dio una bofetada en la cara. Cuando por fin tuve la estructura 'perfecta', los requisitos cambiaron. Y como mi arquitectura era tan rígida en su supuesta flexibilidad, tardé el doble en adaptarla que si hubiera escrito un código simple y directo. Fue frustrante. Me di cuenta de que estaba construyendo una catedral para una aldea que solo necesitaba una carpa temporal. Estaba quemando horas de mi vida y dinero de la empresa en resolver problemas que no existían, simplemente por el ego de seguir las 'mejores prácticas' a rajatabla.
¿Por qué me parece importante hablar de esto?
A ver, no me malinterpretes. Las buenas prácticas están ahí por algo. No estoy diciendo que ahora escriba código espagueti o que me de igual la calidad. Lo que digo es que hemos convertido las 'best practices' en una religión, y nos hemos olvidado del contexto. El contexto lo es todo en la ingeniería de software. No es lo mismo programar el sistema de navegación de un cohete que una aplicación para pedir pizza. A veces, la mejor práctica es la que te permite entregar valor hoy, no la que teóricamente facilitará un cambio que quizás nunca ocurra dentro de tres años. He visto a muchos desarrolladores juniors (y no tan juniors) sufrir una ansiedad tremenda por no estar aplicando el último patrón de diseño que leyeron en Medium, y sinceramente, esa presión nos está quitando la alegría de construir cosas que funcionen.
Lo que he aprendido en el camino
El gran cambio mental ocurrió cuando empecé a priorizar el valor real para el usuario sobre la estética de mis archivos .ts o .js. Aprendí que es mejor tener una función un poco larga que sea fácil de leer y de borrar, que una abstracción hiper-compleja con cinco niveles de indirección que nadie entiende. Ahora sigo una regla personal: 'Hazlo funcionar, hazlo bonito, hazlo rápido', pero en ese orden estricto. Muchas veces, si te quedas en el primer paso y entregas, el feedback que recibes es tan valioso que te ahorras el trabajo de los otros dos pasos porque descubres que la funcionalidad no era lo que el usuario quería.
Otra lección vital: el código es un coste, no un activo. Cuanto más código escribes, más tienes que mantener, testear y depurar. Por eso, ahora mi 'best practice' favorita es escribir la menor cantidad de código posible para resolver el problema. Si puedo resolverlo con una funcionalidad nativa del navegador en lugar de instalar una librería de 20kb, lo hago. Si puedo duplicar tres líneas de código en lugar de crear una abstracción genérica que cubra todos los casos posibles, lo hago. Y lo mejor de todo es que duermo mucho más tranquilo.
Reflexiones finales y un consejo de amigo
Hoy en día soy un desarrollador mucho más feliz y, paradójicamente, más productivo. Ya no me fustigo si un componente me queda un poco más grande de lo ideal o si no he usado el patrón de diseño más 'trendy'. Mi enfoque ahora es: ¿esto soluciona el problema del usuario?, ¿es lo suficientemente claro para que mi 'yo' del futuro lo entienda en seis meses?, ¿se puede entregar hoy? Si la respuesta es sí, tiro para adelante. Mi recomendación para ti, si te sientes atrapado en este bucle de perfección, es que te permitas ser un poco más pragmático. No dejes de aprender, no dejes de leer sobre arquitectura, pero usa ese conocimiento como una caja de herramientas, no como un manual de instrucciones inamovible. Al final del día, nos pagan por entregar software que funcione, no por escribir poesía en formato código.