Mal karma en la programación. ¿Qué es la deuda técnica y cómo solucionarla?

Deuda técnica. La mayoría de los programadores que trabajan activamente en su especialidad tienen que lidiar con este término. Para muchos, su mención puede incluso provocar dolor de cabeza, así como molestias en otras partes del cuerpo que aparecen cada vez que se enfrenta a una deuda técnica mientras se trabaja en un proyecto. Por eso, hoy hablaremos de deuda técnica (TD): qué es, cómo aparece, qué tipos de deuda técnica hay y cómo gestionarla de forma eficaz.

¿Qué es la deuda técnica?

Sin embargo, primero comprendamos la terminología. La deuda técnica es una metáfora de la ingeniería de software para los problemas acumulados en el código o la arquitectura del software debido al descuido de la calidad en el desarrollo de software y que causan costos laborales adicionales en el futuro. Esta es la definición de deuda técnica dada por Wikipedia. En pocas palabras, la deuda técnica es el resultado de la aplicación de soluciones simplificadas y de corto plazo en el desarrollo, que luego conducen a costos cada vez mayores (a menos, por supuesto, que la deuda sea "pagada") en dinero y tiempo para su posterior refinamiento. reescribir el código o mantener el producto en su forma actual. En el mundo de los programadores comunes, la deuda técnica es uno de los tipos de karma negativo, un desmotivador y una fuente de tristeza que surge como retribución por el código incorrecto, el uso de muletas y soluciones "temporales" (pero en realidad no muy) que ayudar a resolver problemas de corto plazo y acelerar el desarrollo “a crédito”, es decir, a expensas de una creciente maraña de problemas en el futuro. En la industria de TI, la deuda técnica es un problema bastante grave. Según un estudio reciente , las empresas de todo el mundo gastan anualmente más de 85 mil millones de dólares solo en corregir códigos incorrectos. En total, se gastan alrededor de 300 mil millones de dólares al año en proyectos relacionados con el soporte de sistemas obsoletos y software “malo”. Estas son cifras significativas. Los investigadores estiman que si los esfuerzos de todos los desarrolladores que trabajan con la deuda técnica y sus consecuencias se reorientaran hacia el desarrollo “correcto”, se agregarían alrededor de 3 billones de dólares al PIB mundial en el transcurso de la década actual.

Razones de la apariencia

Hay que entender que la deuda técnica no siempre es mala, del mismo modo que endeudarse financieramente puede ser positivo si, por ejemplo, se pide un préstamo para desarrollar un negocio (o lanzar una startup ). En el caso de TD, esto es aceptable para empresas de rápido crecimiento que necesitan lanzar nuevos productos o servicios de forma rápida y frecuente para evaluar su éxito y estudiar las necesidades del mercado, o capturar rápidamente nuevos nichos, por ejemplo. Pero, al igual que ocurre con la deuda financiera, con la deuda técnica hay que tener cuidado y saber gestionarla, de lo contrario pueden surgir problemas graves. Cuanta más deuda técnica se acumula durante el desarrollo de un producto de software, más puede afectar a la empresa, ralentizando el lanzamiento de nuevas versiones, bajando la moral de los programadores comunes que son responsables del "mantenimiento" de dicha deuda y aumentando los costos. , que en última instancia puede incluso destruir la empresa . Las razones de la deuda técnica, además del noble deseo de terminar el producto lo antes posible o de complacer a los usuarios con una nueva versión, suelen ser una mala gestión del producto, plazos poco realistas o limitaciones de recursos y, por supuesto, la pereza del programador. , junto con las bajas calificaciones y la falta de comprensión de los principios clave del desarrollo, también contribuyen a menudo al crecimiento de la deuda. A menudo sucede que los propios desarrolladores son muy conscientes de la presencia y el crecimiento constante de la deuda técnica, pero no tienen el poder suficiente para cambiarla o no pueden transmitir información a la gerencia sobre la existencia de tal problema y la importancia de resolverlo.

