Rimorsoft Online
Blog Foro

Qué es la deuda técnica


Este es un término muy manejado en los equipos avanzados de programación, los equipos chicos la mantienen pero no saben que está allí acechando.

Acechar: Vigilar, mirar en silencio, aguardar cautelosamente. Acechan pacientemente.

Pensemos en la deuda técnica como en una expresión usada por nosotros los programadores para referirnos al código de mala calidad. Se le llama "deuda" porque genera inmediatamente la obligación de pagar y a veces con altos intereses.

youtube

Dos cosas a tener en cuenta.

  1. Podemos introducir deudas técnicas al decidir no implementar testing en el proyecto.
  2. Podemos introducir deuda técnica al pensar que más adelante tendremos tiempo para refactorizar.

Debemos tener la certeza de que existen muchas deudas por pagar debido a que alguien del equipo mencionó lo siguiente: "empecemos de cero porque ya sabemos cómo debemos hacerlo" ...y ese alguien puedes ser tú.

Conseguimos este resultado si trabajamos con una imprudencia "justificada", es decir, debido a la velocidad, al poco tiempo que se tiene, al cambio constante del personal, etc. Incluso con la imprudencia debido a la ignorancia originada por un novato o "junior" ascendido a avanzado o "senior" por circunstancias de la vida (como mencioné en twitter). Estos son los errores que más comprometen porque generalmente no hay forma de ir atrás y reparar.

El conocimiento que se tiene también es un factor determinante, puedes empezar con cierto rumbo y a medida que avanzas en el proyecto y pasa el tiempo comienzas a desarrollar otro tipo de consciencia que te ayuda a entender otros mejores diseños y formas de implementar. En este punto solo debemos evaluar si es necesario pagar la deuda en ese momento o si se puede aplazar de manera planificada.

Incluso, como reflexión final de esta sección te puedo comentar que es muy común heredar un proyecto con muchas deudas técnicas y de hecho ese es el principal motivo de traspaso.

Refactorización

Es importante saber que la deuda técnica es definitivamente inevitable a pesar de sus consecuencias negativas.

Lo único que debemos hacer como profesionales es que sea inducida a conciencia con la responsabilidad de pronto pago. Y esto por supuesto puede hacer que te surja la siguiente pregunta, ¿cómo se paga una deuda técnica? Mediante la refactorización.

En términos sencillos la refactorización es un fino proceso que tiene como objetivo mejorar el código anteriormente escrito sin cambiar el comportamiento para que sea fácil de mantener, entendible por otros programadores y lo más importante que sea tolerante a cambios (la refactorización debería ser un paso común y obligatorio).

Lo imprescindible en este caso es el testing, no podemos refactorizar sin ello porque es la única forma de comprobar que el código cambiado sigue cumpliendo con los requisitos o con lo solicitado. Otra manera de decirlo es que si refactorizamos sin testing no tendremos verdadero control, yo diría que si cambiamos nuestro código con la intención o deseo de mejorarlo pero el proyecto está sin testing conseguiremos un desastre como resultado, de hecho cuando trabajamos sin testing tenemos el mantra "no lo toques", precisamente por el riesgo que corremos al intentar alterar alguna función o pieza cualquiera del proyecto.

El testing involucra como paso necesario a la refactorización, incluso de manera natural nos da el criterio de saber cuando debemos refactorizar. Generalmente refactorizamos al detectar poca calidad y debemos hacerlo muy a menudo precisamente porque es un buen método para recordar qué se hizo el día anteriormente.

Tomemos en cuenta que esto es algo que podemos prevenir en gran medida porque el código de mala calidad lo termina pagando alguien, quizás tú con tu puesto de trabajo o manteniendo el empleo gastando más horas en reparaciones que en nuevas implementaciones sobre un sistema frágil, el cliente siempre sufrirá respecto al dinero y así continúa una cadena de desaciertos.

Debemos saber que esto existe principalmente para evitarlo al máximo, trabajado precisamente con clean code, SOLID, TDD y muchos de estos conceptos asociados a las diferentes normas establecidas como buenas prácticas.

  1. Testing.
  2. Don't Repeat Yourself.
  3. ...

Conclusión

Debemos analizar si se puede tolerar algo de deuda técnica respecto al beneficio del proyecto, lo único a tomar en cuenta es el pago responsable y a tiempo. Recordemos que el peligro real se presenta cuando no pagamos, hablamos del incremento significativo de los intereses hasta el punto de hacerlo impagable.

Consideraciones y reflexiones.

  • La experiencia nos dirá cuándo debemos refactorizar.
  • De manera natural descubriremos pronto el código con poca calidad.
  • Sí a medida que programas vas aprendiendo nuevas formas de hacer las cosas no las cambies por mera emoción, planifica si esto lo puedes aplazar. En otras palabras, evalúa si puedes pagar la deuda en ese instante o si la puedes agendar para más adelante como una tarea más.

Aprende a detectar los siguiente indicadores, esto te ayudará a prevenir el desastre:

  1. Tenemos que entregar rápido.
  2. No tenemos tiempo para el testing.
  3. Programa más hoy, haz el testing después.
  4. Al menos funciona.
  5. Refactorizamos después de entregar.
  6. Ya sabemos cómo hacerlo, empecemos de cero.

Finalmente, recuerda que la deuda técnica es la frase que usamos al intentar explicar la existencia o tenencia de mucho código de poca calidad. Lo llamamos "deuda" porque se trata de costos (inversión de tiempo y dinero, a veces gastos innecesarios) que debemos pagar en el futuro.

Libro de TDD - Lo que debes saber
Compra el libro
TDD lo que debes saber

Newsletter

Únete a más de 4.000+ personas y no te pierdas nunca más de las nuevas clases, tips, tutoriales y más cada semana.

    No enviamos spam. Puedes darte de baja en cualquier momento.