¿Cómo reducir la deuda técnica?

No existe una receta única para reducir la deuda técnica. Algunas tácticas que funcionan para una pequeña empresa emergente no siempre funcionan para un equipo de más de 100 personas, que solucionan problemas en un sistema de nivel empresarial. Sin embargo, hay dos direcciones generales que toda empresa debe tomar para mantener la deuda tecnológica bajo control:

• Minimizar la creación de nueva deuda tecnológica.
• Pagar la deuda existente de la manera más eficiente y regular posible.

Veamos diferentes mejores prácticas y estrategias que puede usar para mantener bajo control la deuda técnica actual y limitar la cantidad de errores nuevos que aparecen.

¿Reducir deuda técnica? Rastree y corte el “Cruft”

El seguimiento y la eliminación de la basura son vitales, ya que una deuda tecnológica puede sobrevivir a múltiples ciclos de desarrollo. Lidiar con la artesanía es un proceso de cinco pasos:

• Inventario de su deuda tecnológica: Inicie y mantenga una lista de deudas técnicas en su empresa. Realice un seguimiento de todas las instancias en las que el equipo sabe que el código no está limpio y las versiones que requieren reelaboraciones futuras.
• Categorice el cruft: agrupe las deudas tecnológicas en unidades viables en función de su complejidad, costo de reparación e impacto potencial.
• Tasar la deuda: Tenga en cuenta las consecuencias de ignorar cada unidad. Esta métrica descriptiva ayuda con la priorización de tareas.
• Haga que la lista sea accesible: la lista Cruft debe ser visible para todas las partes relevantes de su empresa (partes interesadas, marketing, ventas, SecOps , etc.).
• Elimine el cruft temprano y con frecuencia: programe horarios regulares (y frecuentes) para que los desarrolladores paguen la deuda tecnológica y mantengan el producto limpio.

Este proceso debe ser continuo y parte de cada ciclo de lanzamiento. Idealmente, el seguimiento y la eliminación de cruft deberían ser uno de los KPI de su equipo de desarrollo o DevOps.

No contrate desarrolladores de baja calidad

Los desarrolladores baratos y de baja calidad crean más deuda tecnológica incluso cuando resuelven activamente los errores existentes. Cuando se tiene en cuenta la pérdida de ingresos por la entrega de un producto de menor rendimiento, los desarrolladores de baja calidad le cuestan más de lo que pagaría por un equipo experimentado.

Al contratar desarrolladores, debe adoptar las siguientes dos mentalidades:

• Valor sobre precio.
• Calidad sobre cantidad.

Los equipos mejores y más pequeños funcionan mejor que los departamentos más grandes y menos capacitados. Contratar a dos desarrolladores de primer nivel suele ser una mejor opción que ir con diez codificadores de bajo rendimiento. Una vez que tenga dos ingenieros confiables para dictar la dirección y supervisar los lanzamientos, puede comenzar a traer miembros del personal de nivel junior para capacitación interna.

Escribir código de alta calidad

Esta práctica se relaciona con la anterior; asegúrese de que el equipo escriba código de calidad midiendo las siguientes métricas:

• Complejidades del código (ciclomáticas y cognitivas).
• Acoplamiento de clases.
• Líneas de código.
• La profundidad de la herencia.
• Aridad.
• Índice de mantenibilidad.
• Medidas de complejidad de Halstead.

Vigilar estas métricas ayuda a enviar productos de software de bajo endeudamiento. Recuerde recompensar a los miembros del personal según el trabajo de alto nivel y no según la cantidad de código escrito.

Considere también crear una guía de estilo de codificación. Al documentar las prácticas de codificación ideales, al equipo le resultará más fácil escribir una sintaxis más limpia y dedicar más tiempo a revisar el código.

Use pruebas automatizadas en lugar de manuales

Las pruebas manuales no son una opción a largo plazo para controlar la deuda tecnológica, por lo que su equipo debería buscar configurar y confiar en las pruebas automatizadas. Si bien establecer y mantener pruebas automatizadas requiere tiempo y esfuerzo, la falta de pruebas manuales garantizará que se descubra cruft de manera más precisa y consistente.

Mantenga un registro transparente de cambios

El equipo de desarrollo debe mantener un registro continuo de todos los cambios en un repositorio. Si ocurre un problema, los desarrolladores pueden rastrear fácilmente su origen y documentar la deuda.

Este registro también es útil para equipos distribuidos y proyectos muy complejos que requieren cambios cuidadosos (como migrar a la nube o modernizar el software heredado).

En la segunda parte hablaremos sobre cómo debe estar preparado un equipo, no sólo para reducir deuda técnica, también para abordarla. Así como saber si vale la pena estar endeudado o cuáles son las mejores opciones para gestionarla. ¡No te lo pierdas!

Descubre cómo podemos ayudarte en este proceso