"¡El manual no me deja refactorizar mi código heredado!" Situación común? Terriblemente molesto. La mayoría de los desarrolladores tarde o temprano se enfrentan a un administrador que no está del todo interesado en mejorar lo que ya está listo. Necesitan implementar algo nuevo, apagar el fuego con urgencia o arreglar algún error ... En general, siempre encontrarán una razón para posponer la refactorización del código base en ejecución.
E incluso cuando intentas explicarles los beneficios de un código ordenado, o no entienden o no quieren entender. Solo tienen en cuenta los costos y el tiempo, ya nadie le importa la calidad. Y resulta que eres absolutamente impotente para hacer algo con la deuda técnica, que todavía se acumula y se acumula. Los programadores trabajan para prod y prod, para solicitudes de usuarios impacientes. Nadie pagará por la refactorización. La situación parece desesperada.
En tal situación, muchos desarrolladores inteligentes simplemente empacan sus cosas y dejan la empresa. Y muy pronto, debido a la rotación en el departamento, las puertas ya no están cerradas: unos se van, otros vienen ...
Los gerentes no son programadores
La solución al problema es comunicar a los gerentes qué impacto tiene la mala calidad del código en el negocio. En última instancia, las actividades de la empresa tienen como objetivo ganar dinero. Llegado. En consecuencia, la administración está buscando las mejores formas de reducir costos y aumentar los ingresos. Esto significa que para rehabilitar la refactorización en sus ojos, tendrán que hablar su idioma.
Trabajé como líder técnico y consultor, así que tengo mucha experiencia en este negocio. Compartamos contigo algunas plantillas.
Cinco argumentos que puedes dar
1) "La refactorización ayudará a reducir la volatilidad del costo marginal por unidad de funcionalidad de software",
esta es una cita exacta de los notables desempeños de John B. Rheinsberg en una conferencia sobre "Economía en el desarrollo de software". ¡Espera, no te vayas! Todo lo que aquí se dice, lo sabes perfectamente bien, está simplemente formulado en un espíritu abstracto, abstruso.
Vayamos en orden:
- "La refactorización ayudará a reducir ..." - hasta ahora, todo está bien
- "... volatilidad ..." - en otras palabras, imprevisibilidad
- "... costos marginales ..." - es decir, cuánto recurso se requerirá para producir una unidad adicional más
- “… Por unidad de funcionalidad de software” es una característica que tiene valor para los negocios. ¡Hurra! El valor comercial es exactamente lo que necesitamos.
Los cinco argumentos se basan en la misma idea general de traducción de un idioma a otro, que a menudo descuidamos al tratar con personas alejadas de la esfera de las tecnologías de la información. No use jerga, apóyese en conceptos de economía y negocios, ese es el ingrediente secreto. Esto lo ayudará a establecer una conexión con su administración más rápido.
2) "Durante el último mes, el 63% del recurso de desarrollo se gastó en solucionar problemas con la calidad del producto"
Bueno, sustituya sus números aquí. El punto es respaldar el mensaje con datos cuantitativos. La deuda tecnológica no puede evitar afectar sus procesos de trabajo diarios. ¿Puedes probarlo? ¡Por supuesto!
A continuación, se muestran algunas métricas que puede consultar:
- . ? ?
- -, , . , ? ?
- , . ? ?
Muestre a la gerencia exactamente dónde se traduce para ellos la mala calidad del código. Mejor aún, encuentre una manera de convertir esos números en valor monetario.
Una vez asistí a un error post-mortem que podría haberse evitado si se hubiera realizado la verificación del tipo de datos. El código fue escrito en JavaScript. En ese momento, hubo un debate en la empresa sobre si cambiar o no a TypeScript.
Los desarrolladores que entendieron lo que había sucedido no fueron demasiado perezosos para obtener los datos y pudieron evaluar el daño que el error causó a la empresa. Resultó que en los pocos meses de su existencia, el error le quitó un millón de dólares canadienses a la empresa. ¡Millón! Solo eso habría sido suficiente para compensar el costo de cambiar a TypeScript.
En base a esto, se decidió que los nuevos servicios se implementarán en TypeScript, y para los más importantes, los tipos de datos deben revisarse de forma retroactiva.
3) “Desde un punto de vista técnico, trabajamos a crédito para sacar el producto más rápido. Ahora tenemos que saldar parte de la deuda para que no aumente el time to market ”.
Nuevamente: hablamos el idioma del interlocutor. Las metáforas pueden ser muy efectivas cuando se necesita transmitir un mensaje: conectan conceptos desconocidos con otros familiares para el oyente y, por lo tanto, ayudan a comprenderlos. El concepto de "crédito" es bien conocido por cualquier gerente. Y la "deuda técnica" en sí misma es también una metáfora que ha recibido amplia circulación.
O, digamos, imagine una empresa como un restaurante y el código base como su área de cocina. A medida que se acumulan los platos sucios, atender a un número creciente de visitantes se vuelve cada vez más difícil. Los empleados deben tener tiempo para lavar los platos entre cocciones.
4) "Si invierte el 10% de su tiempo en la calidad del código, su facturación se reducirá significativamente".
Hasta ahora, hemos hablado de las consecuencias obvias de la mala calidad del código. Pero hay una cosa insidiosa que es fácil pasar por alto: la rotación.
Las empresas en estos días tienen dificultades para mantener a los desarrolladores, especialmente a los talentosos, en ellas. Si esa persona deja de disfrutar del trabajo, no le será difícil conseguir otra oferta y simplemente ir a donde mire, lejos del caos eterno. Pero qué hay, tal vez tú mismo ya estés buscando algo mejor ...
Ahora hagámonos una pregunta: ¿cuánto le cuesta a la empresa reemplazar a un desarrollador resignado? Es necesario encontrar un nuevo especialista, recorrer el proceso de contratación y actualizarlo. Requiere inversión, tiempo y pone a todo el equipo en espera. La gerencia definitivamente preferiría no hacer este tipo de reorganización todos los años. Por tanto, reducir la fluidez puede ser un argumento serio. Y el mero hecho de tener un plan para eliminar la deuda técnica dará inmediatamente a todo el equipo +100 de motivación.
5) "Si invierte el 20% de los recursos en refactorización, FRT se reducirá a la mitad y el ROI será positivo para la productividad del desarrollador"
FRT es el tiempo de respuesta, una métrica importante para la asistencia al usuario. El negocio se esfuerza por garantizar que los clientes estén satisfechos con todo.
Aquí hacemos lo siguiente:
- Elegir métricas que tengan mucho peso en el soporte técnico;
- Encontramos un par de problemas que surgen con regularidad y requieren la intervención del desarrollador;
- Ofrecemos un plan para reducir la cantidad de llamadas al soporte técnico al eliminar la causa raíz.
- Si se resuelven este tipo de problemas, será menos probable que los desarrolladores se involucren en las tareas de soporte al usuario. Es decir, liberarán más tiempo del que se dedicó a la refactorización, lo que significa que la inversión dará sus frutos: ese ROI muy positivo.
Al final, deciden
Nadie puede discutir eso. He ofrecido cinco argumentos para convencer a la gente de la importancia de eliminar la deuda técnica, pero ahora creo que hay un consejo más que se debe dar antes de empezar a trabajar en cualquier gerente.
Refactorizar sobre la marcha
La refactorización no debe verse como una fase separada del trabajo de funcionalidad. Después de todo, todavía no puede predecir de antemano qué funciones se implementarán en el futuro. Esto significa que debe ajustar la base del código para las nuevas realidades a medida que estén disponibles. Esto también es parte del trabajo necesario para crear ese valor material; cualquier desarrollador profesional lo confirmará.
La regla funciona incluso para bases de datos con código heredado. Bueno, está bien, definitivamente no la traerás a una forma divina mañana. Y tratar de hacer una refactorización a gran escala en el medio también es un problema muerto. Pero con este enfoque, al menos la situación no empeorará. Y cuando se trabaja con código heredado, no debe centrarse en "bueno", sino en "mejor".
¿Estás arreglando un error? Dedique una hora más a redactar una prueba automatizada. ¿Se está preparando para implementar una nueva función? Tómate un día más para limpiar el código. Intente que el cambio sea indoloro día tras día. Después de unos meses, notarás que este hábito ha tenido un gran impacto en tu productividad. ¿Sabes por qué? Porque la refactorización ayuda a reducir la volatilidad de los costos marginales por unidad de funcionalidad del software.