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 que te ahorre miles de horas de trabajo y 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 de modo que 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á, es ya algo molesto 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 de 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 es algo perfecto que no necesita 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 donde 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 lo va a 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 vas dando 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 lo es 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).

Legacy Code

 

Comparte esta entrada...

De qué hablo cuando hablo de programar (volumen 1)

PD: artículo revisado, corregido y mejorado en mi libro "De qué hablo cuando hablo de programar (volumen1)".

Todos mis libros

Todos los libros de Rafael Gómez Blanes

Mi último libro: De qué hablo cuando hablo de programar (volumen 2): Cómo avanzar mejor y más rápido en tu carrera como desarrollador.

Si quieres conseguir una carrera de éxito desarrollando software y saber cómo evitar los errores habituales, lee El Libro Negro del Programador best seller en su categoría en Amazon), o adquiérelo ya aquí.

Si quieres conocer las principales técnicas de desarrollo ágil, código limpio y refactoring, lee El Libro Práctico del Programador Ágil, o descárgalo ya aquí.

Si estás de acuerdo conmigo en que somos seres de hábitos, conviértete en mejor profesional leyendo The Coder Habits, o consíguelo ya aquí.

Los tres libros técnicos los tienes ahora a tu disposición en el pack La Trilogía del Programador Profesional, léelo ya.

Si tienes un proyecto que gestionar y no sabes cómo, aprende metodología lean y lee El Método Lean MP, o adquiérelo aquí.

Si quieres emprender y desarrollar un proyecto digital, lee El Arte del Emprendedor Digital

Las Doce Claves, las claves de desarrollo personal extraidas de El Arte del Emprendedor Digital

Para tratar con código heredado: Legacy Code: Cómo modernizar en catorce pasos código heredado o proyectos software que han crecido demasiado rápido

Mis libros en todas las tiendas:

Amazon
Google Play
Apple
Kobo
Barnes and Noble
Scribd
Smashwords
Payhip
Gumroad

Rafael Gómez Blanes Rafael Gómez Blanes
¿Hablamos?

 

Trabajo en...

Archivo

Mis novelas...