proyecto estructurar estructura directorios como aplicacion php profiling xdebug inclued

estructurar - Recopilación eficiente de información sobre el funcionamiento interno de un nuevo proyecto de PHP. ¿Herramientas? Técnicas? ¿Guiones?



estructura de directorios aplicacion web php (5)

Pronto me uniré a un proyecto de PHP que se ha desarrollado a lo largo de varios años. Va a ser enorme, escasamente documentado, muchos archivos, montones de código, no se espera un nivel de calidad consistente.

¿Cómo iría a reunir toda la información posible sobre lo que está sucediendo?

  • No se espera una carga automática, al menos no extensivamente, por lo que inclued podría hacer un buen trabajo al revelar las interdependencias.

  • Si phpDocumentor digiere los archivos del proyecto puede dar una idea de qué clases / métodos / funciones están presentes.

  • Tal vez phpCallGraph para phpCallGraph de método / función.

  • Perfilando algunos casos de uso genéricos con XDebug para obtener una idea acerca de las jerarquías y los conceptos.

  • Inspeccionar archivos de registro importantes ... verificando advertencias, usos obsoletos, errores.

  • phpinfo() .

  • Tal vez extraer todos los comentarios y procesarlos en un archivo html.

No cubre unidades de pruebas, bases de datos, ...

¿Qué harías? ¿Cuáles son sus experiencias con las herramientas mencionadas para aprovecharlas al máximo?

Puede asumir cualquier condición necesaria.

¿Qué información estadística podría ser útil extraer?

¿Alguien ha experimentado con esas herramientas?

EDITAR desde "Herramientas PHP para control de calidad" :

Edición 2 de la respuesta de Bryan Waters:

Configuración de un ciclo de implementación / construcción / CI para proyectos PHP - sugerido por Pekka

EDITAR 3

Acabo de encontrar este PDF de una charla de Gabriele Santini - "Análisis estadístico del código - Escuche su código PHP". Esto es como una mina de oro.

Estoy de acuerdo en que su pregunta tiene la mayoría de las respuestas.

Esto es lo que probablemente haría. Probablemente comenzaría con las herramientas de Sebastian Bergman, especialmente phploc, para que puedas tener una idea del alcance del desastre (base de código) que estás viendo. Le da clases, conteos de funciones, etc., no solo líneas de código.

A continuación, buscaría en los registros de Apache o Google Analytics y obtendría los 10 URL de PHP más solicitados. Configuré XDebug con perfiles y ejecuté esas 10 solicitudes principales y obtuve los archivos, llame al árbol. (Puedes verlos con una herramienta de cacheginder)

Finalmente, leí toda la ruta de ejecución de una o dos de esas trazas, que es la más representativa de la totalidad. Usaría mi IDE de Eclipse, pero imprimirlas e ir a la ciudad con un resaltador también es válido.

El método de los 10 principales podría fallarle si hay varios sistemas improvisados. Debería ver rápidamente con Xdebug si los 10 primeros están codificados de manera similar si cada uno es una isla única.

Miraría las bases de datos mysql y trataría de entender para qué sirven todas ellas, especialmente mirando los prefijos de tablas, puede que tenga un par de aplicaciones diferentes apiladas una encima de la otra. Si hay partes grandes de la base de datos que no están en el top 10, debes ir a buscar las subapps. Si encuentra otras aplicaciones secundarias, ejecútelas en el perfilador xdebug y luego lea una de las rutas representativas de esa aplicación secundaria.

Ahora regrese y mire los números de alcance de phploc y vea qué porcentaje de la base de código (probablemente cuente las clases o funciones) no se tocó durante su revisión.

Debe tener un conocimiento básico del código de ejecución más frecuente y una idea de cuántos rincones, grietas y armarios para el almacenamiento de esqueletos existen.

Habiendo construido y soportado grandes proyectos de PHP heredados de spaghetti-y, creo que hay tantas cosas que podrá hacer usando herramientas de análisis. La mayoría de ellos simplemente le dirá que el proyecto es de una calidad terrible :)

Las pruebas de unidades y las herramientas de documentación del código fuente generalmente necesitan una contribución activa dentro del código para producir resultados utilizables. Dicho esto, todos valen la pena probarlos, no estoy familiarizado con las herramientas de phpCallGraph y Sebastian Bergmann. Además, phpDocumentor puede dar sentido a al menos partes del código. PHPXref también es una herramienta genial para obtener una visión general, here''s una demostración (lenta).

La mejor manera de comenzar podría ser simplemente tomando una tarea simple que debe hacerse en el código base, y abrirse camino a través de la jungla, siga las instrucciones incluidas, trate de comprender la estructura de la biblioteca, etc., hasta que el trabajo esté terminado. Si te unes a un equipo, quizás tengas a alguien cerca para que puedas pedir ayuda.

Me concentraría en hacer que el proceso de exploración sea lo más conveniente posible. Algunos puntos (triviales) incluyen:

  • Use un IDE que pueda llevarlo rápidamente a las definiciones de funciones / métodos, clases y variables

  • Tener un depurador en ejecución

  • Absolutamente mantenga todo bajo control de la fuente y cometa cada cambio.

  • Tenga un entorno que le permita implementar fácilmente un cambio para la prueba, y tan fácilmente cambiar a una rama diferente o revertir todo por completo. Aquí hay una pregunta relacionada sobre cómo configurar algo así: configurar un ciclo de implementación / creación / CI para proyectos PHP

Quizás pueda configurar un entorno de integración continua. En este entorno puede reunir todas las estadísticas que desee.

Jenkins es un buen servidor de CI con muchos complementos y documentación.

Si le interesan las estadísticas, eche un vistazo al índice CRAP (Análisis y predicciones del riesgo de cambio), que mide la calidad del código.

Hay un buen artículo introductorio de dos partes:

Primera parte
Segunda parte