¿Tenemos la responsabilidad de mejorar el código antiguo?

Estaba revisando algún código antiguo que escribí. Funciona, pero no es un gran código. Ahora sé más de lo que sabía en ese momento, por lo que podría mejorarlo. No es un proyecto actual, pero es un código de producción actual y funcional. ¿Tenemos la responsabilidad de regresar y mejorar el código que hemos escrito en el pasado, o es la actitud correcta "si no está roto, no lo arregles"? Mi empresa patrocinó una clase de revisión de código hace unos años y una de las principales conclusiones fue que a veces es lo suficientemente bueno; siga adelante.

Entonces, en algún momento, ¿debería llamarlo lo suficientemente bueno y seguir adelante, o debería tratar de impulsar proyectos para mejorar el código antiguo cuando cree que podría ser mejor?

A menos que realice cambios en este "código antiguo" para corregir errores o agregar funciones, no me molestaría en mejorarlo solo por el simple hecho de hacerlo. Si finalmente desea mejorarlo, asegúrese de tener pruebas unitarias en su lugar que prueben el código antes de comenzar a refactorizarlo.

Puede usar el "código antiguo" para aprender mejores prácticas. Si hace esto, es una experiencia de aprendizaje a tiempo parcial y no debe esperar que ese código reemplace lo que actualmente se publica o implementa por clientes / clientes.

Refactorice las áreas de código que necesita modificar con más frecuencia . Dado que visita estas áreas con frecuencia, la refactorización mejorará su comprensión del código y la legibilidad para cuando tenga que volver a visitarlas, mientras que no tiene sentido refactorizar el código que nadie volverá a ver.

Además, si solo refactoriza áreas de código cuando necesita modificarlas, le dará una excusa válida si su refactorización causa una regresión . Por supuesto, intente cubrir sus refactorizaciones con pruebas unitarias, pero esto no siempre es posible, especialmente con código heredado y debe esperar grandes refactorizaciones para crear regresiones de vez en cuando.

Si necesita agregar características y su diseño lo está ralentizando o causando duplicación, refactorice . Cuando diseño código casi nunca predigo exactamente qué cambios serán necesarios en el futuro. Sin embargo, cuando agrego nuevas funciones, generalmente termino refactorizando el código compartido. Para cuando agregué un tercer ciclo de funciones / refactorización, mi refactorización ya se está amortizando y mi código compartido es bastante estable.

TLDR: refactorizar según sea necesario, no hay obligación.

Todo lo que haces tiene un costo. Tienes tiempo limitado para programar. Todo lo que haces en la programación debe ser comparado con "¿Cuál es el beneficio de hacer esto?" y "¿Cuál es el beneficio de hacer otra cosa?"

Si no tiene en cuenta el costo de oportunidad (¿Cuál es el costo de hacer otra cosa?), Entonces la calidad es gratuita. Es mejor mejorar tu código. Aprenderás algo. Funcionará mejor. Se venderá más.

La verdadera pregunta es ¿cuál es la siguiente mejor cosa que podrías hacer con tu tiempo? Y luego tienes que hacer concesiones.

¿Venderá más del software?

¿Causará menos dolores de cabeza para apoyar?

¿Que aprenderás?

¿Se volverá más estéticamente agradable?

¿Mejorará tu reputación?

Haga estas preguntas (y cualquier otra que sea relevante para usted) para esta y otras actividades en su cola, y eso ayudará a responder si vale la pena solucionarlo. Estas compensaciones son la razón por la que la economía es importante para los programadores. Joel lo dijo antes que yo, y un viejo mentor me lo dijo incluso antes de Joel.

O si desea una respuesta más simple, simplemente deje de mirar televisión hasta que haya arreglado el código. :-)

Creo que deberías comenzar haciéndote la pregunta que parece haberse perdido. ¿De qué manera es malo el código? Y con esto realmente te estás preguntando lo siguiente:

• ¿El código no hace lo que se supone que debe hacer?
• ¿El código le causa problemas cuando mantiene el software?
• ¿El código es completamente autónomo?
• ¿Tiene planes para actualizar o reemplazar el código en cualquier momento en el futuro previsible?
• ¿Hay algún caso comercial sólido que pueda hacer para actualizar el código que le preocupa?

