Deuda técnica: todo el mundo la tiene y todo desarrollador digno de su título quiere saldarla, pero ¿cómo se organiza este proceso?

Implementamos la rotación de cultivos

En mi artículo anterior, comparé el pago de la deuda técnica con la importancia de la rotación de cultivos en la agricultura. Si continúa procesando un campo (base de código) temporada tras temporada para obtener una gran cosecha (proyectos completos, agregar características, etc.), y no le da a este campo una temporada para recuperarse (pago de deuda técnica), entonces poco a poco comienza a perder su calidad y productividad.



Esta metáfora sigue siendo apropiada para el desarrollo de software; además, contiene indicios de posibles estrategias que se pueden utilizar para saldar la deuda técnica.



Existe una gama sorprendentemente amplia de formas de saldar la deuda. Y esto es muy útil ya que nos brinda muchas opciones de planificación.



Para los propósitos de este artículo, asumiremos que está trabajando en una metodología de desarrollo ágil, pero muchos de los principios, si se refinan creativamente, se aplican a otras metodologías.

Sprints dedicados para pagar la deuda técnica

En completa analogía con la rotación de cultivos, podemos dejar de trabajar en funciones cada cuarto sprint más o menos, asignándolas solo para pagar la deuda técnica.



Pros:

• Los desarrolladores comparten un impulso común para centrarse únicamente en pagar la deuda técnica
• Los desarrolladores pueden coordinarse para pagar grandes cantidades de deuda técnica trabajando en conjunto
• Las empresas están motivadas para estudiar los resultados de la deuda técnica que demuestren la importancia del trabajo y el volumen restante.

Desventajas:

• Los conflictos de fusión comienzan a surgir a medida que los empleados realizan grandes volúmenes de cambios arquitectónicos.
• Con este caos e inestabilidad, puede ser difícil saber si algo está roto si no hay una buena cobertura de prueba.
• Solo porque está trabajando en deuda técnica, los incidentes de soporte nunca desaparecen. Sin personal que ayude con la escalada de solicitudes de soporte, se garantiza que la deuda técnica se verá obstaculizada por el soporte.

Capacidad dedicada para el pago de la deuda técnica

En este modelo, el equipo ágil reserva una cierta cantidad de puntos o un porcentaje de la capacidad total del sprint para pagar la deuda técnica de forma continua. Por ejemplo, en cada sprint, un equipo puede tomar 5 storypoins de varios trabajos de pago de deudas.



Pros:

• Esto asegura que el pago de la deuda técnica sea parte de la cultura continua de la organización.
• El trabajo en curso sobre la deuda técnica puede evitar la necesidad de más trabajo en el futuro.

Desventajas:

• Si es necesario realizar cambios en el sprint, trabajar en la deuda técnica será el candidato más probable para ser eliminado del sprint.
• Al limitar su trabajo sobre la deuda técnica a pequeñas cantidades, hace que sea más difícil eliminar las partes, a veces grandes, de la deuda técnica.

Dedicar empleados a pagar la deuda técnica

Este es un híbrido de las dos últimas opciones. Cada sprint selecciona un desarrollador para trabajar en la deuda técnica mientras todos los demás continúan con su trabajo normal.



Pros:

• , , .
• , ,

:

• ,
• , , capacity

En este modelo, cuando los desarrolladores planifican su trabajo, agregan al plan la limpieza del código vecino y el pago de la deuda técnica detectable que ya se encuentra en el área de trabajo. Esto está en línea con el principio de Boy Scouts : siempre deje el estacionamiento (código base) más limpio de lo que estaba antes.



En otras palabras, esto implica que cuando tocas el código, debería mejorar. En el código que se toca con más frecuencia, debe pagar el porcentaje más alto de la deuda técnica, por lo que tiene sentido pagar la deuda en las áreas del código en las que está trabajando.



Un concepto similar se encuentra en el libro de Malcolm Gladwell The Tipping Point.para un ejemplo del metro de Nueva York. La Autoridad de Transporte de la Ciudad ha descubierto que al desacoplar los vagones del metro, limpiarlos de grafitis y asegurarse de que no haya grafitis en todo momento, se puede evitar el efecto de las ventanas rotas , en las que la gente cree que el estado de los vagones no molesta. cualquiera y la tasa de criminalidad puede aumentar. Al reducir la cantidad de conejos y grafitis, la agencia también podría reducir la cantidad de delitos violentos en el metro.



