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

A menos que esté realizando cambios en este "código antiguo" para corregir errores o agregar funciones, no me molestaría en mejorarlo por el simple hecho de hacerlo. Si desea mejorarlo en el futuro, asegúrese de tener pruebas de unidad que prueben el código antes de comenzar a refactorizarlo.

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

Refactorice las áreas de código que necesita modificar con mayor 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 visitarlos, 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 da 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 el código heredado y debe esperar que las refactorizaciones grandes creen regresiones de vez en cuando.

Si necesita agregar funciones y su diseño lo está ralentizando o causando duplicación, entonces refactorice . Cuando diseño el 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. Por el momento, he agregado un tercer ciclo de funciones / refactorización, mi refactorización ya se está pagando y mi código compartido es bastante estable.

TLDR: refactor cuando sea necesario, no hay obligación.

Todo lo que haces tiene un costo. Tienes un tiempo limitado para programar. Todo lo que haces en la programación debe ser visto en contra, "¿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?), la calidad es gratuita. Es mejor mejorar tu código. Vas a aprender algo Funcionará mejor Se venderá más.

La verdadera pregunta es ¿qué es lo mejor que puedes hacer con tu tiempo? Y luego tienes que hacer concesiones.

¿Se venderá más software?

¿Causará menos dolores de cabeza para soportar?

¿Qué aprenderás?

¿Será más agradable estéticamente?

¿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 concesiones son la razón por la cual la economía es importante para los programadores. Joel lo dijo antes que yo, y un viejo mentor me lo dijo incluso antes que Joel.

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

Creo que deberías comenzar por hacerte 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 está causando problemas cuando mantiene el software?
• ¿El código es completamente autónomo?
• ¿Tiene planes de actualizar o reemplazar el código en algún momento en el futuro inmediato?
• ¿Hay algún caso comercial sólido que pueda presentar para actualizar el código que le preocupa?

Si hay algo que he aprendido con los años, es que no puedes darte el lujo de 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 para 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ó antes se convierta en un problema heredado que se vuelva más difícil de manejar 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 será el mantenimiento a medida que pase el tiempo. Esta es esencialmente una pregunta acerca de la deuda técnica, y si vale la pena pagar esa deuda usando un poco de mantenimiento quirúrgico ahora, o si la deuda es lo suficientemente pequeña como para dejarla pasar por un tiempo.

Estas son preguntas que realmente debe sopesar con su carga de trabajo presente y futura, y debe ser discutida en detalle con su equipo de administración y equipo para obtener una mejor comprensión de dónde invertir sus recursos, y si su antiguo el código vale la pena el tiempo que puede necesitar dedicarlo, si es que lo hace. Si puede hacer un buen caso de negocios para introducir un cambio, entonces hágalo con todos los medios, pero si está enfrentando la necesidad de modificar el código porque se siente avergonzado por la forma en que lo escribió, sugiero que no haya Espacio para el orgullo personal cuando se trata de mantener el código antiguo. O 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 estuvo disponible para ti ayer.

Definitivamente no lo mejore solo por el simple hecho de mejorarlo. Como han dicho otros (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 estas partes y piezas que probablemente deseamos que nunca más vean la luz del día.

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

• Identifique a las personas en el equipo que realmente cavan retrocediendo y mejorando el código, como una especie de limpieza del cerebro o una tarea agradable y pequeña que da una sensación de logro, y encuentre tiempo en el calendario para que lo hagan Es sobre una base 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 de inactividad.

• Úselo como base para un ejercicio de aprendizaje. Para internos, estudiantes o miembros nuevos / junior del equipo, refactorizar el código antiguo con la guía de los miembros principales del equipo les da la oportunidad de comunicarse con los nuevos miembros del equipo, entender más sobre el sistema y adquirir el hábito de escribir / Actualización de pruebas unitarias y trabajo con integración continua. Es importante tener en cuenta que este ejercicio se realiza con orientación y se enmarca claramente como un ejercicio para mejorar el código porque no se ajusta a las normas / estándares 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 puedes estar seguro de que se comportará exactamente como debería, es mejor que lo dejes solo.

Desde la perspectiva de un ingeniero, seguro que me gustaría mucho trabajar en el 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 los resultados finales, la rentabilidad de su lugar de trabajo. Si no lo es, simplemente déjalo.

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

En cuanto a mí, la pregunta se puede reformular y generalizar: "¿Por qué alguien debería gastar un recurso adicional (tiempo, dinero, mental, etc.) si esa pieza concreta de código funciona bien ahora? ¿No es un desperdicio de recursos? (s)? "

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? (En este momento)
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 encontrar 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, deberías hacerte muchas preguntas. No hay una lista completa y definitiva de ellos. Solo tú y probablemente tus compañeros de equipo pueden encontrar la respuesta.

P.S. Me he dado cuenta de que tiendo a volver a escribir el código muy a menudo, mientras que mi amigo y mi compañero de equipo tienden a dejarlo intacto. Eso es porque respondemos a las preguntas mencionadas de manera diferente. Y tengo que decir que respondemos mal a menudo ... porque no podemos predecir el futuro.

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

Normalmente, puedes escribir mejor el código la segunda vez, aprendiste más sobre el dominio al escribirlo inicialmente.

No hay una respuesta simple para lo que vale la pena refracorar. En general, no debería hacerlo, a menos que a) sea un buen ejercicio de aprendizaje para usted ob) a la larga, ahorre tiempo con un mejor código. Recuerda que cada cambio arriesga errores.