Si hay una cosa que he aprendido a lo largo de los años, es que no puedes permitirte adivinar después del hecho. Cada vez que resuelve un problema en el código, aprende algo y probablemente verá cómo su solución, o algo similar, podría haber sido una mejor solución a un problema que resolvió de manera diferente hace años. Esto es bueno, porque te muestra que has aprendido de tus experiencias. Sin embargo, la verdadera pregunta es si es probable que el código que escribió anteriormente se convierta en un problema heredado que se vuelve más difícil de tratar con el tiempo.

De lo que realmente estamos hablando aquí es si el código que le molesta es fácil o difícil de mantener, y qué tan costoso es el mantenimiento a medida que pasa el tiempo. Esta es esencialmente una pregunta sobre la Deuda Técnica, y si vale la pena pagar esa deuda con un poco de mantenimiento quirúrgico ahora, o si la deuda es lo suficientemente pequeña como para que pueda dejarla pasar un poco.

Estas son preguntas que realmente necesita sopesar con su carga de trabajo presente y futura, y deben analizarse detenidamente con su gerencia y equipo para obtener una mejor comprensión sobre dónde invertir sus recursos y si su antiguo código vale la pena. el tiempo que puede necesitar para dedicarlo, si es que lo hace. Si puede hacer un buen caso de negocios para introducir cambios, entonces hágalo, pero si se enfrenta a la necesidad de jugar con el código porque se siente avergonzado por la forma en que lo escribió, le sugiero que no haya espacio para el orgullo personal cuando se trata de mantener el código antiguo. Funciona o no, y es fácil de mantener o costoso de mantener, y nunca es bueno o malo simplemente porque la experiencia de hoy no estaba disponible para usted ayer.

Definitivamente no lo mejore solo por mejorarlo. Como otros han dicho (y es de sentido común), todos mejoramos (por algún valor de "mejor") a medida que pasa el tiempo. Dicho esto, revisar el código (ya sea formal o informalmente) a menudo ilumina estos fragmentos que probablemente desearíamos nunca volver a ver la luz del día.

Aunque no creo que tengamos la responsabilidad de regresar y mejorar el código que no está fundamentalmente roto, inseguro o depende de las características de una lista obsoleta / EOL, aquí hay algunas cosas que he hecho en el pasado en esta situación. :

• Identifique a las personas en el equipo que realmente piensan en regresar y mejorar el código, como una especie de limpieza del cerebro o una tarea agradable y de tamaño pequeño que les da una sensación de logro, y encuentre tiempo en el cronograma para que lo hagan de manera regular. Siempre he tenido al menos uno de estos tipos de personas en un equipo, y este enfoque también puede aumentar la moral (o al menos el estado de ánimo) si todos estamos en un período de calma o depresión.

• Úselo como base para un ejercicio de aprendizaje. Para pasantes, estudiantes o miembros nuevos / junior del equipo, refactorizar el código antiguo con la guía de los miembros senior del equipo les brinda la oportunidad de comunicarse con los nuevos miembros del equipo, comprender más sobre el sistema y adquirir el hábito de escribir / actualizar las pruebas unitarias y trabajar con integración continua. Es importante tener en cuenta que este ejercicio se realiza con orientación y claramente enmarcado como un ejercicio para mejorar el código porque no se ajusta a los estándares / normas actuales.

Entonces, no hay responsabilidad de arreglarlo, pero esas cosas viejas pueden ser realmente útiles. ¡Y las pruebas unitarias y CI son tus amigos!

No necesariamente. Sin embargo, si está realizando el mantenimiento del código y se topa con algo que podría ser mejor, puede cambiarlo siempre que tenga las pruebas unitarias adecuadas para asegurarse de que no creó una regresión.

Si no existen tales pruebas y no puede estar seguro de que se comportará exactamente como debería, es mejor dejarlo solo.

Desde la perspectiva de un ingeniero, seguro que me gustaría mucho trabajar en código antiguo hasta que ya no se pueda mejorar. ¿Pero hay un caso de negocios para ello? Al final del día, el código está ahí para contribuir a la rentabilidad, a la rentabilidad de su lugar de trabajo. Si no es así, solo déjalo.

