Taxonomía de la deuda técnica (2018)

Taxonomía de la deuda técnica

Introducción

• Bill "LtRandolph" Clark es engineering manager del equipo de Champions de LoL y tiene un profundo interés en la deuda técnica.
• La deuda técnica se define como código o datos que generan costos para desarrolladores futuros.
• Este artículo presenta varios tipos de deuda técnica experimentados en Riot y el modelo que usan internamente.

Métricas

Para evaluar la deuda técnica, se usan tres ejes principales: impacto, costo de corrección y contagio.

Impacto

• El impacto que la deuda técnica tiene en jugadores y desarrolladores.
• Bugs, funciones faltantes, comportamientos inesperados, etc.

Costo de corrección

• El tiempo y el riesgo necesarios para corregir la deuda técnica.
• Un error simple puede corregirse en unos minutos, pero los problemas profundamente arraigados pueden tomar semanas o meses.

Contagio

• Qué tanto puede propagarse la deuda técnica.
• Afecta la interacción con otros sistemas, la copia de datos y la implementación de nuevas funciones.

Tipos de deuda

Deuda local

• El problema ocurre solo dentro del sistema y no afecta al exterior.
• Ejemplo: Cataclysm de Jarvan.

Métricas de Cataclysm

• Impacto: 1 / 5
• Costo de corrección: 2 / 5
• Contagio: 1 / 5

Deuda MacGyver

• Cuando dos sistemas en conflicto se combinan mediante una solución temporal.
• Ejemplo: std::string de C++ y la clase AString de Riot.

Métricas de std::string vs AString

• Impacto: 2 / 5
• Costo de corrección: 3 / 5
• Contagio: -2 / 5

Deuda fundamental

• Cuando una suposición ubicada en lo profundo del sistema afecta a todo el sistema.
• Ejemplo: el uso del lenguaje de scripting lua en LoL.

Métricas de BlockBuilder Lua

• Impacto: 4 / 5
• Costo de corrección: 4 / 5
• Contagio: 4 / 5

Deuda de datos

• Cuando se ha acumulado mucho contenido sobre otros tipos de deuda técnica, haciendo que corregirla sea difícil y riesgoso.
• Ejemplo: el bug de nombres de parámetros en el lenguaje de scripting de BlockBuilder.

Métricas del bug de nombres de parámetros

• Impacto: 2 / 5
• Costo de corrección: 2 / 5
• Contagio: 4 / 5

Resumen

• Al evaluar la deuda técnica, se deben considerar el impacto, el costo de corrección y el contagio.
• El contagio indica la posibilidad de que la deuda técnica se propague, y ignorarlo puede convertirse en un gran problema.
• La deuda técnica puede clasificarse en cuatro tipos: deuda local, deuda MacGyver, deuda fundamental y deuda de datos.

Resumen de GN⁺

• Este artículo ayuda a los desarrolladores a tomar mejores decisiones al explicar los tipos de deuda técnica y cómo evaluarla.
• Destaca el contagio de la deuda técnica y enfatiza la importancia de resolver los problemas de forma temprana.
• Otros proyectos con funciones similares incluyen Dota 2 y Overwatch.

[GN⁺]

Opiniones en Hacker News

• La interfaz es uno de los elementos más importantes del diseño y debe considerarse con cuidado

  • Una interfaz hermosa puede mejorarse fácilmente si se le dedica tiempo, pero rara vez ocurre lo contrario

• La deuda del fundador es la deuda creada por los fundadores para ofrecer tecnología rápida y buena

  • Los documentos fundacionales de muchos países también entran en esta categoría

• Sorprende que este artículo haya sido escrito por un gerente de ingeniería

  • No hay gerentes promovidos desde dentro y hay una tendencia a contratar desde afuera

• Se discute una clasificación de la deuda técnica

  • Enlace relacionado: A Taxonomy of Technical Debt
  • Enlace relacionado: A Taxonomy of Tech Debt (2018)

• Es un artículo excelente desde una perspectiva técnica

  • "Nomenclatura" podría ser una expresión más apropiada
  • Cada ejemplo da mucho para pensar

• Se usa "Contagion" para explicar la deuda técnica

  • Es una gran explicación

• La deuda técnica se define como código o datos cuyo costo deberá pagar un desarrollador futuro

  • Al generar deuda, hay que equilibrar la necesidad inmediata con el costo futuro
  • Existe una aversión casi patológica a la deuda

• No llamaría "deuda local" a deuda técnica en una situación general

  • Siempre habrá desorden en alguna parte, y encapsularlo es algo habitual

• He trabajado en varias startups

  • A menudo los fundadores confunden la idea, lo que realmente se implementó y la parte que sí funciona

• A veces se asume deuda técnica de forma intencional para obtener beneficios a corto plazo

  • Ese beneficio también debería considerarse como otro eje