El problema: Nosotros
Somos programadores. Modelamos problemas de la vida real y los escribimos en un lenguaje que la máquina pueda entender. Lo probamos, y cuando funciona, lo ponemos al alcance del usuario. Todos felices.
Pero la historia no termina ahí. Algunos meses después producto viene con una idea nueva. Quiere agregar una funcionalidad que antes no estaba. Repetimos el ciclo anterior. Pero esta vez no es tan fácil. Porque nos tenemos que asegurar no romper lo que hicimos antes. Si fuimos medianamente vivos, tenemos tests automatizados de la aplicación que nos van a ayudar. Tiempo después vemos en el log un error 500. Nos metemos de nuevo en el código. Lo entendemos de nuevo. Encontramos el error. ¿Cómo no vimos esto antes?” Repetimos el proceso anterior.
Hasta acá, como el shampoo: Lave, enjuage, repita. Pero cada ciclo es más complejo. Y el principal problema somos nosotros. Somos humanos, no máquinas. El tiempo pasa, y no nos acordamos del todo en qué estábamos pensando cuando hicimos el diseño original. Tenemos un montón de clases, métodos y abstracciones. Nos tenemos que meter de nuevo mentalmente en el problema. Tenemos que leer el código. “No lo entiendo, vamos de nuevo”. Y lo volvemos a leer. “¿Por qué hice A y no B, que era mejor? Lo leemos de nuevo. Y caemos. “Ah… cierto, era por esto”. Logramos repetir el ciclo anterior. Todos felices.
-“Más funcionalidad es mejor.”
– “Por las dudas, agregalo”.
-“No va a pasar nunca, pero por las dudas, considero este caso.”
– “Agrego esta abstracción.”
– “Extiendo esto, porque en realidad conceptualmente…”
– “Por las dudas, dejalo configurable.”
¡Basta!
Cada día que pase, cada feature que agreguemos, cada abstracción que hacemos, el problema se agranda. Cada línea de código que agregamos ahora, es una línea de código que vamos a tener que leer mañana. O que va a tener que leer otra persona que no soy yo.
Pensemos en esta situación cuando vamos a diseñar. Mantengamos simples las cosas. No hagamos abstracciones que no sabemos si vamos a necesitar. Si, hagamos flexibles las cosas, pero hagámoslas flexibles en la dirección en la que creemos que es más probable que crezcan, no en todas las direcciones. No tenemos la bola de cristal, no sabemos para dónde puede llevarnos la aplicación y nuestros usuarios, pero podemos intuir.
En la facultad, en los cursos, en los tutoriales, nos enseñan cómo escribir código. Pero no nos enseñan cuando NO escribirlo. Cuándo parar. Eso lo tenemos que aprender nosotros, y es un problema casi tan complejo como aprender a escribirlo. Y también, es igual de importante. Desarrollar la capacidad de ir al punto, de solucionar el problema, y de ser flexible en la dirección necesaria, y no en todas las direcciones.
-¿Qué pasaría si NO hiciera esto?
– ¿Cuánto tiempo me costaría hacerlo configurable, si fuera necesario?
-¿Y si tuviera que redesplegar la app, cuánto me costaría?
Está bueno hacernos esas preguntas a la hora de agregar una línea de código. Ah, y ya se lo que estás pensando. Si. Este problema no lo descubrimos ahora. Ya mucha gente se topó con esto antes, y le pusieron nombre: KISS. (Keep It Simple, Stupid!) (mantenlo simple, estúpido) y YAGNI (You ain’t gonna need it) (No vas a necesitarlo). Recomiendo fuertemente leer estos principios. Les prometo que los autores de esas ideas las explican mejor que yo.