No lo olvides: tu enemigo número uno como desarrollador de software es la deuda técnica.
Si llevas poco tiempo programando, enhorabuena: lo que vas a leer a continuación puede ahorrarte miles de horas de trabajo y hacer que tu carrera profesional sea mejor a lo largo del tiempo.
Algo que siempre me gustó de la programación es que el desarrollo de software presenta aspectos sutiles que son difíciles de comprender en un principio hasta que lo experimentas por ti mismo.
Quizá un buen método de aprendizaje consista en caer en todos los errores posibles y después darte cuenta de su solución, aunque lamentablemente eso, en el contexto de una compañía, supone pérdida de ingresos, proyectos fracasados y seguramente tu búsqueda de un nuevo empleo.
Con el tiempo y la experiencia, vas acumulando cierta sabiduría y ya sabes con antelación las consecuencias a largo plazo de hacer algo de un modo u otro.
Imagina qué ocurriría si durante un mes nadie se preocupa de recoger, ordenar y limpiar la cocina de tu casa. El primer día no pasaría nada; el segundo quizá ya sea algo molesto para prepararte un simple sandwich, pero desde luego, después de una semana, la cocina será un espacio sucio e intransitable. Sigue siendo una cocina, pero hacer algo en ella costaría cada vez más trabajo (aparte de lo asqueroso, claro).
Pues bien, muchas veces dejamos que nuestro proyecto crezca de ese modo (o nos vemos obligados en una dinámica de trabajo irregular, para “antes de ayer” y en medio de una gran desorganización); casi sin darnos cuenta, vamos dejando poco a poco piedras en el camino que se convertirán en rocas hasta que no podamos transitar más por él.
Una mente ingenua e inexperta podría pensar: si ya esto funciona, ¿para qué me voy a molestar?, ignorando que “sobre lo que ya funciona” habrá que incluir más funcionalidad o modificar la existente.
La deuda técnica se produce por un error muy frecuente entre los programadores, sobre todo los noveles: programar no consiste únicamente en escribir líneas de código y ya está.
Sí, vuelve a leer lo anterior una vez más.
¿De qué hablo cuando hablo de programar?
Rara vez ocurre que lo que haces a la primera sea algo perfecto y que no necesite ser tocado nunca más; menos aún en el contexto de un proyecto que crece casi siempre con requisitos que ni imaginas aún.
Esto es: hay que programar para que las líneas de código que escribes puedan ser modificadas más adelante.
Ese acto de “modificación”, sea para lo que sea, también es programar.
¿Funciona lo que has hecho? Puede que sí, pero ¿cómo te aseguras de que siga funcionando más adelante cuando el proyecto crezca? Creando pruebas, claro. Programar también consiste en desarrollar una batería de tests que cubran la mayor parte de tu código.
¿Tiene tu proyecto el mejor diseño posible? Salvo que seas un desarrollador muy experimentado, lo normal es que inicialmente el diseño ni se te pase por la cabeza; tan solo añades funcionalidad del modo que sea y ya está, más aún cuando las fechas aprietan y quieres volver a casa pronto (caso típico en el que surgen archivos de cientos de líneas de código = ausencia de diseño).
Sin embargo, sin diseño, tu aplicación es como el edificio cuyos cimientos, vigas y columnas fuesen de arcilla.
El diseño es la estructura de la aplicación que te permite añadir funcionalidad y mantenerla de una forma ordenada y eficaz (en el menor tiempo posible). Un diseño de calidad viene a ser como un plano o guía que permite comprender la aplicación mejor.
Diseñar, o mejorar el diseño existente, es también programar.
A medida que una aplicación crece, la vamos complicando necesariamente; de ahí que “simplificar” sea esencial para que ese crecimiento sea ordenado. ¿Simplificar qué? Nombres de función, algoritmos, extraer funcionalidad común, hacer más legible ese bucle, etc. No es suficiente que tú comprendas el código; lo tienes que hacer de modo que cualquier otra persona lo pueda entender con el menor esfuerzo posible.
Hay que programar para que otros asuman lo que haces con facilidad.
Todo eso debe formar parte de nuestro tiempo “programando”. Demasiadas veces he visto aplicaciones en donde la lógica de negocio está en su totalidad en una única clase de miles de líneas con un estilo de programación que difícilmente comprenderá otro que no sea su autor.
No respetar todo lo anterior, y consideraciones similares, supone añadir las piedras en el camino de las que hablábamos antes. Esas piedras son las deudas que se van acumulando de forma inevitable hasta que tú mismo te das cuenta de que añadir más funcionalidad, modificar la existente o depurar un error, es cada vez más difícil, cuando no imposible.
Tu trabajo como programador consiste en reducir la deuda técnica al máximo. Ésta es inevitable que se produzca porque es consustancial al desarrollo de software (otra frase que quizá debas leer de nuevo).
Es más, afirmo que parte del ciclo de desarrollo de una aplicación debe consistir en detectarla y mejorar cualquier aspecto del proyecto. Sorprendentemente, esa actividad creativa de mejora tarda menos de lo que pensamos y es muy gratificante, al menos para mí.
Esas mejoras pueden ser micromejoras que, a lo kaizen, con el tiempo van produciendo grandes cambios positivos en la aplicación.
(Extracto de uno de los capítulos del libro “Legacy Code: Cómo modernizar en catorce pasos código heredado o proyectos software que han crecido demasiado rápido”, disponible a partir del 5 de diciembre en todas las plataformas).
