guru - refactoring translate

¿Debo volver y arreglar el trabajo cuando aprendas algo nuevo/mejor? (16)

"Nuevo / mejor" no es un sustituto para "bien probado en el campo". Si algo en mi código ha estado funcionando de manera confiable durante años, no lo tocaré.

Piense en su código como si fuera un cangrejo herradura : la naturaleza ha inventado formas "mejores" de hacer las cosas desde que aparecieron por primera vez, pero todavía están ahí y siguen siendo fuertes.

Teniendo en cuenta que todos estamos aprendiendo constantemente, todos tenemos que encontrar un punto en el que aprendemos algo realmente increíble que mejora significativamente nuestro código o partes de él.

La pregunta es, cuando haya aprendido alguna nueva técnica, estrategia o lo que sea, ¿debe o debe volver al código que sabe que funciona, pero podría ser mucho mejor / mantenible / más rápido / generalmente mejorado e implementar este nuevo conocimiento?

Entiendo el concepto de "si no está roto, no lo arregles", pero ¿cuándo se convierte eso en perder orgullo en el código que ya has escrito y qué dice para refactorizar?

¿Tiene una buena cobertura de prueba unitaria? Si lo hace y confía en que puede hacer el cambio sin romper nada, ¿por qué no?

Solo haría esto si estuviera seguro de que la forma "mejorada" era realmente mejor.

A pesar del Triángulo de Proyecto de Calidad / Presupuesto / Tiempo, no debe considerar refactorizar su código a menos que:

El código está defectuoso / no está funcionando con el resto de la aplicación.
Habrá una nueva actualización de características que utilizará su código experimentado;)
es un proyecto no empresarial (el blog web de su madre escrito hace aproximadamente 10 años usando PHP y archivos de texto) o un proyecto de código abierto: puede obtener satisfacción y experiencia mientras refactoriza.
Cuando sus compañeros de trabajo están enojados cuando usan su código.

Serás un mejor programador cuando escribas más.

Buena pregunta y una en la que a menudo pienso. A medida que los programadores evolucionen, habrá menos recursos para mantener los sistemas heredados y, por lo tanto, es importante no dejar que los sistemas se vuelvan demasiado viejos, de lo contrario, resultará caro mantenerlos en el futuro.

Reescribir un sistema completo no es una tarea que deba tomarse a la ligera. Los años de pequeñas correcciones de errores aquí y allá serán difíciles de capturar desde el principio de nuevo, por lo que se necesita mucho cuidado.

Si puede reducir 1000 líneas de código a 100, sugeriría que vale la pena hacerlo. Si eso significa implementar un marco completamente nuevo para lograr esto, pensaría lo contrario hasta que los beneficios superen con creces las desventajas.

En general, no, "si no está roto, no lo arregles". Sin embargo, si hiciste trucos / soluciones sustanciales para que algo funcionara y sabes que esto causará problemas más tarde, entonces generalmente es conveniente refactorizarlo.

Cada decisión se basa en el esfuerzo / riesgo frente a la recompensa. Si conoce bien el alcance del cambio y puede estimar el costo de la reparación con precisión, puede dar sus frutos. Sin embargo, si se trata de un cambio de gran alcance, esto generalmente conduce a un síndrome de la versión 2 donde empiezas a reescribir todo y ahí está el problema ...

Mi opinión: uno debería regresar y arreglar el trabajo "de trabajo" cuando alguien está pagando para que lo arreglen.

Por supuesto, soy un consultor capitalista impenitente, y la mayor parte de mi trabajo es básicamente un cliente que aparece con una solicitud para la aplicación XYZ y la construyo para ellos.

Dicho esto, para mi proyecto de juego (un lector de .BR CBR de código abierto) siempre estoy feliz de implementar de inmediato cosas nuevas en él, pero una vez más, para eso es.

No hay reglas duras y rápidas, pero en general la forma en que me he acercado es: si es para un proyecto personal, por supuesto. Si está en el dólar de otra persona, generalmente, usted no puede arreglarlo hasta que el cliente desee el beneficio de una mayor capacidad de mantenimiento / rendimiento que estará entregando o hasta que necesite tocar ese código para realizar otras modificaciones de todos modos. En cualquier caso, trate de asegurarse de que tiene una cobertura de prueba que le asegure que no romperá ninguna funcionalidad existente.

Nunca siento que el código de reescritura que escribiste en el pasado valga la pena a menos que se rompa, porque a menudo se rompe de una manera tan fundamental que comenzarás de cero. Centra tus habilidades Jedi recién adquiridas en lugar de nuevos desafíos.

Dicho esto, en caso de que usted lo refactorice, asegúrese de tener esos casos de prueba listos para ayudarlo a capturar las regresiones que introducirá.

OMI, esto depende un poco de algunos factores:

¿Proyecto actual o no? ¿Volvería a un proyecto anterior para hacer el cambio y abrir una lata de gusanos para hacer esto? Donde trabajo, está nuestro proyecto actual y, si bien puedo aprender esto y aquello, no voy a entrar en proyectos más antiguos y crear nuevos problemas al tratar de aplicar algo que pensé que sería simple. Otro pensamiento aquí sería tomar lo que está en SourceSafe y trasladarlo a Subversion, lo que puede ser útil para tener solo un software para el control de versiones, pero es probable que no se considere universalmente como una buena inversión de tiempo como la mayoría de los desarrolladores aquí están acostumbrados a utilizando ambos.
Edad del código: ¿Es este código en el que trabajé recientemente o pasaría mucho tiempo en comprender lo que hice cuando? Si bien esto es similar al anterior, mi proyecto de trabajo actual ha estado en marcha desde junio de 2008, por lo que hay cosas en las que trabajé hace un año o más que tal vez no valgan la pena volver atrás y cambiar.
Escala de cambio: ¿esto va a tomar semanas o solo unas pocas horas? Esto también es algo que se debe tener en cuenta, ya que los pequeños cambios a veces pueden llevar a horas de trabajo solucionando esto y que se convierten en nuevos errores debido a los efectos secundarios del cambio.

