stringtranslate.com

Deuda técnica

En el desarrollo de software y otros campos de la tecnología de la información , la deuda técnica (también conocida como deuda de diseño [1] o deuda de código ) es el costo implícito de futuras modificaciones porque una solución prioriza la conveniencia sobre el diseño a largo plazo. [2]

De manera análoga a la deuda monetaria , [3] si la deuda técnica no se paga, puede acumular "intereses", lo que dificulta la implementación de cambios. La deuda técnica no abordada aumenta la entropía del software y el costo de volver a trabajar en ella. De manera similar a la deuda monetaria, la deuda técnica no es necesariamente algo malo y, a veces (por ejemplo, como prueba de concepto ) es necesaria para hacer avanzar los proyectos. Por otro lado, algunos expertos afirman que la metáfora de la "deuda técnica" tiende a minimizar las ramificaciones, lo que da como resultado una priorización insuficiente del trabajo necesario para corregirla. [4] [5]

A medida que se inicia un cambio en una base de código, suele ser necesario realizar otros cambios coordinados en otras partes de la base de código o la documentación. Los cambios necesarios que no se completan se consideran deuda y, hasta que se paguen, generarán intereses adicionales, lo que dificulta la creación de un proyecto. Aunque el término se utiliza principalmente en el desarrollo de software, también se puede aplicar a otras profesiones.

En un seminario de Dagstuhl celebrado en 2016, los expertos académicos e industriales en la materia definieron la deuda técnica de la siguiente manera: "En los sistemas con uso intensivo de software, la deuda técnica es un conjunto de construcciones de diseño o implementación que son convenientes a corto plazo, pero que crean un contexto técnico que puede hacer que los cambios futuros sean más costosos o imposibles. La deuda técnica presenta una responsabilidad real o contingente cuyo impacto se limita a las cualidades internas del sistema, principalmente la capacidad de mantenimiento y evolución". [6]

Supuestos

La deuda técnica postula que un diseño conveniente reduce esencialmente los gastos en el presente, pero genera gastos adicionales en el futuro. Esta premisa hace suposiciones sobre el futuro:

Como el futuro es incierto, es posible que una deuda técnica percibida hoy en día pueda parecer en realidad un ahorro en el futuro. Aunque el escenario de la deuda se considera más probable, la incertidumbre complica aún más las decisiones de diseño.

Además, el cálculo de la deuda técnica normalmente considera el costo del tiempo de trabajo de los empleados, pero una evaluación completa debe incluir otros costos incurridos o diferidos por la decisión de diseño, como capacitación, licencias, herramientas, servicios, hardware, costo de oportunidad, etc.

Causas

Las causas comunes de deuda técnica incluyen:

Dar servicio o saldar la deuda técnica

Kenny Rubin utiliza las siguientes categorías de estado: [10]

Consecuencias

Los "pagos de intereses" se deben tanto al mantenimiento local necesario como a la ausencia de mantenimiento por parte de otros usuarios del proyecto. El desarrollo continuo en el proyecto aguas arriba puede aumentar el costo de "liquidar la deuda" en el futuro. [ aclaración necesaria ] Uno paga la deuda simplemente completando el trabajo incompleto. [ cita requerida ]

La acumulación de deuda técnica es una de las principales causas de que los proyectos no cumplan con los plazos. [ cita requerida ] Es difícil estimar exactamente cuánto trabajo es necesario para saldar la deuda. Por cada cambio que se inicia, se asigna al proyecto una cantidad incierta de trabajo incompleto. Se incumple la fecha límite cuando el proyecto se da cuenta de que hay más trabajo incompleto (deuda) que tiempo para completarlo. Para tener cronogramas de lanzamiento predecibles, un equipo de desarrollo debe limitar la cantidad de trabajo en curso para mantener baja la cantidad de trabajo incompleto (o deuda) en todo momento. [ cita requerida ]

Si se completa suficiente trabajo en un proyecto como para no presentar un obstáculo para la presentación, entonces se lanzará un proyecto que aún conlleva una cantidad sustancial de deuda técnica. Si este software llega a producción, entonces los riesgos de implementar futuras refactorizaciones que puedan abordar la deuda técnica aumentan drásticamente. Modificar el código de producción conlleva el riesgo de interrupciones, pérdidas financieras reales y posiblemente repercusiones legales si los contratos implican acuerdos de nivel de servicio (SLA). Por esta razón, podemos ver el traslado de la deuda técnica a producción casi como si fuera un aumento en la tasa de interés y la única vez que esto disminuye es cuando se rechazan y se retiran las implementaciones.

"A medida que un programa en evolución cambia continuamente, su complejidad, que refleja el deterioro de su estructura, aumenta a menos que se trabaje para mantenerla o reducirla". [11]

—Meir  Manny Lehman , 1980

Si bien la Ley de Manny Lehman ya indicaba que los programas en evolución aumentan continuamente su complejidad y deterioran su estructura a menos que se trabaje para mantenerlos, Ward Cunningham fue el primero en establecer la comparación entre complejidad técnica y deuda en un informe de experiencia de 1992:

"Enviar código por primera vez es como endeudarse. Una pequeña deuda acelera el desarrollo siempre que se pague con prontitud mediante una reescritura... El peligro surge cuando la deuda no se paga. Cada minuto que se gasta en un código que no es del todo correcto cuenta como interés de esa deuda. Organizaciones de ingeniería enteras pueden quedar paralizadas por la carga de la deuda de una implementación no consolidada, orientada a objetos o de otro tipo". [12]

—Ward  Cunningham , 1992

En su texto de 2004, Refactoring to Patterns , Joshua Kerievsky presenta un argumento comparable sobre los costos asociados con la negligencia arquitectónica, que él describe como "deuda de diseño". [13]

