La belleza excepcional del código fuente es aquella que logra ser clara en lo que hace.
En la construcción de código, siempre nos enfrentamos a crear elementos de apoyo que son los que nos permiten escalar soluciones (fáciles o no tanto) en el futuro.
Pensar bien en el presente nos hace tener cimientos sólidos para que siga creciendo el software en el futuro. Con cada decisión podemos ir abarcando mejor la evolución del software, pero, en ocasiones, ese romanticismo del código "bien estructurado" compite directamente con el código que debe hacer lo que tiene que hacer.
Me ha tocado en un par de ocasiones hablar con personas que no comparten su código en forma libre diciendo: "está mal hecho" o "no seguí normas". Yo también fui parte de ese grupo. Con el tiempo comprendí que un código mal escrito (sin formato, normas, etc.) es, en ocasiones, lo que permite que un experimento o una idea loca se aplique y validar si funciona o no.
Obviamente, después hay que dedicar tiempo a embellecerlo o al menos, asegurar que si un próximo humano que lo lea, comprenda qué es lo que se trae entre manos el código.
¿Cuál es mi postura?
- Validación primero, belleza después: Si el código hace lo que debe, ¡celebramos con un café! Ya habrá tiempo para refactorizar y "embellecerlo" para el próximo humano que lo lea.
- Cero vergüenza: Compartir el código "sucio" es un acto de honestidad técnica. Permite detectar errores antes y colaborar sobre la realidad, no sobre una quimera de perfección.
- Cimientos, no adornos: Prefiero mil veces un sistema con cimientos firmes y terminaciones rústicas, que un edificio de cristal con bases de arena.
No hay que sentir vergüenza por lo hecho: si hace lo que queremos ¡bien!, podemos tomarnos un café e ir a celebrar.