Esas son algunas cosas que me guiarían, además de tratar de recordar que solo porque algo pueda parecer mejor, no es necesariamente algo que se use en todas partes. Por ejemplo, tratar de usar un taladro en un clavo no es una buena idea, pero si acaba de aprender a usar un taladro y quiere usarlo en cualquier lugar , entonces puede haber problemas en los que otras herramientas, como un martillo o una llave, pueden ser muy útiles. más útil, así que no olvide que existe la herramienta adecuada para el trabajo que también puede valer la pena.

Para abordar parte de su pregunta:

Donde trabajo, sería un error ir a editar cosas que no están rotas. En un entorno de producción, donde las personas utilizan su código todo el día todos los días, se le reprendería por "modificar" el código que aún no se ha informado como roto. En la posibilidad (preferiblemente) reducida de que cometas un error tipográfico o cambies accidentalmente alguna funcionalidad, alguien más sufrirá mientras resuelven los problemas. En otras palabras, el desarrollo va a causar problemas de apoyo. Además, pagarle a alguien para que realice cambios en algo que no está roto es una práctica que mi empleador tendería a evitar.

Personalmente para mí es una cosa del tiempo. Si aprendo algo "nuevo e impresionante", tomo una nota mental para implementarlo en cualquier código nuevo que escriba en el futuro.

Tratar de implementar esto en el código antiguo requiere mucho tiempo para cambiarlo, pero también para solucionar cualquier problema que pueda surgir posteriormente en la línea debido al cambio que he realizado. Tratar de explicarle a mi jefe lo que salió mal en estos casos es extremadamente difícil ya que no es un programador y no entiende el orgullo que tenemos por el código que escribimos.

Sin embargo, si vuelvo y reviso el código antiguo porque tengo que cambiar algo (solucionar un problema, implementar una nueva función, etc.) y ese código me hace pensar (ay, ¿en qué estaba pensando?) Entonces sí, cambio Es porque es algo en lo que estoy trabajando de todos modos.

Sí, si el tiempo lo permite. Por lo general no lo hace.

Si estamos hablando de código de producción, diría que realice los cambios si:

Puede ahorrar tiempo sin poner en peligro otros proyectos / programas de lanzamiento.
Las mejoras harán que la aplicación sea más eficiente / rápida.
Si la mejora del rendimiento no es sustancial desde el punto de vista del usuario típico, implemente estos cambios como parte de una versión con nuevas características (no haga una versión solo de refactorización, a menos que sea en gran medida transparente para los usuarios)
Tienes tu código bajo control de código fuente. "Si no está roto, no lo arregle" solo se aplica cuando en un momento dado no puede regresar al estado ininterrumpido. El control de la fuente es crítico para cambios de este tipo.
Tiene pruebas unitarias alrededor de la mayoría de los componentes que se volverán a trabajar. No desea arruinar nada para los usuarios solo por un intento de refactorización; La mejor manera de evitar esto es tener pruebas que verifiquen que el comportamiento del antes y el después sea idéntico.

Supongo que eso depende de si es código para proyectos personales o de trabajo. Si es trabajo, obviamente depende de tu jefe al final. Si puede convencerlos de que esto debe hacerse y ellos están dispuestos a darle tiempo libre para que lo hagan otros proyectos, entonces hágalo.

Refactorizar el código [de producción] existente que, de otro modo, es funcional y generalmente satisface a sus usuarios finales (y en menor grado a sus mantenedores) es, en general, una mala idea . Aquí es por qué

A menudo no tiene sentido económico.
Presenta el riesgo (¡la certeza!) De introducir nuevos errores, que luego requerirán una solución y que interrumpirán a los usuarios finales.
A menudo, nuestras ideas sobre "hacer las cosas mejor" están simplemente ligadas a una moda o concepto erróneo: mantener las nuevas ideas para el nuevo código ;-)

A un nivel más filosófico hay dos puntos a considerar:

La distinción entre ingeniería y diseño elegante / perfecto.
¡La ingeniería nos permite lidiar con las imperfecciones en el diseño!
Entonces, si bien es útil y, a menudo, es beneficioso para esforzarse por lograr la forma más elegante de diseñar cosas y utilizar herramientas que permiten producir aplicaciones prácticas y viables, aunque sus partes individuales pueden ser menos que óptimas.
Las ventajas relativas y los inconvenientes de la creación frente a la evolución.
Aunque la analogía con la evolución biológica se rompe porque la evolución del software es más directa (es decir, reintroduce fragmentos del creacionismo durante la evolución), debemos tener cuidado de que la evolución continua de un producto de software probablemente incremente la complejidad general de ese sistema.

Pienso en esto todo el tiempo y no es una pregunta fácil de responder. Básicamente, si es probable que el código que quiero reescribir nunca se vuelva a utilizar, no lo hago. A menos que sea algo que escribí fuera del trabajo. Luego, si fue un programa lo suficientemente bueno, lo más probable es que lo reescriba. Sin embargo, si está relacionado con el trabajo, probablemente no lo haría a menos que realmente pueda hacer que el código sea mucho más sólido.

Pero no lo haría a menos que sepa a ciencia cierta que es una mejora.