Hay una gran advertencia, si al mejorar el código, va a evitar que ocurra un error (pensando en las grandes bolas Y2K aquí ...) Definitivamente lo mencionaría con alguien más alto, tal vez el gerente de su unidad de negocios, y discuta las consecuencias de mejorar el código.

En cuanto a mí, la pregunta puede reformularse y generalizarse: "¿Por qué alguien debería gastar recursos adicionales (tiempo, dinero, mental, etc.) si ese código concreto funciona bien ahora? ¿No es un desperdicio de recursos? ? "

Cada vez que encuentro un código heredado, pienso en varias cosas que parecen ser importantes.

1. ¿Para qué voy a hacer cambios?
2. ¿Tendré que admitir este código? ¿Qué tan pronto puede suceder (futuro cercano / lejano)?
3. ¿Es este código lo suficientemente cómodo para trabajar? (Ahora mismo)
4. ¿Puedo estar seguro de que todos los cambios que hago son seguros? Las diferentes pruebas generalmente ayudan a responder esta pregunta.
5. ¿Qué consecuencias puedo enfrentar si cometo errores durante la modificación del código? ¿Es posible revertir mis cambios rápidamente? ¿Será una pérdida de tiempo?
6. ...

En realidad, debes hacerte muchas preguntas. No hay una lista completa y final de ellos. Solo usted y probablemente sus compañeros de equipo pueden encontrar la respuesta.

PD: He notado que tiendo a reescribir el código muy a menudo, mientras que mi amigo y compañero de equipo tienden a dejarlo intacto. Eso es porque respondemos las preguntas mencionadas de manera diferente. Y tengo que decir que les respondemos mal muy a menudo ... porque no podemos predecir el futuro.

¿Microsoft necesita actualizar Windows? ¿Todas las distribuciones * nix tienen que seguir evolucionando? ¿O un ejemplo más práctico todavía conducen todos los autos de los años 70?

Normalmente puede escribir mejor el código la segunda vez, aprendió más sobre el dominio escribiéndolo inicialmente.

No hay una respuesta simple para saber si vale la pena volver a clasificar. En general, no debería a menos que a) sea un buen ejercicio de aprendizaje para usted ob) ahorre tiempo a largo plazo con un mejor código. Recuerde que cada cambio corre el riesgo de errores.

Como nota al margen, recomendaría firmemente las pruebas unitarias. Es muy fácil acumular cambios de enfoque, especialmente si no tiene un comportamiento actual claramente marcado con descansos automáticos.

Creo que tenemos la responsabilidad de escribir el mejor código posible que podamos hoy. Eso significa usar todo lo que hemos aprendido en el pasado y negarnos a tomar atajos en nuestro diseño. Si las presiones de programación causan que algo se corte, no creo que la calidad de nuestro software deba considerarse, por otro lado, ese pequeño clip de papel animado ...

Ahora, si está trabajando y encuentra que el código con el que necesita interactuar no está escrito al nivel que actualmente es capaz de escribir, entonces es razonable arreglarlo SI puede hacerlo de una manera metódica controlada. Personalmente, tengo una experiencia mínima con este tipo de Refactorización, como todos (¿casi todos?) Intenté todo "vamos a cambiar todo y rezar para que funcione" y me mordió lo suficiente. Sugeriría investigar las discusiones de Martin Fowler (ya sea su libro o uno de muchos artículos ) sobre el tema. Parece haber inspirado la mayor parte del pensamiento actual sobre el proceso.

Por supuesto, a veces es posible que no pueda limpiar el código como lo desea. Joel Spolsky escribió un artículo sobre por qué querrá dedicar unas semanas a simplemente Refactorizar su código. Léalo aquí y sí, es un poco viejo, pero creo que la información sigue siendo relevante.

Espero que eso ayude

Siento que refactorizar / mejorar el código antiguo define al programador mismo. El deseo de mejorar el código que escribió hace un año solo muestra su progreso, y si mejora la aplicación y tiene la capacidad, el tiempo y la aprobación para mejorarla, hágalo.

Mejor / mejorado es una comparación multieje. ¿Crees que puedes hacerlo más rápido, más pequeño, más eficiente en recursos, más legible, información más útil, resultados más precisos, más flexible, más general, capaz de ejecutarse en más sistemas, eliminar una dependencia de un producto separado?

