Había una vez que se era un proyecto, en el cual, por primera vez y sin que sirva de precedente, ningún Sky Manager Relaximent (me pirra la heráldica de los cargos en Linkedin) me “recomendó” usar un framework en particular, me “incitó” a adoptar la solución fácil, me “empujó” a implantar una tecnología que,  por muy prefabricada que fuese, en muchas ocasiones no satisfacía al 100% nuestras necesidades.

Al principio era muy extraño, ahí estaba yo, con un sublime text en blanco, o en negro -si usamos monokai- ¿Cómo empezaba?, ¿Por dónde tendrían que ir mis zanjas rellenas con los primeros cimientos?. Cuando todos hablan de arquitectura, suelen hacerlo de manera impropia, casi siempre suelen hablar de librerías, frameworks, piezas que suponemos nos facilitarán un desarrollo mantenible, escalable -e inserte aquí cualquier otra palabra que hayamos enumerado como requisito mínimo de un proyecto-, aunque pronto nos dimos cuenta que elegir cualquiera de estas soluciones traía un problema, el problema de que lo que conocemos del framework es solo la punta del iceberg.

¿Y sí el problema es que estamos sustentando todo nuestro proyecto en algo que muchas veces desconocemos, no compr, en estos proyectos se desarrollaba una capa que envolvía la solución escogida, intentando simplificar y personalizar su interfaz con el desarrollador, en vez de entender el framework, formar a las personas, controlar la situación.

Así que me decidí por el TDD, y desarrollar una arquitectura modular apoyándome en ésta metodología. Después de las recomendaciones de nuestro coach técnico, quería intentar por una vez hacer el mínimo código necesario e ir abstrayendo líneas de código patronizable hasta lograr obtener algo susceptible de llamarse arquitectura.

Era muy de esperar que la gente pronto se pusiera nerviosa, era algo a lo que no estaban acostumbrados, era algo que no daría billetes al segundo día, era algo que no daría problemas al segundo día. Y claro, empezó la paradoja “que sea azul pero que se parezca al rojo”, “haz TDD pero no refactorices nada”, vamos a hacer TPD … test por planificación desastrosa.

Siempre me ha gustado la gente que va a cenar sushi al punto, es tan cuqui…

Además, quien haya probado esto del TDD, sabrá que hay que escuchar al código, que te va diciendo lo que necesita, eso sí, la arquitectura javascript floreciendo, es como las vitaminas del zumo, o las tomas a su debido tiempo o se pierden, y si las pierdes, tienes un buen ñordo del que es muy difícil la vuelta atrás. Por esto, el refactor debe ir integrado en el mismo flow de desarrollo del TDD.

Cansado de recordar a todos, que a veces, es más importante el MPGV: mínimo producto ganador viable. Y así me quedé en ese proyecto como _la cabeza de un ciervo colgado en la pared, hasta que cambié de proyecto, donde todo fue mejor, o peor, según se mire. Pero eso, ya es otra historia o la misma que se repite.