Las actividades que podrían posponerse incluyen la documentación , la redacción de pruebas , la atención a los comentarios de TODO y la resolución de las advertencias del compilador y del análisis de código estático . Otros casos de deuda técnica incluyen el conocimiento que no se comparte en toda la organización y el código que es demasiado confuso para modificarlo fácilmente. [ cita requerida ]

Al escribir sobre el desarrollo de PHP en 2014, Junade Ali dijo:

El costo de no pagar nunca esta deuda técnica es claro: con el tiempo, el costo de entregar funcionalidad se volverá tan lento que será fácil para un producto de software competitivo bien diseñado superar al software mal diseñado en términos de características. En mi experiencia, el software mal diseñado también puede generar una fuerza laboral de ingeniería más estresada, lo que a su vez genera una mayor rotación de personal (lo que a su vez afecta los costos y la productividad al entregar características). Además, debido a la complejidad de una base de código dada, la capacidad de estimar el trabajo con precisión también desaparecerá. En los casos en que las agencias de desarrollo cobran función por función, el margen de ganancia por entregar código eventualmente se deteriorará.

—  Junade Ali escribe en Mastering PHP Design Patterns [14]

Grady Booch compara cómo la evolución de las ciudades es similar a la evolución de sistemas con uso intensivo de software y cómo la falta de refactorización puede generar deuda técnica.

"El concepto de deuda técnica es fundamental para comprender las fuerzas que pesan sobre los sistemas, ya que a menudo explica dónde, cómo y por qué se estresa un sistema. En las ciudades, las reparaciones de la infraestructura suelen demorarse y se realizan cambios incrementales en lugar de audaces. Lo mismo sucede en los sistemas que hacen un uso intensivo del software. Los usuarios sufren las consecuencias de una complejidad caprichosa, mejoras demoradas y cambios incrementales insuficientes; los desarrolladores que desarrollan dichos sistemas sufren los problemas de no poder escribir código de calidad porque siempre están tratando de ponerse al día". [1]

—Grady  Booch , 2014

En el software de código abierto , posponer el envío de cambios locales al proyecto original es una forma de deuda técnica. [ cita requerida ]

Véase también

Referencias

  1. ^ ab Suryanarayana, Girish (noviembre de 2014). Refactoring for Software Design Smells (1.ª ed.). Morgan Kaufmann. pág. 258. ISBN 978-0128013977.
  2. ^ "Definición del término "Deuda Técnica" (más información de fondo y una "explicación")". Techopedia . Consultado el 11 de agosto de 2016 .
  3. ^ Allman, Eric (mayo de 2012). "Gestión de la deuda técnica". Comunicaciones de la ACM . 55 (5): 50–55. doi :10.1145/2160718.2160733. S2CID  53246391.
  4. ^ Jeffries, Ron. «Deuda técnica: ¿mala metáfora o la peor metáfora?». Archivado desde el original el 11 de noviembre de 2015. Consultado el 10 de noviembre de 2015 .
  5. ^ Knesek, Doug. "Cómo evitar una crisis de 'deuda técnica'" . Consultado el 7 de abril de 2016 .
  6. ^ Avgeriou, París; Kruchten, Philippe; Ozkaya, Ipek; Carolyn, marinero (2016). "Gestión de la deuda técnica en ingeniería de software (seminario dagstuhl 16162)" (PDF) . Informes Dagstuhl . 6 (4).
  7. ^ ab Rios, Nicolli; Spínola, Rodrigo Oliveira; Mendonça, Manoel; Seaman, Carolyn (11 de octubre de 2018). "Las causas y efectos más comunes de la deuda técnica: primeros resultados de una familia global de encuestas industriales". Actas del 12.º Simposio Internacional ACM/IEEE sobre Ingeniería y Medición de Software Empírico . ESEM '18. Nueva York, NY, EE. UU.: Association for Computing Machinery. págs. 1–10. doi :10.1145/3239235.3268917. ISBN 978-1-4503-5823-1.
  8. ^ abc Girish Suryanarayana; Ganesh Samarthyam; Tushar Sharma (11 de noviembre de 2014). Refactorización para el diseño de software: gestión de la deuda técnica. Elsevier Science. p. 3. ISBN 978-0-12-801646-6.
  9. ^ abc Chris Sterling (10 de diciembre de 2010). Managing Software Debt: Building for Inevitable Change (Administración de la deuda de software: preparación para un cambio inevitable) (Adobe Reader). Addison-Wesley Professional. pág. 17. ISBN 978-0-321-70055-1.
  10. ^ Rubin, Kenneth (2013), Essential Scrum. Una guía práctica para el proceso ágil más popular , Addison-Wesley, pág. 155, ISBN 978-0-13-704329-3
  11. ^ Lehman, MM (1996). "Leyes de la evolución del software revisadas". EWSPT '96 Actas del 5º Taller europeo sobre tecnología de procesos de software : 108–124. ISBN 9783540617716. Recuperado el 19 de noviembre de 2014 .
  12. ^ Ward Cunningham (26 de marzo de 1992). "El sistema de gestión de carteras WyCash" . Consultado el 26 de septiembre de 2008 .
  13. ^ Kerievsky, Joshua (2004). Refactorización de patrones . Addison-Wesley. ISBN 978-0-321-21335-8.
  14. ^ Ali, Junade (septiembre de 2016). Mastering PHP Design Patterns | PACKT Books (1.ª edición). Birmingham, Inglaterra, Reino Unido: Packt Publishing Limited. pág. 11. ISBN 978-1-78588-713-0. Recuperado el 11 de diciembre de 2017 .

Enlaces externos