¿Qué es la deuda tecnológica?

Las deudas técnicas son puntos de implementación de ingeniería conocidos que uno puede haber elegido conscientemente para no implementar en este momento. Las deudas tecnológicas son comunes, pero deben ser pensadas juiciosamente. Presentaremos algunas pautas sobre cuándo / cómo evaluarlos.

Idealmente, cualquier pieza de código, durante su primera implementación, debe manejar todos los casos conocidos. Sin embargo, puede haber bloqueadores:

1. En algunos casos, con suerte poco comunes, la funcionalidad del producto o la lógica de ingeniería pueden no ser claras. Esto también podría ser una escala o requisitos de tráfico poco claros, lo que genera el riesgo de una preparación insuficiente o excesiva para el tráfico y la escala.
2. Incluso si la implementación es clara para los casos de uso poco comunes, la implementación puede ser compleja o llevar mucho tiempo.

Idealmente, todos queremos minimizar las deudas tecnológicas, pero hay momentos en los que tiene sentido tomarlas.

La necesidad de avanzar

Si bien no tener todos los detalles o la implementación completa puede ser perjudicial, a menudo uno tiene que seguir adelante por alguna combinación de las siguientes razones:

1. A menudo, uno tiene que construir o implementar algo para responder más preguntas, aprovechando los comentarios parciales del uso o del cliente. El tramado puede generar retrasos que son costosos, y es prudente arriesgarse a una implementación no perfecta que a ninguna.
2. La falta específica de claridad puede ser relativamente insignificante en el esquema más amplio de la funcionalidad que se va a construir, se puede agregar o corregir fácilmente, y no implementar la funcionalidad puede ser más costoso.

Cualidades

Cuando tomamos una deuda tecnológica, hemos decidido conscientemente intercambiar quizás una implementación más correcta con una implementación parcial. Sin embargo, una buena deuda tecnológica:

1. Cuando se aborda la deuda tecnológica, provoca menos cambios de código en el código de la implementación elegida actualmente, y
2. Conduce a una falla elegante de alguna parte poco común de la funcionalidad. Por el contrario, cuando se corrige, es una mejora incremental de la característica.

Uno solo debe tomar las buenas deudas tecnológicas que cumplan con las cualidades anteriores. Las siguientes preguntas nos ayudan a evaluar.

Costo

Algunas preguntas para hacer al evaluar el costo de tomar la deuda tecnológica o el caso perdido:

1. ¿Dónde está la funcionalidad perdida, por ejemplo, en visualización/presentación de datos o generación de datos? Más específicamente, ¿la funcionalidad perdida conduce a datos permanentemente incorrectos?
2. ¿Cuál es la desventaja de la experiencia del usuario? ¿Es un caso de uso común con el que es probable que los usuarios tropiecen y se sientan descontentos, o un caso poco común al margen de nuestra propuesta de valor central?
3. ¿Estamos seguros de los detalles del diseño y la implementación de la funcionalidad faltante u omitida? ¿O preferimos recibir comentarios sobre la implementación parcial para definirla?

Tomamos deudas tecnológicas para ciertos beneficios:

1. Lanzamiento más rápido, lo que puede conducir a un aumento de las ventas o la satisfacción del cliente.
2. Potencial para obtener datos de adopción o comentarios, lo que quizás lleve a un mejor diseño de la funcionalidad faltante. Para alguna funcionalidad poco clara, esto puede ser necesario.
3. El costo de oportunidad del esfuerzo de ingeniería ahorrado en el corto plazo.

Seguir los principios fundamentales básicos de un diseño robusto minimiza el retrabajo que implica abordar la deuda tecnológica.

Modularidad

Asegúrese de que los servicios y objetos estén bien pensados ​​con interfaces bien definidas. La modularidad permite localizar los cambios sin minimizar la huella de reelaboración del código.

Trate de pensar más allá de lo inmediato, por ejemplo

1. Si actualmente tenemos una implementación de la funcionalidad, pero más adelante quizás podamos poner la implementación como una subclase de una interfaz. Esto facilita agregar más implementaciones más adelante.
2. Si una entidad actualmente tiene un valor posible para el campo pero luego puede tener más, conviértalo en una enumeración.

esquema limpio

Un buen modelo de esquema de base de datos y ORM que modele de cerca el caso de uso de la vida real generalmente es resistente a cambios adicionales.

Buenas prácticas de codificación

1. Mantenga los valores que pueden modificarse SECOS y no profundos en el código. Pueden ser variables de configuración de entrada en tiempo de ejecución o constantes de código. Esta debe ser una decisión consciente.
2. Algunas funcionalidades necesitan la capacidad de iterar rápidamente o personalizar por cliente. Use herramientas de código bajo/sin código, son fáciles de iterar, incluso un poco por parte de un no ingeniero. Y hay menos código y, por lo tanto, menos abandono.
3. Se aplican las prácticas generales de codificación y diseño mencionadas anteriormente, es decir, mantenga el código SECO (es fácil cambiar el código en un solo lugar), manténgalo simple (por lo tanto, es más fácil de entender para cambiar), etc.
4. Algunos cambios serán aditivos, literalmente basados ​​en el statu quo, por ejemplo, agregar conjuntos de réplicas a un servidor de base de datos mongo de un solo nodo existente o fragmentar a un servidor de base de datos mongo. En caso de que su implementación sea costosa, la necesidad de tales mejoras puede retrasarse más en la línea de tiempo hasta que se necesite sin ningún esfuerzo adicional.

No manejar todos los casos no es razón suficiente para revisar el código. En cambio, a continuación hay una forma de avanzar:

1. Siga confirmando código en su sucursal con abundantes comentarios TODO sobre la funcionalidad pendiente o los elementos de aclaración.
2. Idealmente, resuelva todas las TODO antes de generar la solicitud de extracción.
3. Cualquier problema no resuelto se convierte en una deuda tecnológica: asegúrese de que el revisor de código y el gerente/líder de ingeniería relevante estén etiquetados / la información, la deuda tecnológica creada por Jira y la ID de Jira mencionada en el comentario. Con suerte, la revisión de relaciones públicas debería reconfirmar que la deuda tecnológica está bien.
4. Asegúrese de que el código maneje correctamente incluso los casos no manejados; por ejemplo, el front-end obtiene una respuesta de API adecuada para mostrar el error de la entrada de API aún no manejada en lugar de colapsar el backend.
5. Tenga en cuenta una línea de tiempo para la deuda tecnológica de Jira, posiblemente manteniéndola en el próximo sprint para que aparezca en la llamada de planificación del sprint para la revisión inicial.