He visto el libro Trabajar con eficacia con el código heredado recomendado algunas veces. ¿Cuáles son los puntos clave de este libro?
¿Hay mucho más para tratar con el código heredado que agregar pruebas de unidad / integración y luego refactorizar?
He visto el libro Trabajar con eficacia con el código heredado recomendado algunas veces. ¿Cuáles son los puntos clave de este libro?
¿Hay mucho más para tratar con el código heredado que agregar pruebas de unidad / integración y luego refactorizar?
El problema clave con el código heredado es que no tiene pruebas. Así que necesitas agregar algunos (y luego más ...).
Esto en sí mismo requeriría mucho trabajo, como anotó @mattnz. Pero el problema especial del código heredado es que nunca fue diseñado para ser comprobable . Así que, por lo general, es un gran desorden de espaguetis en código, donde es muy difícil o completamente imposible aislar partes pequeñas para probarlas en la unidad. Por lo tanto, antes de la prueba de unidad, debe refactorizar el código para hacerlo más comprobable.
Sin embargo, para refactorizar de forma segura, debes realizar pruebas de unidad para verificar que no has roto nada con tus cambios ... Esta es la captura 22 del código heredado.
El libro te enseña cómo salir de esta captura haciendo los cambios mínimos y más seguros al código para habilitar las primeras pruebas unitarias. No están diseñados para hacer que el diseño sea más agradable, solo para habilitar pruebas unitarias. De hecho, a veces hacen que el diseño sea más feo o más complejo. Sin embargo, le permiten escribir pruebas, y una vez que haya implementado las pruebas unitarias, tiene la libertad de mejorar el diseño.
Hay muchos trucos para hacer que el código sea verificable: algunos son obvios y otros no. Hay métodos que nunca hubiera pensado en mí mismo, sin haber leído el libro. Pero lo que es aún más importante es que Feathers explica qué hace que una unidad de código sea verificable. Debe cortar las dependencias e introducir barreras en su código, pero por dos razones distintas:
Cortar dependencias de forma segura puede ser complicado. La introducción de interfaces, simulacros y inyección de dependencia es limpia y agradable como objetivo, pero no necesariamente segura en este momento. Así que a veces tenemos que recurrir a la subclase de la clase bajo prueba para anular algún método que normalmente, por ejemplo. iniciar una solicitud directa a un DB. Otras veces, incluso podríamos necesitar reemplazar una clase de dependencia / jar por una falsa en el entorno de prueba ...
Para mí, el concepto más importante introducido por Feathers es costuras . Una costura es un lugar en el código donde puedes cambiar el comportamiento de tu programa sin modificar el código en sí mismo . La creación de uniones en su código permite separar el fragmento de código bajo prueba, pero también le permite detectar el comportamiento del código bajo prueba, incluso cuando es difícil o imposible hacerlo directamente (por ejemplo, porque la llamada realiza cambios en otro objeto o subsistema, cuyo estado no es posible consultar directamente desde el método de prueba).
Este conocimiento le permite observar las semillas de la capacidad de prueba en el montón de código más desagradable y encontrar los cambios mínimos, menos perturbadores y más seguros para llegar allí. En otras palabras, para evitar hacer refacciones "obvias" que tengan el riesgo de romper el código sin que te des cuenta, porque aún no tienes las pruebas unitarias para detectar eso.
Formas rápidas de obtener los puntos clave de Cómo trabajar con eficacia con el código heredado
Trabajo en una base de código de millones de líneas de código, algunas de las cuales se remontan a los años 80. Es solo software, así que solo es cuestión de escribir algunas pruebas unitarias, para que pueda ir y refactorizarlo, y hacerlo mucho mejor.
La palabra clave aquí es justa: es una palabra de cuatro letras que no pertenece al vocabulario de ningún programador, por no hablar de alguien que está trabajando en sistemas heredados.
¿Cuánto tiempo crees que se necesita para escribir una prueba de unidad, para probar una hora de esfuerzo de desarrollo? Por el bien de la discusión, digamos otra hora.
¿Cuánto tiempo se invierte en ese sistema legado de 20 años y 20 millones de líneas? Digamos, 20 desarrolladores por 20 años por 2000 horas / año (trabajaron bastante duro). Ahora escojamos un número: tienes nuevas computadoras y nuevas herramientas, y eres mucho más inteligente que los tipos que escribieron esta pieza de $% ^^ en primer lugar. Digamos que vales 10 de ellos. ¿Tienes 40 años hombre, bueno, tienes ...?
Entonces, la respuesta a tu pregunta es que hay mucho más. Por ejemplo, esa rutina es de 1000 líneas (tengo algunas que tienen más de 5000), es demasiado compleja y es un pedazo de espagueti. Solo le tomaría (otra palabra de cuatro letras) un par de días re-factorizarlo en unas pocas rutinas de 100 líneas y unos 20 ayudantes más, ¿verdad? INCORRECTO. Oculto en esas 1000 líneas hay 100 correcciones de errores, cada una de las cuales es un requisito del usuario no documentado o un caso de borde oscuro. Son 1000 líneas porque la rutina original de 100 líneas no hizo el trabajo.
Debe trabajar con la configuración mental " si no está roto, no lo haga. arréglalo ". Cuando se rompe, debe ser muy cuidadoso cuando lo arregle, ya que, al mejorarlo, no cambia accidentalmente otra cosa. Tenga en cuenta que "quiebra" puede incluir un código que no se puede mantener, pero que funciona correctamente, depende del sistema y su uso. Pregunte "¿qué pasa si lo arruino y lo empeoro?", Porque un día lo hará y tendrá que decirle al jefe de los jefes por qué eligió hacerlo.
Estos sistemas siempre se pueden mejorar. Tendrá un presupuesto para trabajar, una línea de tiempo, lo que sea. Si no lo haces, ve y haz uno. Deja de hacerlo mejor cuando el dinero / tiempo se haya agotado. Agrega una característica, date tiempo para hacerlo un poco mejor. Arregle un error - nuevamente, pase un poco de tiempo extra y hágalo mejor. Nunca lo entregues peor de lo que era cuando empezaste.
Hay dos puntos clave para quitar del libro.
Como otros respondedores han señalado, tratar de actualizar de manera preventiva su código heredado existente es un tarea de los tontos . En su lugar, siempre que tenga que realizar un cambio en el código heredado (para una nueva característica o una solución de error), tómese el tiempo para eliminar su estado heredado.
En una cáscara de nuez que es verdad: de lo que se trata es agregar pruebas y refactorizar.
Pero el libro le brinda muchas técnicas diferentes para hacerlo con un código que es muy difícil de probar y refactorizar de forma segura.
Lea otras preguntas en las etiquetas testing refactoring legacy books