php - poner - ¿Vale la pena intentar escribir pruebas para el sitio más estrechamente acoplado del mundo?
no funcionan los hashtags en instagram 2018 (13)
Imagine que el 90% de su trabajo se limita a clasificar problemas en un sitio web muy masivo y muy roto. Imagine que este sitio web está escrito en el código PHP más estrechamente unido y menos cohesivo que jamás haya visto, el tipo de código que agregaría los desarrolladores originales a su lista de "bofetadas". Imagine que esta aplicación web se compone de 4 partes muy dispares (1 comercial, 2 "reutilizadas" y 1 personalizada) y una tonelada de cinta adhesiva y calzas virtuales. Imagine que contiene el tipo de prácticas de programación en las que los principales componentes del sitio web realmente se basan en que las cosas NO funcionan correctamente, y arreglar estas cosas rotas generalmente rompe otras cosas. Imagine que sabe por demasiadas malas experiencias que cambiar una parte aparentemente inocua del sitio web, como dividir un campo de "nombre" en dos campos separados "primero" y "último", pondrá al sitio de rodillas y requerirá horas de retrocesos, fusiones y parches. Imagínese suplicarle al cliente durante años que simplemente abandone el código y comience de nuevo, pero que se encuentre con la desesperación de Enterprise-Grade y las escrituras. Luego, imagine obtener tickets ASAP / EMERGENCY para implementar nuevas características que en cualquier otro sitio web tardarían 4 horas, pero usted sabe mejor con este sitio, por lo que citará 40 horas, luego lo soplará y facturará 80 horas, pero está bien porque el cliente está acostumbrado a eso con su sitio web.
Aquí hay algunas otras cosas que también deberías imaginar:
- no hay pruebas en absoluto ahora
- hay googleteen diferentes capas de inicios de sesión. Algunos clientes realmente tienen 3 cuentas diferentes para diferentes secciones del sitio web
- cuando digo "estrechamente unido", quiero decir que los bucles de las declaraciones include / require probablemente se trazarían como un nudo celta
- cuando digo "menos cohesivo" quiero decir que algunas cosas se organizan de forma similar a MVC, pero en realidad no es MVC. En algunos casos, puede llevarle varias horas descubrir cómo se correlaciona el URI A con el archivo B
- la interfaz de usuario se escribió como "obstructiva" e "inaccesible" fueron las palabras de moda del día
Imaginando todo eso, ¿vale la pena intentar alcanzar incluso un nivel moderado de cobertura de prueba? ¿O debería usted, en este escenario imaginario, seguir haciendo lo mejor que pueda con lo que se le ha dado y esperando, rezando, incluso sacrificando, que el cliente acuerde reescribir uno de estos días y ENTONCES pueda comenzar a escribir pruebas?
APÉNDICE
Como muchos de ustedes lo mencionaron: me he acercado a la posibilidad de volver a escribir en cada oportunidad que he tenido hasta la fecha. Las personas de marketing con las que trabajo saben que su código es basura, y saben que es la culpa de la empresa de "oferta más baja" con la que trabajaron originalmente. Probablemente he sobrepasado mis límites como contratista al señalar que gastan una tonelada de dinero en mí para proporcionar cuidados de hospicio para este sitio, y que al volver a desarrollarlo desde cero verían un retorno de la inversión muy rápidamente. También he dicho que me niego a reescribir el sitio tal como está, porque en realidad no hace lo que ellos quieren que haga de todos modos. El plan es reescribir el estilo BDD, pero conseguir todos los actores clave en un solo lugar es difícil, y aún no estoy seguro de que sepan lo que necesitan. En cualquier caso, espero que sea un proyecto muy grande.
¡Gracias por todos los comentarios hasta ahora!
Absolutamente no.
Si dices que varias cosas dependen de otras cosas que específicamente no funcionan , ¿cómo puedes empezar a probarlas?
Personalmente, diría que lo desechen y comiencen de nuevo. ¿Cuatro horas de funciones que toman 80? Espero que esto sea una exageración. Los dolores de cabeza que debes tener.
Comenzaría con una propuesta muy firme para volver a escribir la base de código. A los clientes que se estrujan la mano se les debe decir la verdad indirecta algunas veces. ¿Cuántos otros desarrolladores trabajarán con una base rota? Haga algunos gráficos bonitos de costo / beneficio.
Por supuesto, escriba pruebas para el código que escriba . No descuides eso. Estoy diciendo que no trataría de escribir pruebas en la base de códigos existente.
Darle una oportunidad
Escribir pruebas te permite refactorizar. Si escribe sus pruebas a un nivel lo suficientemente alto, puede hacerlo para que pueda refactorizar sin tener que volver a escribir las pruebas todas las veces.
Es lo menos que vale la pena ir, en una pequeña parte del sitio (sé que no podrás aislar por completo ninguna parte, pero igual puedes orientar la parte).
Tal vez establecer un presupuesto de tiempo (depende de usted para averiguar qué es asequible / vale la pena), luego probar algunas pruebas y algunas refactorizaciones. Si no funciona, retrocede. Si lo hace, continúa.
¡Buena suerte!
Absolutamente escribir pruebas. Especialmente en un entorno de acoplamiento cerrado, las pruebas serán aún más críticas (ya que una corrección de errores en un área puede afectar drásticamente a otras áreas debido al acoplamiento ajustado).
Ahora, date cuenta de que esto probablemente no sea una tarea trivial. Para escribir pruebas, necesitarás modificar el código para que sea comprobable. Para modificar el código, debes tener pruebas. Entonces estás atrapado en un ciclo de dependencia ...
Sin embargo, mira los posibles beneficios. Eso debería decirle si realmente vale la pena o no.
Si comienzas, comienza pequeño. Escoge una pequeña pieza que se ve vagamente acoplada, y prueba eso. Luego encuentra algo más que no esté tan enredado. Pruebe primero todas las piezas más sueltas (la fruta que cuelga más abajo). Luego, una vez que llegue a las partes realmente apretadas, ambos se sentirán más cómodos y (con suerte) tendrán más información sobre lo que realmente deben hacer.
Recuerde, no necesita una cobertura del 100% para obtener los beneficios. Cada prueba agrega significado ...
Comience haciendo una caja negra, pruebas funcionales, partes conectadas o partes y piezas aquí y allá. Esto hace que el desarrollo continuo y la refactorización / reescritura sean mucho más fáciles.
He estado allí, haciendo eso.
Tomó un tiempo hasta que pudimos comenzar a agregar pruebas unitarias, pero finalmente llegamos allí.
Todavía está lejos de ser a prueba de balas, pero todos los desarrolladores tienen mucha más confianza para atreverse a cambiar / corregir cosas cuando sabes que hay un banco de pruebas esperando para verificar los cambios de tu código.
Desde su escenario, debe tener una larga lista de áreas frágiles del código que tienden a verse afectadas por cambios inocuos (o al menos áreas que absolutamente deben funcionar). Si puede realizar pruebas contra esta lista, tiene una forma rápida de descubrir cuándo un cambio que está implementando ha roto algo.
En primer lugar, si su cliente está acostumbrado a que sus estimaciones sean la mitad de lo que realmente cuesta, ¡corrija sus cálculos! Es bueno que el cliente esté ''OK'' con las estimaciones sin descuento, pero es fundamental que sus estimaciones estén más en línea con el esfuerzo realmente necesario. Sin eso, qué cliente aceptaría alguna vez una refactorización importante, y mucho menos una reescritura. Así que obtenga un poco de historia de estar en lo cierto con las estimaciones, luego muévase a modificar el proyecto.
En cuanto a escribir pruebas. Eso es aún más vital para lo que describes que para un proyecto de campo verde. En cada fragmento de código que toques, pregúntate si es posible desvincular el comportamiento que debería existir del comportamiento que está ahí. Escriba el código como debería (con pruebas) y luego agregue una capa de abstracción para que sea como es actualmente (¡y también pruebe eso!). Sentirás que estás contribuyendo al desastre, y lo estarás, pero lentamente, con el tiempo, las pruebas te darán confianza en estas áreas.
Si es algo así como lo que he estado tratando, estará en el orden de extraer un único método en una clase de ayuda y volver a parchearlo en el código existente, apenas parece valer la pena, pero vale la pena cada vez tienes que tocar esa parte del sistema de nuevo. Como dicen, "déjalo mejor de lo que lo encontraste" y comenzarás a encontrarlo en mejor forma cada vez que vuelvas a él. Las pruebas son la mejor manera de dejarlo mejor de lo que lo encontraste.
Pero en serio, es necesario que el cliente confíe en la precisión de sus estimaciones antes de que tenga plena confianza en su capacidad para manejar una nueva versión.
En teoría, definitivamente. Cuanto más estrechamente acoplados, errores en el proceso de mantenimiento, más importantes son las pruebas. En la práctica, ¡aléjate y vive otro día!
Es posible que desee considerar la facturación de otras 40 horas / iteración para crear un modelo de BDD (dominio) de cómo funciona la aplicación o mejor: debería funcionar. Eso crea un marco agradable donde puede documentar las características necesarias. Cuando el modelo esté lo suficientemente completo, puede estimar cuánto tiempo necesitaría para convertirlo a una aplicación en funcionamiento.
Es probable que no obtenga una cobertura completa durante un tiempo. Pero puede escribir pruebas para nuevos códigos / características que implemente. Empieza pequeño. No intentes hacer todo de una vez.
¿Y quizás vale la pena leer el libro " Trabajar eficazmente con Legacy Code "?
Editar
También recomendaría ver esta presentación de Uncle Bob que toca este escenario y cómo transformar una base de código incorrecta, en una buena usando "Ampliación progresiva"
Editar 2
Comience por encontrar cualquier función autónoma. Funciones que no hacen referencia a nada más que a los argumentos pasados. Moverlos y organizarlos en clases auxiliares. Es probable que esto sea solo temporal, ya que muchos terminarán en clases diferentes más adelante, pero esto ayudará a identificar algunos códigos duplicados y a comenzar a organizarlos. Luego, observe cómo se usan estos, escriba pruebas basadas en estos usos. Y dale palmaditas en la espalda. Ahora ha comenzado a hacer que su código sea mantenible.
Editar 3
Con gran rapidez, InfoQ acaba de publicar otro artículo sobre cómo hacer refactorizaciones a gran escala, que es específicamente este tipo de cosas, y otro artículo más antiguo llamado Refactor o Reescribir. y hay técnicas como el Método Mikado donde tienes que darte cuenta de que no siempre puedes hacer el movimiento que deseas en un solo paso, tienes que hacer otros movimientos para configurar y realizar tu objetivo.
Esto suena a que para que sea comprobable del todo , tendrías que volver a escribir partes del sistema desde cero, inevitablemente causando toneladas de errores en el proceso.
Según lo que describes, no vale la pena poner ese tipo de esfuerzo en el viejo sistema.
Bajo ninguna circunstancia intentaría introducir pruebas para esto, pero trataré de obtener permiso para reescribir lo antes posible.
Si su cliente no ve la luz, considere si la refacturación del proyecto vale la pena darle tiempo propio: trabajar con código limpio es mucho mejor para el bienestar de uno ...
Lo más importante (después de comprar Trabajar eficientemente con código heredado ) es comenzar en pequeño. Trabajo en varios proyectos, cada varios miles de líneas de PHP de largo y, a menudo, sin una sola función (y ni siquiera pienso en objetos) y cada vez que tengo que cambiar el código, trato de refactorizar la pieza en una función y escribir una prueba para ella . Esto se combina con extensas pruebas manuales de esa parte, así puedo estar seguro de que funciona como antes. Cuando tengo varias funciones para cosas similares, las muevo como métodos estáticos a una clase y luego, paso a paso, las reemplazo por un código adecuado orientado a objetos.
Cada paso de moverlo a una función para cambiarlo a una clase real está rodeado de pruebas de unidad (no muy bueno, ya que el 90% del código son consultas SQL y es casi imposible configurar una base de datos de prueba confiable, pero todavía puedo prueba el comportamiento).
Como se repite una gran cantidad de códigos (encontré una sola consulta SQL repetida 13 veces en un solo archivo y muchas veces más en los otros 50 archivos de ese proyecto) pude cambiar todos los demás lugares, pero no lo hago, ya que estos no son probados tampoco puedo estar seguro de que el código circundante no dependa de ese código de alguna manera extraña (piense en global ). Ese código se puede cambiar tan pronto como tenga que tocar ese código de todos modos.
Es un trabajo largo y tedioso y cada vez que veo el código, siento un paso (o más bien un salto) más cerca de la falla mental, pero la calidad del código mejorará (lenta pero principalmente de manera confiable).
Su situación parece ser bastante similar, entonces tal vez mis ideas podrían ayudarlo con su código.
En breve
Comience poco a poco, cambie solo aquello en lo que trabaja y comience a escribir solo pruebas unitarias limitadas y amplíelas cuanto más aprenda sobre el sistema.
No puedes desecharlo. El cliente no va a dejarlo, y puede que no sea el mejor camino de todos modos.
Entonces, en lugar de cotizar 40 horas para una solución que debería haber tomado minutos ... cite 60. El cliente parece A-OK con eso. Usa 40 para corregir y 20 para refactorizar ... y escribe pruebas sobre lo que refactorizas. Si el 60 corre a 100, gasta 120; 80 para corregir y 40 para refactorizar / probar.
Construya a tiempo para mejorar la cosa en sus estimaciones normales, o encuentre un nuevo trabajo; la situación actual, parece, te llevará a odiar nuestro campo.
Si las cosas se comportan de manera confiable, puedes probarlas, ¿verdad? Su sistema funciona la mayor parte del tiempo, por lo que puede probar esas condiciones de éxito.
..innocuo parte del sitio web, como dividir un campo de "nombre" en dos campos separados "primero" y "último", pondrá el sitio de rodillas y requerirá horas de retrocesos
Dividir un campo aparte, como el nombre y el apellido suena como una potencial gran cosa, pero parece que has aprendido la lección. Al menos intente obtener financiación para un sistema de prueba de tamaño completo y establezca los procedimientos para que la transferencia de datos de producción a la misma sea automática, para que pueda probar completamente esta cosa.
Suena bastante horrible sin embargo. Es hora de polvo del ole resume?