Si transferimos el mismo principio a nuestra base de código, entonces debemos hacerlo de modo que cuando toque áreas del código, se limpien y se pague la deuda técnica.



Probablemente adivinó por lo que leyó anteriormente que soy un fanático de este enfoque, pero consideremos sus pros y sus contras.



Pros:

• La deuda tecnológica se amortiza en áreas que los desarrolladores, naturalmente, tocan con más frecuencia
• Ya no necesita "asignar espacio" para pagar la deuda técnica, es solo parte del flujo de trabajo
• Los conflictos de fusión se minimizan porque los cambios se realizan solo en áreas aisladas.

Desventajas:

• No existe una oportunidad especial para realizar grandes cambios que afecten a todo el sistema.
• Causa "inflación" de los storypoints debido al hecho de que es necesario realizar un trabajo adicional con cada boleto. Esto reduce la cantidad de trabajo que se puede realizar en cada sprint.

Revisiones importantes del código

Arriba, hablé sobre la estrategia de pagar la deuda técnica reemplazando gradualmente partes del sistema, como en el experimento mental con la nave de Teseo , pero ¿y si eso no es suficiente? ¿Qué pasa si no tiene tiempo para reemplazar todo el software pieza por pieza y necesita hacer cambios más radicales?



Aquí hay algunas ideas que le ayudarán:

Dividir una aplicación en aplicaciones más pequeñas

Con esta metodología, dividimos la aplicación monolítica en aplicaciones más pequeñas. A menudo, este enfoque se complementa con un diseño controlado por dominio y / o microservicios, pero su punto principal es que si la aplicación es demasiado grande para reemplazarla, se puede dividir en partes más pequeñas, cuyo reemplazo es realista, después de lo cual puede reemplazar cada una. parte una tras otra.



También puede implementar este esquema utilizando el patrón de aplicación Strangler de Martin Fowler, que crea una nueva aplicación que recibe las mismas solicitudes que la anterior y realiza llamadas a los sistemas heredados hasta que haya un reemplazo moderno listo para cada uno de ellos.



Pros:

:

• ,

capacity

En este modelo, los desarrolladores pueden usar el tiempo de inactividad o el tiempo asignado a la deuda técnica para trabajar en proyectos a largo plazo, como reemplazar parte o la totalidad de una aplicación. Una vez que se ha logrado un progreso suficiente y se puede comenzar a trabajar en serio, estas tareas comienzan a implementarse en un sprint o una serie de sprints para la implementación y entrega formal.



Siguiendo este patrón, he tenido mucho éxito al migrar aplicaciones JavaScript a TypeScript , incluido pasar tiempo fuera del trabajo (no necesariamente, pero decidí hacerlo) y esperar a que los entornos de prueba de regresión se conecten.



Pros:

• Los prototipos potencialmente defectuosos que no están vinculados a ciclos formales de suministro / garantía de calidad se pueden identificar y abordar.
• Cuando el trabajo está listo para ser incluido en el sprint, ya suele ser un trabajo muy concentrado en el que se resuelven la mayoría de las variables desconocidas.

Desventajas:

• Puede resultar difícil encontrar una cantidad significativa de tiempo de creación de prototipos fuera del programa, a menos que su organización desee reducir la asignación de recursos a otros proyectos.

Transición completa a la nueva aplicación

En este modelo, todo el trabajo en la aplicación anterior se detiene, excepto la corrección de errores críticos, y comienza el trabajo en la aplicación, que se convertirá en su reemplazo completo. Esto es lo que la gente suele decir cuando habla de reescribir una aplicación.



Pros:

• Los empleados pueden concentrarse en el nuevo sistema sin tener en cuenta realmente el existente.
• El tiempo total de ejecución puede ser menor

Desventajas:

• Con tiempos de entrega muy cortos, la empresa puede sentir que está desperdiciando dinero en el proyecto.
• Los retrasos en los plazos pueden interferir con la entrega del trabajo requerido
• De hecho, este enfoque se convierte en un principio de todo o nada.
• Es posible que no considere todos los riesgos antes de invertir en un nuevo proyecto de plataforma

recomendaciones

Considere estas opciones para actualizar aplicaciones continuamente, así como opciones más radicales. En mi opinión, no existe una única mejor opción, debes buscar la que sea más óptima para tu equipo, producto y organización. Evalúe estos enfoques y determine qué opciones funcionan mejor para usted cuando prepare una "rotación de cultivos" para mantener su base de código saludable a largo plazo.