Clasificación

Como se mencionó anteriormente, la deuda técnica se presenta en muchas formas diferentes y, dado que la definición en sí es solo una metáfora, los diferentes tipos de deuda técnica se pueden clasificar de diferentes maneras. En particular, Dag Liodden, cofundador y CTO de Tapad, considerado uno de los expertos mundiales en deuda técnica, durante un discurso en el evento anual de la Cumbre de la CTO, propuso dividir la deuda técnica en tres tipos principales.

1. Deuda técnica intencional.

   Aparece en los casos en que los desarrolladores eligen deliberadamente no la mejor solución, porque es más fácil y rápida de implementar, lo que, a su vez, ayudará a lanzar rápidamente un nuevo producto al mercado.

   “A veces asumimos deuda técnica deliberadamente para reducir el tiempo de desarrollo. Si decide seguir este camino, considere no sólo el tiempo que ahorrará durante el desarrollo, sino también el tiempo que tendrá que dedicar más adelante para “pagar” dicha deuda. Además, asegúrese de que las partes interesadas [la alta dirección de la empresa] sean conscientes de que tal decisión inevitablemente ralentizará el lanzamiento de otras funciones en el futuro”, dijo Dag Ljodden.

   Una aproximación a la solución de este tipo de deuda técnica

   El experto aconseja documentar cuidadosamente estos casos para volver a ellos y corregirlos antes de que se pierda esa deuda técnica, convirtiéndose en parte integral de la estructura del proyecto.

2. Accidentales o derivados de arquitectura de proyecto desactualizada Deuda técnica.

   Además, el endeudamiento técnico a menudo surge con el tiempo, debido a errores y deficiencias en la etapa de creación de la arquitectura del proyecto. A medida que los sistemas evolucionan y los requisitos de software cambian, los errores de diseño se vuelven más evidentes y agregar nuevas funciones requiere más tiempo y esfuerzo. La calidad de la arquitectura inicial del proyecto juega aquí un papel importante: debe ser simple y funcional, entonces será más fácil adaptarse a los cambios.

   Una aproximación a la solución de este tipo de deuda técnica

   Para evitar que este tipo de deuda técnica se acumule y no supere niveles críticos, Dag Llodden recomienda refactorizar periódicamente, aproximadamente una vez cada dos años, durante los períodos en que el sistema se encuentra en un estado estable. Los líderes de equipo y los gerentes de producto deben dedicar tiempo para “saldar” este tipo de deuda técnica que surge debido a la arquitectura y los requisitos cambiantes del proyecto.

3. Deuda técnica que surge con el tiempo.

   El experto califica esta deuda técnica como “de larga data”. Se acumula con el tiempo a medida que un componente o sistema se vuelve gradualmente más complejo debido a que se agregan muchos cambios constantemente. Esto suele verse exacerbado si diferentes personas trabajan en el sistema en diferentes etapas y no comprenden completamente la arquitectura original.

   Una aproximación a la solución de este tipo de deuda técnica

   Este es el único de los tres tipos de deuda técnica que se debe intentar evitar de forma continua mediante una refactorización periódica, afirma el experto. Idealmente, un equipo de desarrollo debería tomarse el tiempo para comprender a fondo la arquitectura del sistema en el que están trabajando, incluso si fue creado originalmente por otras personas. Comprender el sistema le permitirá mejorar y corregir gradualmente el código incorrecto sin llevar el proyecto a la etapa de "pudrición".

Soluciones técnicas de gestión de deuda

Hay muchas opciones para gestionar eficazmente la deuda técnica, pero todos los expertos coinciden en que es necesario hacerlo, ya que la deuda técnica es una parte integral de casi cualquier desarrollo, y aquellas empresas que la ignoran invariablemente enfrentan problemas en etapas posteriores. A continuación se presentan algunas soluciones y enfoques eficaces para gestionar la deuda técnica de un equipo de desarrollo.

