Aplicación PHP de ingeniería inversa sin leer el código (feo)

7

Tengo este nuevo cliente, que tiene esta aplicación PHP. Fue escrito por un solo desarrollador que quería "crear otro marco" en 2005. Aproximadamente 3 años después, el desarrollador dejó la compañía y con él todos los conocimientos sobre lo que realmente está haciendo esta cosa.

Ahora, ya que la aplicación ya entró en producción, el gerente acaba de contratar a algunos desarrolladores / freelancers más (que ya no están disponibles) para corregir errores aquí y allá y desarrollar algunas funcionalidades más. Algunos intentaron seguir las pautas no documentadas del software, otros no.

Tal vez puedas imaginar cómo se ve el código hoy ... ¡es un completo desastre!

Hablé con el gerente y le dije lo que pienso de su software y logré que realmente pensara en reescribir la maldita cosa.

Pero aquí viene mi problema: para poder estimar el esfuerzo necesario para volver a escribir, necesitaría saber qué está haciendo la cosa. El gerente me puede decir desde su perspectiva lo que está haciendo, pero simplemente no hay conocimiento técnico al respecto. Y al igual que con todo el software que creció durante años, existen estos "casos especiales".

Básicamente, mi idea es "grabar / registrar" el sistema en vivo durante unas semanas para obtener una conclusión técnica, algo completa, de lo que está haciendo la mayor parte del tiempo y cuáles son las cosas que rara vez se tocan / usan. P.ej. ¿Qué fue la Solicitud y qué ruta tomó para rendir los resultados? Leer e intentar entender el código es imposible. Sin embargo, sería útil ver a qué clases / funciones se llaman y luego leerlas / entenderlas.

Entonces, ¿hay alguna herramienta para registrar / registrar solicitudes / respuestas de HTTP y qué gráfico de llamadas de la aplicación php activó? ¿Preferiblemente algo que no tendría que ser escrito en el código? Abandoné PHP hace años y estoy algo oxidado con mi Utilidad PHP y el Conjunto de herramientas de biblioteca estándar para saber algo que podría ayudarme aquí.

    
pregunta Manuel Schmidt 08.12.2011 - 16:32

5 respuestas

4
  

Entonces, ¿hay alguna herramienta para registrar / registrar solicitudes / respuestas de HTTP y qué gráfico de llamadas de la aplicación php activó? ¿Preferiblemente algo que no tendría que ser escrito en el código?

La funcionalidad de análisis de cobertura de código de xdebug lo ayudará a tener una idea de lo que se ejecuta en cada solicitud:

  

La cobertura de código le dice qué líneas de script (o conjunto de scripts) se han ejecutado durante una solicitud. Con esta información, por ejemplo, puede averiguar qué tan buenas son sus pruebas unitarias.

perfilador de xdebug genera información de perfiles en forma de un archivo compatible con Cachegrind, por lo que en teoría no tiene que hacer una Lote en código, ya que puede configurar xdebug a través de php.ini y htaccess .

Este es el enfoque práctico, no se detenga aquí, debe seguir los consejos dados por ChrisF y Imbéciles .

    
respondido por el yannis 08.12.2011 - 17:40
17

Si desea volver a escribir la aplicación, no necesita saber cómo hace lo que hace, pero sí necesita saber qué hace.

Siéntate con el administrador y recorre el sistema resaltando la funcionalidad que debe tener el sistema. Esto le dará una lista de funciones (por ejemplo, suponiendo que la aplicación es un sistema de blogs):

  • Crear usuario
  • Añadir publicación de blog
  • Publicar una publicación de blog en algún momento en el futuro.
  • Comentar en la publicación del blog
  • etc.

Tome capturas de pantalla de cada página para tener un documento del aspecto del sistema. Esto también le dará los objetos y campos que debe tener su modelo de datos.

Luego se va y especifica cuánto tiempo llevará implementar estas funciones utilizando el marco de su elección.

En ningún momento debes mirar el código existente. Está asignando la funcionalidad usuario , no la funcionalidad sistema .

    
respondido por el ChrisF 08.12.2011 - 17:03
6

Te has equivocado de año. Era el 2001 ... Espera, tú no eres mi viejo compañero de trabajo. Esto debe suceder en todas partes.

