Mantenimiento del código: ¿mantiene un patrón incorrecto al extender el nuevo código por ser consistente, o no?

La refactorización se realiza mejor en pasos pequeños, y preferiblemente solo si tiene pruebas de unidad para cubrir el código. (Por lo tanto, si aún no tiene pruebas, intente escribirlas primero, y hasta entonces, apéguese a las refactorizaciones más simples, a prueba de errores y preferiblemente automatizadas. Una gran ayuda para esto es Trabajar eficazmente con el código heredado por Michael Feathers.)

En general, apunta a mejorar un poco el código cada vez que lo toques. Siga la Regla de Boy Scout ( acuñado por Robert C. Martin ) dejando el código más limpio de lo que lo encontró. Cuando agregue un nuevo código, intente mantenerlo separado del código incorrecto existente. P.ej. no lo entierre en el medio de un método largo, en lugar de eso, agregue una llamada a un método separado y coloque allí su nuevo código. De esta manera, crecen gradualmente islas más grandes de código limpio (er) dentro del código base existente.

Actualizar

  

El costo de refactorización será mayor que sus beneficios. [...] Usted, como desarrollador, prefiere mantener un código aburrido estúpido y fácil O tener algunos ayudantes que hagan el código aburrido estúpido en tu lugar?

Hice hincapié en lo que creo que es el punto clave aquí. Siempre vale la pena evaluar los costos y los beneficios de la refactorización antes . Como en su caso, la mayoría de nosotros tenemos recursos limitados para refactorizar, por lo que debemos usarlos sabiamente. Dedique poco tiempo a la refactorización, donde aporta los mayores beneficios con el menor esfuerzo.

Como mente creativa, por supuesto, preferiría producir código perfecto, hermoso y elegante, y reescribir todo lo que no se parezca a mis ideales :-) En realidad, me pagan para producir software que resuelva problemas reales para sus usuarios. , así que debería pensar en producir el mayor valor por su dinero a largo plazo.

El beneficio de la refactorización solo aparece si hay suficientes ahorros en tiempo y esfuerzos para comprender, mantener, corregir y extender el código a largo plazo . Entonces, si un fragmento de código, por muy feo que sea, rara vez se toca, no hay errores conocidos y no conozco ninguna característica próxima en el futuro previsible que requiera que lo toque, prefiero dejarlo. en paz.

Ya que no tiene tiempo para refactorizar y el código se puede mantener, manténgalo consistente. La próxima vez, asegúrese de incluir refactorización en la estimación.

Ser coherente solo ayuda al siguiente desarrollador cuando el código circundante está en buena forma. Piense en cuánto tiempo le llevó entender el código en cuestión y encontrar los "puntos de extensión" correctos para agregar sus cambios. Si sigues la tendencia actual, el siguiente usuario debe entender el código existente y tu nuevo código cuando tiene que hacer cambios.

Si refactoriza el código en funciones significativas, al siguiente usuario le resultará más fácil comprender lo que está sucediendo y tendrá que esforzarse menos para agregar sus cambios. Piénsalo de esta manera. Supongamos que el siguiente chico eres tú. ¿Qué preferiría ver cuando vuelva a visitar este bloque de código, el mismo desorden que está viendo ahora o algo más lógicamente construido?

Consistencia tiene una alta prioridad. Obviamente, todos en su sano juicio preferirían una solución DRY elegante en cualquier lugar en lugar de una plantilla de copia pegada en cualquier lugar, pero ¿realmente preferiría dos enfoques diferentes en la misma base de código a uno aplicado consistentemente? ¿Qué pasa si alguien inventa una solución aún más inteligente y también la aplica de manera inconsistente? Entonces tienes tres formas diferentes de hacer lo mismo.

He visto mucho código desordenado debido a que los desarrolladores han encontrado una "mejor manera" de hacer algo, pero no lo han aplicado de forma coherente en un código base. Si es parte de una estrategia planificada y coordinada aplicar un nuevo patrón gradualmente con el tiempo, puede funcionar, pero cada patrón implementado de manera inconsistente tiene el riesgo de empeorar el sistema en general.

Tal vez podría considerar la refactorización en pasos más pequeños, de modo que cada paso se pueda aplicar sobre todo el código base de una sola vez. P.ej. extraer una parte más pequeña de la placa de calderas para una función auxiliar en cada iteración. Con el tiempo, terminas con todos los platos en una clase de ayuda. Puede parecer realmente feo porque no fue diseñado pero creció, pero puedes arreglarlo ahora porque tienes todo el código en un solo lugar.

Cualquier refactorización que elimine el código duplicado es buena y no debe posponerse a menos que sea inminente una fecha límite. El tiempo dedicado a refactorizar una vez, se recupera fácilmente con el tiempo ganado en futuras implementaciones. Gracias a la refactorización, los trabajos internos ya no son visibles, por lo que debería ser más fácil de entender, no más difícil de seguir.

En mi opinión, es un error común que el código refactorizado sea más difícil de seguir. Por lo general, este es un argumento de personas que solo están familiarizadas con lo que se está refactando y no con el resultado. Para los recién llegados, el resultado refactorizado será más claro.

Cualquier error / característica puede ser arreglado / implementado en un lugar central en un momento posterior, y están disponibles automáticamente en cualquier parte de su aplicación. Esta es una gran ganancia que suele ser muy subestimada. En general, una refactorización total de un componente no toma tanto tiempo. (días en lugar de meses) Al comparar esto con el tiempo perdido debido a errores, al tener que entender el código que podría haberse refaccionado, el costo de refactorización se vuelve mínimo.

Actualización relacionada con la respuesta de Péter Török: ¿No es posponiendo la refactorización "porque lleva tiempo", aumenta el tiempo para refactorizarla más tarde? La refactorización no debería tomar mucho tiempo, cuando se hace con más frecuencia.

Cómo explicarle a su jefe que pasará unos días escribiendo un código que no agregue nada al producto, es difícil y es una pregunta completamente diferente. :)

¿No puedes crear una nueva Interfaz / Clases que funcione como una Fachada sobre el código anterior, al tiempo que introduces tu nuevo código en tu propio estilo que se puede extender fácilmente?

Hazlo bien en el futuro. Usa funciones en lugar de cortar y pegar. Eso no requiere refactorización, pero le da el comienzo de una base para la refactorización futura.

  

Tú, como desarrollador, ¿prefieres mantener un código aburrido estúpido y fácil o tener algunos ayudantes que hagan el código aburrido en tu lugar?

No entiendo la pregunta revisada. Creo que la mayoría de la gente, como yo, preferiría no mantener el "código aburrido estúpido". No sé a qué te refieres con ayudante, lo siento.

El póster respondió a su propia pregunta al no realizar grandes cambios en este momento. Buena elección. Tengo problemas con la arrogancia de un desarrollador porque saben qué es lo mejor para el negocio. Una gran refactorización a escondidas ... ¿porque sabes mejor que tu jefe? Cualquier administrador capaz puede sopesar los beneficios.

Si la refactorización no es una opción, la pregunta se convierte más en una discusión sobre la hora, el lugar, etc. correctos para hacerlo. La consistencia es muy importante. Sin embargo, el código de larga vida a menudo se beneficia de la "renovación". Otros han discutido esto ...