1. Asigna un porcentaje fijo de tu tiempo de trabajo a trabajar en deuda técnica.

   Lo que pasa con la deuda técnica es que nunca hay tiempo para trabajar en eliminarla (porque siempre hay tareas de mayor prioridad) a menos que lo hagas con un propósito. Por tanto, una buena solución sería destinar un determinado porcentaje fijo del tiempo de trabajo a estos fines: alrededor del 20-25%.

   Esto se puede hacer de diferentes maneras.

2. Trabajar en deuda técnica 1 día a la semana.

   Si dedica un día a la semana a trabajar en la eliminación de TD como todo el equipo, esto representará aproximadamente el 20% del tiempo total de trabajo. Para algunos equipos, este enfoque funciona bien y se dice que incluso mejora la moral, porque en ese día particular de la semana todo el equipo está trabajando para resolver los problemas que los acosan el resto del tiempo de desarrollo.

3. Dedica una de cada cuatro tareas a trabajar en TD

   Este sistema es adecuado para aquellos equipos que tienden a dividir el trabajo del proyecto en tareas aproximadamente iguales en tiempo y esfuerzo para completarlas. Si una de cada cuatro tareas se dedica a “pagar” el TD, esto requerirá aproximadamente una cuarta parte del tiempo total de desarrollo. Y la introducción de este enfoque como regla garantizará que los codificadores no dejen la deuda técnica “para más adelante”.

4. Papel de transición

   Otro enfoque al problema de eliminar la deuda técnica sería asignar a diferentes miembros del equipo a una tarea determinada por turnos, para distribuir uniformemente este trabajo que a veces no es el más agradable entre los miembros del equipo. El número de desarrolladores asignados a "recolectar" TD puede ser diferente: para un equipo de 4 a 5 personas, uno será suficiente, mientras que para equipos más grandes se pueden asignar dos o tres. Pero la esencia sigue siendo la misma: alrededor del 20-25% de todos los recursos y horas de trabajo deberían dedicarse a trabajar en TD.

5. Regla de los boy scouts.

   La regla de los Boy Scouts es dejar siempre un campamento (sitio de campaña) en mejores condiciones que cuando llegaron, es decir, limpiar hasta la basura que no dejaron. Este principio, como han descubierto los codificadores extranjeros, también es excelente para gestionar la deuda técnica. Según esta regla, todos los miembros del equipo deben corregir el TD cada vez que lo encuentren de una forma u otra. Por supuesto, esta regla debe aplicarse con prudencia para que el tiempo que lleva corregir el TD no supere un “razonable” 25-30% del total de los recursos de tiempo.

6. Priorizar la deuda técnica “cara”

   Los expertos también recomiendan en general no olvidar que la deuda técnica puede variar en importancia. No todo tipo de deuda técnica requiere una resolución inmediata, por lo que es importante trabajar en clasificar los diferentes tipos de deuda técnica y priorizar el trabajo sobre ellas en consecuencia. En pocas palabras, en primer lugar es necesario cerrar aquellas deudas que tienen un impacto directo en la velocidad de desarrollo del producto, siendo parte de su arquitectura básica. Este tipo de deudas son las más peligrosas porque dan lugar a nuevas deudas que pueden crecer como una bola de nieve.

Conclusión

Finalmente, me gustaría enfatizar una vez más que es imposible prescindir de las deudas técnicas en el desarrollo de software, porque son parte integral del desarrollo como tal. Sin embargo, a pesar de su naturaleza técnica, la TD sigue siendo un problema causado por el factor humano en el desarrollo. Y aunque no podrá prescindir de él por completo, la cantidad de deuda técnica se puede reducir tanto como sea posible si escribe código "limpio" y aborda el proceso de desarrollo de la manera más responsable y profesional posible. ¡Esto es lo que deseamos para todos!