Cuando tuve que elegir entre reescribir o parchar a Frankenstein, estaba absolutamente claro que no iba a ocurrir una reescritura. No todos a la vez, de todos modos. En su lugar, fuimos página por página refactorizando de arriba a abajo (esto no era exactamente una arquitectura basada en modelos, por lo que pensar en el sitio como una colección de páginas era razonable). El "marco" en nuestro caso comenzó simple. %código%. Pero a medida que surgieron los casos especiales, esta función se convirtió en Draw_Info_Box(some_object) ... bueno, entiendes la idea. Comenzamos refactorizando estos para eliminar un parámetro adicional a la vez. Para algunos, tomamos la decisión de duplicar el código y eliminar el caso especial entre las dos versiones (nombres como "DoSomethingOrSomethingElse" se dividirían en "DoSomething" y "DoSomethingElse"). Para otros, los envolvimos en objetos simples y convertimos los parámetros adicionales en variables de estado del objeto. Esto permitió una refactorización más fácil más adelante.

Al dividirlo en unidades manejables (en nuestro caso, páginas individuales), algunas partes del sistema se hicieron más manejables mientras el sistema aún estaba en uso. Esto también permitió correcciones de errores más simples mientras se realizaba la refactorización (que era el caso en contra de la reescritura; aún había cosas que debían hacerse al sistema que se estaba usando).

En realidad me fui antes de que se reescribiera todo el sistema. Para entonces, algunas partes se habían reescrito más de una vez (eliminar un nivel del caos organizativo a menudo revelaba otro, pero teníamos un enfoque metodológico que nos permitía manejarlo).

Si estuviera comenzando algo similar hoy, en realidad comenzaría con las pruebas de Selenium en la aplicación y trataría de obtener algún tipo de métrica de cobertura de código de las pruebas. Luego haría el mismo trabajo de refactorización, pero me sentiría un poco más seguro de que los errores y las diferencias de comportamiento serían detectados.

    
respondido por el ccoakley 08.12.2011 - 17:43
4

Básicamente necesita documentar los sistemas en términos de Casos de uso \ Pantallas de usuario. Asegúrese de cubrir todas las pantallas del sistema en al menos uno de los casos de uso.

Luego, debe pasar por todas las pantallas y casos de uso mientras ejecuta un perfil de base de datos. Documentar todas las transacciones Db en cada pantalla. Pruebe cada campo para la validación de datos.

Pregunte a los usuarios sobre la integración del sistema, básicamente cualquier cosa que pueda estar sucediendo detrás de la pantalla que no se refleje en la interfaz de usuario o con una interacción Db. (Envío y correo electrónico. Enviando por FTP algo, lo que sea)

Pregunte por cualquier cosa que se ejecute en un horario. Mire todo el SQL detrás de los informes principales en el Sistema. Hacer un ERD.

Documento, Documento, Documento ... Luego, finalmente, una vez que tenga toda la información que pueda de esta manera. Comience a buscar en el código las áreas donde necesita aclaraciones.

    
respondido por el Morons 08.12.2011 - 17:03
2

Me gustaría basarme en lo que ChrisF y Morons ya han dicho.

De respuesta de ChrisF :

  

Si desea volver a escribir la aplicación, no necesita saber cómo   hace lo que hace pero usted necesita saber lo que hace.

Estoy de acuerdo al 100%.

De la respuesta de Morons :

  

Pregunte a los usuarios sobre la integración del sistema, básicamente cualquier cosa que pueda ser   sucediendo detrás de la pantalla que no se refleja en la interfaz de usuario o con una   Interacción db. (Envío y correo electrónico. Enviando por FTP algo, lo que sea)

     

Pregunte por cualquier cosa que se ejecute en un horario. Mira todo el SQL detrás   Los principales informes en el sistema.

De acuerdo. Gran punto sobre los trabajos programados.

  

Documento, Documento, Documento ... Finalmente, una vez que haya obtenido toda la información   Usted puede de esta manera. Comience a buscar en el código las áreas donde necesita   aclaración.

A la derecha.

  

Pruebe cada campo para la validación de datos.

OK.

  

Luego debes ir a través de todas las pantallas y casos de uso mientras ejecutas   un perfil de DB. Documentar todas las transacciones Db en cada pantalla.

No estoy de acuerdo.

  • Hacer un perfil exhaustivo de la base de datos no es un buen uso de su tiempo.
  • También podría ser engañoso.
  • Énfasis: como dijo ChrisF, concéntrese en lo que hace la aplicación, no en cómo lo hace.

También, sepa que: ¡Cometerá errores! :)

Por supuesto, como líder técnico, es su responsabilidad minimizar estos errores en la medida en que el nuevo sistema imite la funcionalidad principal del antiguo sistema.

Habiendo dicho eso ...

  • Parece que este será un esfuerzo valioso porque está haciendo que el sistema se pueda mantener y está eliminando una gran cantidad de deuda técnica.
  • Simplemente no creo que sea útil, productivo, eficiente o incluso fiscalmente responsable cargarte con una actitud demasiado perfeccionista en este trabajo.
respondido por el Jim G. 08.12.2011 - 17:31

Lea otras preguntas en las etiquetas