Este artículo sobre deuda técnica tiene algunos puntos positivos, que incluyen:

Trabajar en los "asuntos técnicos" funciona mejor cuando es impulsado por historias. Es probable que la base del código necesite trabajo en todas partes, pero la recompensa se recibirá solo donde se va a trabajar el código por razones de cara al usuario. Si ninguna historia va a pasar por un área irregular, trabajar en ella se desperdicia en gran medida.

Por lo tanto, prefiero el enfoque de tomar historias como de costumbre (pero probablemente menos de ellas), y seguir la "regla de boy scout" de abandonar el campamento mejor de lo que lo encontraste. En otras palabras, donde sea que nos lleven las historias, escribamos más pruebas, refactoricemos más agresivamente.

Este enfoque tiene al menos estas ventajas:

• mantiene el flujo de historias "mejor sensible";
• proporciona ayuda de todo el talento del equipo
• proporciona a todo el equipo para aprender cómo mantener limpio el código;
• enfoca la mejora exactamente donde se necesita;
• no desperdicia la mejora que "puede" ser necesaria;

He visto que la calidad del código tiene un gran efecto en la productividad a largo plazo, por lo que creo que la deuda técnica debe ser atendida. Creo que la publicación anterior tiene sentido, pero no estoy tan seguro sobre los últimos dos puntos. Estoy interesado en descubrir experiencias reales de los beneficios de la limpieza de la deuda técnica, incluso si no estaba relacionada con las historias de los usuarios.

¿Qué beneficios positivos ha visto al limpiar su base de código y librarse de las deudas técnicas? ¿Qué métodos usaste para hacer el trabajo?

Puedo darte un ejemplo de mi experiencia.

Hace unos 10 o 12 años heredé una aplicación de un equipo de desarrolladores que terminó dejando la empresa (demasiado tiempo para entrar aquí ...). El sistema era un gran sistema de generación de informes de middleware de cosecha propia. Funcionaba todas las semanas y generaba alrededor de 2 docenas de informes Excel para altos ejecutivos de una compañía Fortune 500. Cuando lo heredé, tardé entre 5 y 6 horas en ejecutarse y durante una semana determinada fallaría al menos 2 noches.

No era un campista feliz por haber tenido este desastre.

Inicialmente, mi plan era solo detener el sangrado y corregir la causa principal de las fallas. Después de sentirme más cómodo con la base de código, comencé a buscar lugares donde pudiera refactorizar y agregar estabilidad y rendimiento. En el transcurso de 2 años más o menos, hice muchos, muchos cambios en el sistema. Retiramos ese sistema hace un par de años y en ese momento todo el proceso tardó 45 minutos en ejecutarse y no había generado ningún problema en años.

Se trabajó mucho para pagar la deuda técnica, pero valió la pena. Fue agradable no recibir llamadas telefónicas en medio de la noche que el sistema falló. Fue agradable entrar a la oficina en el monring y ver nada más que buenas noticias en los registros.

(Aparte ... Después de un par de años me encontré con uno de los principales desarrolladores de este sistema. Me preguntó cómo estaba funcionando y le dije lo malo que era el sistema. En realidad se disculpó y me dijo que sabía que sería un puñado de apoyo después de que se fue y deseó haber hecho un mejor trabajo en ello).

Según mi experiencia, los beneficios de la limpieza del código son más notables cuando tengo que mantener el código donde no se ha realizado la limpieza. Cuando se ha realizado la limpieza, mis cambios consisten en leer el código, detectar uno o dos lugares que deben cambiarse e ir desde allí. Si la limpieza no se ha realizado, agregue un paso inicial de leer el código un par de veces e intente averiguar qué estaba pensando el autor (a veces yo) cuando lo escribió.

La eliminación de la deuda técnica produce menos apoyo técnico y una mejor base para las mejoras.

siempre

Una experiencia que tuve fue cuando administraba un equipo de rendimiento del sitio en mi empleador anterior. Todas las noches, durante un período de una hora a dos horas, el sitio web que mi equipo estaba monitoreando caería por debajo de los umbrales de rendimiento aceptables debido a que el bot raspaba rápidamente la información del sitio. Las medidas que tomó el equipo para abordar esto consistieron en iniciar sesión en un sistema de administración manual y bloquear las direcciones IP que estaban causando los problemas. No hace falta decir que esto le costó a un miembro del equipo horas de sueño casi todas las noches. Me di cuenta de lo que estaba ocurriendo y tomé el BlackBerry de guardia por varios días para ver qué tan malo era y dar un descanso a mi equipo.

Después de unos días, simplemente fui al dueño del equipo del negocio y les hice saber que si no implementamos un sistema de bloqueo automatizado para que los bots tengan un tiempo mucho más difícil que afecte el rendimiento del sitio, probablemente perderíamos algunos, si no todos, los miembros del equipo debido a fatiga y agotamiento. Estuvieron de acuerdo e implementamos un sistema que nos permitió dormir por la noche. El propietario del negocio entendió que el costo de unos días o una semana de desarrollo era mínimo en comparación con el costo de contratar / capacitar a nuevos ingenieros.

Con respecto a los últimos dos puntos: entiendo de dónde viene, como se explica en su publicación original :

O, ¿es posible reasignar algunos desarrolladores para hacer estos asuntos técnicos, mientras el resto del equipo continúa con las cosas orientadas al usuario? Esto puede afectar la velocidad del equipo, pero ¿y qué?

"Y qué" es igual: el propietario del producto y otras personas del lado del negocio se vuelven infelices. Y cuando mamá es infeliz, todos son infelices.

Sin embargo, la línea entre lo que debe hacerse y lo que puede hacerse es bastante vaga. La cara del usuario es muy amplia e incluye el rendimiento y la aparición de errores. Pero en algunos casos, el problema subyacente del bajo rendimiento y la alta ocurrencia de errores radica en el código. Para decirlo en sus palabras: una historia puede no pasar por un área crujiente, pero esa área crujiente puede ocultar algunas cosas desagradables que atacan la historia en el camino limpio al lado.

Las cosas que no influyen en el rendimiento general son menos interesantes de limpiar, pero uno debe evaluar con mucho cuidado la influencia de esos puntos. La mayoría de las veces tienen una influencia indirecta que puede ser bastante sustancial.

El mayor beneficio que recibirá una organización como resultado de pagar la deuda técnica es evitar el interés compuesto. Hay un ejemplo en la entrada de blog a continuación que muestra cómo el monto del principal adeudado por una deuda técnica pasó de $ 160k a $ 430k en solo cinco años. Se necesitaría un programador de tiempo completo dedicado exclusivamente al servicio de esa cantidad de deuda. ¡Eso ayudará a ponerlo en perspectiva para los tomadores de decisiones!

De blog.acrowire.com .