¿Debería refactorizar el código existente que no está roto en un proyecto centrado en nuevas características?

Dado un pequeño proyecto que apunta a agregar nuevas funcionalidades a la aplicación, los cambios introducidos tocan algunos códigos existentes, lo que implica actualizarlos en ciertas áreas. Durante la implementación, descubrí que algunos de estos códigos que se actualizaron tienen candidatos para la refactorización.

¿Es este un momento apropiado para refactorizar, lo que a su vez requeriría pruebas de regresión para los componentes afectados (por lo tanto, posiblemente, la introducción del alcance no forma parte originalmente del proyecto)? ¿O debería diferir, completar la funcionalidad y tal vez tener un proyecto separado para refactorizar (aunque dudo un poco ya que los usuarios comerciales pueden no patrocinar por completo un proyecto que no agrega ninguna funcionalidad, a menos que valoren el mantenimiento del código ...)?

Absolutamente.

La refactorización se debe hacer en un proyecto que funcione y que "pase". Cuando pasan todas sus pruebas (en los niveles de unidad, sistema y aceptación), sabe que su producto cumple con los requisitos. Cuando refactoriza, puede continuar confirmando que todas las pruebas continúan pasando. Si alguna prueba comienza a fallar, entonces hizo algo mal y necesita corregirlo. Si tiene pruebas fallidas, debe corregirlas antes de refactorizar para que siempre pueda asegurarse de que su refactorización no cambie la funcionalidad del sistema.

Este es también un momento perfecto para la refactorización, suponiendo que tenga el tiempo y los recursos para llevar a cabo la refactorización y aún así cumplir con el tiempo y el presupuesto. Refactorizar ahora facilitará la comprensión y el mantenimiento de su sistema, por lo que a medida que agrega más funciones nuevas, se vuelve más fácil. Debes luchar contra la descomposición del código y la entropía del software .

Como Joel Etherton señala en los comentarios, debe administrar el alcance de la refactorización. Concéntrese en refactorizar las partes del sistema a las que pronto agregará características, realizando refactorizaciones que facilitarán el trabajo o la adición de las nuevas características. El uso de análisis estático, herramientas de métricas y revisiones de código puede ayudarlo a identificar las áreas más críticas. No querrá perder los plazos porque estaba refactorizando, aún debe continuar agregando valor al cliente.

Usted menciona que el cliente no ve valor en la refactorización. Por lo general, al cliente no le importa la calidad del código, sino el producto. La refactorización le facilitará mantener una alta calidad del producto y seguir entregando un producto que satisfaga las necesidades cambiantes del cliente. Intente negociar el tiempo para refactorizar en su programación (el cliente quiere funciones X en días Y, intente ver si no puede obtener días Y + Z o funciones XN para poder dedicar tiempo al diseño, refactorización e implementación), si lata.

Considere responder las preguntas a continuación, entonces sería fácil para usted tomar la decisión. La sabiduría "no lo arregles si no está roto" es tentador pero no siempre es cierto para el trabajo profesional.

0-¿Hay alguna queja del cliente sobre este código?

1-¿Es esto necesario para la funcionalidad de la aplicación?

2-¿Es dañino el código actual?

3-Vale la pena el costo del cambio?

4-¿Podrías pagar el costo?

5-¿Es esta la mejor utilización de sus habilidades para la organización?

6-¿Sus cambios requerirían que su usuario reinstale el nuevo cambio? ¿Podría justificarlo ante el cliente?

7-¿Podrías tolerar el riesgo de una mala solución?

8-¿El cambio afecta a otro código fuera de su proyecto?

9-¿Es este un producto en evolución o un producto estable? Si está evolucionando, ¿podría incluir los cambios en la próxima versión?

Refactorice pronto, refactorice a menudo.

Si puede permitírselo (tiempo, dinero, etc.), debe hacerlo.

Digo esto porque a veces puede quedarse sin tiempo, o como dice que no obtiene dinero para una intervención de mantenimiento de código, o desea completar su proyecto lo antes posible, y más en general porque la refactorización necesita recursos. Pero aparte de eso, siempre es un buen momento para refactorizar.

Desea un código actualizado, y si cree que su código realmente necesita algunos cambios, especialmente al agregar nuevas funcionalidades, entonces debe cambiarlo.

No olvides que con un sistema de control de versiones puedes bifurcar tu proyecto en una nueva rama, para que no afectes tu código actual.

Si la refactorización es necesaria para implementar la nueva funcionalidad, entonces debe hacerse y factorizarse como parte del nuevo desarrollo.

Tener un código duplicado le costará (tanto a usted como a la empresa) más a largo plazo, ya que las modificaciones se realizan en un lugar y no en otro.

Debe tener un conjunto de pruebas, ya sea pruebas unitarias automatizadas o pruebas de regresión que pueda ejecutar que demuestren que no ha introducido problemas en la funcionalidad existente.

Si la refactorización es simplemente "agradable de hacer", es decir, no está en el código directamente afectado por la nueva funcionalidad, entonces lo dejaría en paz. Estás introduciendo un cambio por el bien del cambio.

Parece que refactorizar el código hará que sea más fácil agregar las nuevas funciones; Esa es la teoría. Incluya esto en el alcance de las nuevas características. Es más probable que obtenga la aceptación de los usuarios comerciales de esta manera. En este caso, deberías poder hacer un argumento convincente y justificar el tiempo para refactorizar. Esperemos que comprendan que esta es una parte necesaria del proceso de desarrollo y tendrán menos objeciones. Es posible que no siempre pueda demostrar este beneficio directo.