Como nota al margen, yo recomendaría las pruebas de unidad. Es muy fácil deshacerte de refractar, especialmente si no tienes 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 programadas causan que se reduzca algo, no creo que la calidad de nuestro software deba considerarse siquiera, ese pequeño clip de papel animado, por otro lado ...

Ahora, si está trabajando y encuentra que el código con el que necesita interactuar no está escrito en el nivel que actualmente es capaz de escribir, entonces es razonable arreglarlo SI es capaz de 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 "solo cambiemos todo y oremos para que funcione" y me mordió lo suficientemente mal. Yo sugeriría buscar en las discusiones de Martin Fowler (ya sea su libro o uno de los muchos artículos ) al respecto. Parece que ha inspirado la mayor parte del pensamiento actual sobre el proceso.

Por supuesto, a veces es posible que no puedas limpiar el código como te gustaría. Joel Spolsky escribió un artículo sobre por qué es posible que desee dedicar unas pocas 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 ayude

Siento que refactorizar / mejorar el código antiguo define al programador. Querer 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 de varios ejes. ¿Cree que puede hacerlo más rápido, más pequeño, más eficiente en recursos, más legible, más información útil, resultados más precisos, más flexible, más general, capaz de ejecutarse en más sistemas, eliminar una dependencia en un producto separado?

¿Por qué su empresa debería pagarle para que dedique tiempo a reescribir este código, en lugar de escribir un nuevo código o reescribir algún otro código?

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

Presionar un cambio en la producción introduce una posibilidad no nula 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 tener en cuenta? ¿PERMITA 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 llegue a producción, entonces la oportunidad básicamente significa que usted está mirando el código por alguna razón, y no requiere mucho tiempo hacerlo. Puede revisarse según sea necesario si alguna vez ocurre un impulso, y omitirlo si se considera injustificado en ese momento. Si, por otro lado, está en producción ahora, como dije anteriormente, debe considerar si este cambio vale la pena: en términos del tiempo dedicado a la inserción y los beneficios de usar el nuevo código.

Una buena regla general es que si le tomó tiempo comprender 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 del negocio y de su equipo tomando estos pasos

Si el código no se beneficia de su análisis, si los nombres de los campos no expresan la intención del código y los métodos no se han dividido en partes legibles, entonces la empresa ha perdido algo de valor: su estado de comprensión . Con herramientas como Visual Studio y ReSharper, este tipo de refactorizaciones son seguras, neutrales y potencialmente de gran valor en la futura productividad y confianza del desarrollador.

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

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 antiguo?

¿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?

Caí en esta trampa antes donde estaría en un módulo que corrige un error, y veo el código que yo o alguien más escribió que era ineficiente o poco elegante, cámbielo y termine con más problemas que resolver que si Acabo de corregir el error que me encargaron de solucionar.

Depende.

Si el código en cuestión está realmente roto, de manera que contiene errores que inevitablemente surgirá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 lo hace, ponga en primer lugar todas las medidas de seguridad posibles para evitar la introducción de nuevos errores: asegúrese de tener pruebas de unidad 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 atrás en la versión antigua en cualquier momento, haga una copia de seguridad de los datos antes de comenzar la producción, desplácese primero a un entorno de aceptación y pida a los usuarios reales que la prueben, etc. También querrá obtener la aprobación antes de continuar: si el error es realmente una bomba de tiempo, y su gerente es un tanto competente, podrá convencerlo para que le permita repararlo (y si no obtiene la aprobación, tal vez sea una señal de que está equivocado).

OTOH, si tu queja es simplemente por falta de código, entonces no te atrevas a tocarlo. Ha estado prestando un servicio fiel en la 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: se le paga por lo que hace, por lo que cada minuto de su tiempo cuesta dinero), y como no está agregando ningún valor real, ese cambio sería una pérdida neta para la empresa y el proyecto.