¿Cómo justificar el tiempo de refactorización de código?

Tener un proyecto muy grande de más de 70k LOC.

El proyecto definitivamente necesita refactorización de código en Core Framework y también en otras partes. No había tiempo establecido al comienzo del proyecto para la refactorización. Sin embargo, con el tiempo y más de 40 desarrolladores se unieron y abandonaron el proyecto. Desde mi perspectiva es indispensable.

¿Cuáles serían sus puntos clave al discutir y defender un principio de desarrollo de software adecuado?

Cuando se trabaja en aplicaciones heredadas o abandonadas, es tentador hacer una "limpieza de primavera" con la esperanza de refactorizar todo. De ninguna manera se justifica el uso de los recursos. Después de todo, ¿cómo se puede justificar la detención del desarrollo del software de trabajo (solo se puede refactorizar el código de trabajo)? ¿Puede garantizar que el tiempo dedicado a la Gran Fase de Refactorización dará sus frutos más tarde y no causará degeneración en el proyecto?

¿Cómo se come un elefante? Un bocado a la vez. Cada vez que necesite implementar una nueva función o corregir un error, verá si esa parte necesita una mejora. Como dice la regla de boy scout: "Siempre deja el campamento más limpio de lo que lo encontraste". La refactorización no debería ser una fase separada, es parte del desarrollo diario.

Cuando presente esta cultura de calidad al equipo de desarrollo, la calidad mejorará. Después de eso no hay nada que justificar a la gerencia.

En general, la refactorización debe realizarse para permitir otro cambio que deba realizar en el código o como un paso de limpieza natural después de que se haya realizado un cambio en el código. En ese caso, no hay nada que justificar. La refactorización es simplemente parte del proceso de trabajo en el proyecto. El tiempo se factura a la tarea en la que estaba trabajando cuando realizó la refactorización.

Si no se hace en pequeños incrementos, entonces no se refactoriza realmente, ¿eh?

Todas las buenas respuestas aquí, pero puedo agregar una dimensión comercial a esto. Déjame preguntarte ¿ POR QUÉ / Y qué? (Piense en su jefe de cabello puntiagudo (PHB) :)

PHB: ¿por qué?
Tu: Hará las cosas más fáciles de arreglar
PHB: ¿Y qué?
Usted: Aumentará el rendimiento. ¿Obtendremos nuevas construcciones más rápido?
PHB: ¿Y qué?
Tú: Err ... ¿Clientes más felices?
PHB: WTF?
Usted: me refiero a mayores recomendaciones, mayor satisfacción, 
     más ganancias antes debido al bajo tiempo de respuesta
PHB: ¡Oh! Suena bien. Pero solo "suena" bien, ¿puedo verlo?
Usted: WTF?
PHB: ¡Muéstrame el dinero! (es decir, números por favor)
Tu: Oh! Brb ... (ve y pon algunos números en una hoja de cálculo simple para hacer tu caso)

Básicamente, debe hacer un caso de negocios: ejecute algunos números para aclarar su proceso de pensamiento y obtenga los números que reflejen el 'beneficio' de manera objetiva. También sabrá cuánto tiempo llevará, los costos aproximados, etc. Debe tener sentido. Si vale la pena, obtendrá la señal verde y tal vez encabezará la iniciativa también :)

Si piensas cómo puedo medir todo prueba este libro

La refactorización, como cualquier otra actividad, debe tener un objetivo claro definido para ello. Una vez que ese objetivo esté claro, consideraría el estado actual del proyecto y la etapa del ciclo de vida. Para un proyecto de desarrollo con un 80% de avance, un 30% de retraso, debe justificar el esfuerzo de refactorización según el objetivo establecido anteriormente. En este ejemplo, si las piezas de código se probaron unitariamente y funcionan bien en un entorno de desarrollo, es difícil justificar la refactorización.

El hecho de que hayan quedado 40 desarrolladores puede no ser tan dramático como parece. Esperaría que esos desarrolladores hayan entregado código de trabajo que fue revisado y probado. Entonces, a menos que haya problemas conocidos en este código, lo dejaría como está. La idea es que en un proyecto grande como el suyo, esperaría que hubiera estándares y procedimientos y que el código no sea un completo desastre.

Recuerde que la refactorización hará que se repitan muchas, si no todas, las pruebas realizadas. Además, dado que la refactorización de este tamaño no puede ser realizada por uno o dos miembros principales, la refactorización puede presentar problemas que no existían. Este es un riesgo que no debe ser descuidado.

Dicho esto, no es inusual agregar tareas a un proyecto cuando sucede lo imprevisto. Entonces, si los desarrolladores desaparecieron por alguna razón, eso se consideraría un evento de naturaleza especial y se deben tomar todas las medidas para remediar la situación. Sería tratado como un incendio o un terremoto, etc.

En resumen, no refactorizaría un código de trabajo grande en un proyecto grande sin una buena razón técnica sólida, especialmente porque todos sabemos que la mayoría de los proyectos suelen estar en estado tardío.

Imagina que estás frente a una pared larga y enorme. Necesitas ir al otro lado.

O refactorizas la pared para construir una puerta, o la rodeas.

Calcule el tiempo para ambas soluciones y obtendrá su justificación para refactorizar.

No olvides multiplicar el tiempo en la segunda solución por la cantidad de personas que necesitan ir al otro lado de la pared.

Mientras leo en una de las otras respuestas, come este elefante un bocado a la vez. Estoy involucrado en la auditoría de un gran proyecto internacional, donde los miembros del equipo están dispersos geográficamente. Después de construir las dos primeras versiones del software, el equipo acordó que sus enfoques, estilo de codificación y soluciones de construcción son inconsistentes. Acordaron escribir nuevas partes de la aplicación siguiendo las nuevas reglas y la convención y cuando (y solo entonces) tienen que cambiar parte del código anterior, primero lo refactorizan para cumplir con la nueva convención. Todo funciona bastante bien. El proceso de refactorización está casi en su quinto mes, algunos de los códigos se refactorizan, otros todavía no. Las nuevas funciones se presentan a tiempo, los clientes están contentos, los desarrolladores están contentos, el equipo de control de calidad también está contento. Una situación de ganar-ganar :)

El punto principal de la refactorización es facilitar las cosas en el futuro. No puede mostrar las ganancias de la refactorización a menos que compare varios proyectos a largo plazo con pocos realizados y pocos sin una refactorización constante. En general, se acepta entre los desarrolladores, que la refactorización disminuye el costo de mantenimiento y la implementación de los cambios, pero son difíciles de probar desde el punto de vista comercial. La razón clave para implementar la refactorización es reducir la deuda técnica .

Además, la refactorización debe ser un proceso continuo y el tiempo dedicado a la refactorización debe incluirse en la tarea de desarrollo misma. Tener una "tarea de refactorización" especial no es una buena idea.