¿Por qué su compañía debería pagarle por pasar tiempo reescribiendo este código, en lugar de escribir un código nuevo o reescribir alguna otra pieza de código?

Debe realizar mejoras a medida que se presente la oportunidad, pero la oportunidad significa que ya está trabajando en el código o que ha identificado una razón comercial para realizar el cambio.

Impulsar un cambio en la producción introduce una probabilidad distinta de cero de romper cosas (las pruebas unitarias y funcionales solo reducen esta posibilidad, no la eliminan), y solo deben hacerse cuando el beneficio esperado supera el riesgo.

¿Cuál es otro punto a considerar? ¿PRETENDE impulsar este cambio a la producción, o simplemente a la rama de desarrollo? La barra para los dos escenarios son completamente diferentes. Si solo va en la rama de desarrollo, y puede que nunca entre en producción, entonces la oportunidad básicamente significa que está mirando el código por alguna razón, y no lleva mucho tiempo hacerlo. Puede revisarse según sea necesario si alguna vez se produce un impulso, y omitirse si se considera injustificado en ese momento. Si, por otro lado, se va a producir ahora, como dije anteriormente, debe considerar si este cambio vale la pena: en términos de tiempo dedicado a impulsar y los beneficios de usar el nuevo código.

Una buena regla general es que si le tomó tiempo entender lo que está haciendo el código, y si este tiempo podría reducirse en el futuro mediante algunas refactorizaciones bien elegidas, entonces está satisfaciendo las necesidades de la empresa y de su equipo. tomando estos pasos

Si el código no se beneficia de su análisis, si los nombres de campo no se han convertido en expresivos de la intención del código y los métodos no se han desglosado en fragmentos legibles, entonces el negocio ha perdido algo de valor: su estado de comprensión. Con herramientas como Visual Studio y ReSharper, estos tipos de refactorización son seguros, lógicamente neutros y de gran valor potencial en la productividad y confianza futuras del desarrollador.

Como dice el tío Bob Martin: "Siempre deje el campamento más limpio de lo que lo encontró".

Esta es una pregunta para hacerle a la gerencia de su empresa.

¿Tiene el tiempo y los recursos necesarios para regresar y realizar cambios en el código anterior?

¿Tiene el tiempo y los recursos para que un equipo de control de calidad PRUEBE lo que ha cambiado para asegurarse de que no esté roto?

He caído en esta trampa antes, donde estaría en un módulo arreglando un error, y veo el código que yo u otra persona escribí que era ineficiente o poco elegante, cámbielo y terminé con más problemas que tratar que si solo lo solucionara el error que me encargaron arreglar.

Depende.

Si el código en cuestión está realmente roto, de modo que contiene errores que inevitablemente aparecerán en un punto (por ejemplo, algún contador que en algún momento se desbordará y causará problemas desagradables), entonces vale la pena repararlos, pero si usted primero, coloque todas las medidas de seguridad posibles para evitar la introducción de nuevos errores: asegúrese de tener pruebas unitarias significativas que cubran todo lo que toca, haga que todos los cambios sean revisados ​​por alguien competente, insista en realizar pruebas exhaustivas, asegúrese de que pueda volver al anterior versión en cualquier momento, haga una copia de seguridad de los datos antes de entrar en producción, despliegue primero en un entorno de aceptación y haga que lo prueben los usuarios reales, etc. También querrá obtener la aprobación antes de seguir adelante: si el error es realmente una bomba de tiempo , y su gerente es algo competente,podrá convencerlo para que le permita arreglarlo (y si no obtiene la aprobación, entonces tal vez eso sea una señal de que está equivocado).

OTOH, si su queja es la mera falta de elegancia del código, entonces no se atreva a tocarlo. Ha estado prestando un servicio fiel en producción durante bastante tiempo, cambiar el código solo lo satisfaría, pero no agregaría ningún valor y, como cada cambio, existe el riesgo de que rompa algo. Incluso si no lo hace, su tiempo es valioso (literalmente: le pagan por lo que hace, por lo que cada minuto de su tiempo cuesta dinero), y dado que no está agregando ningún valor real, tal cambio sería Una pérdida neta para la empresa y el proyecto.