A un nivel alto:
- Utilice el análisis estático (o posiblemente en tiempo de ejecución) para crear una lista de cada función y método en su base de código.
- Recolecte un montón de muestras de producción usando XHProf. Úselos para construir una lista de cada función y método llamado .
- Cualquier cosa en la lista 1 pero no en la lista 2 podría eliminarse con seguridad.
Para (1), puede usar grep si es necesario, o algo más sofisticado. Hay algunos scripts similares en Phabricator (mira arc liberate , que enumera todas las funciones y clases en una biblioteca), pero puede haber mucho más código del que deseas tratar. Si tiene alguna forma de cargar todo su código, puede volcar esta lista en tiempo de ejecución usando Reflection, llamando a get_declared_classes() y get_defined_functions() y luego reflejando los nombres de los métodos. Si bien es inusual cargar todo, no debería ser demasiado difícil si no tiene efectos secundarios al incluir.
Para (2), probablemente no pueda usar XHGUI o XHProf directamente para volcar una lista agregada de funciones / métodos llamados, pero el formato de datos subyacente que XHProf usa para sus volcados es bastante sencillo y no debería ser demasiado difícil escribir esto codifícate Puede ver XHProf, XHGUI o Phabricator para ver ejemplos: vea el uso de xhprof_compute_flat_info() aquí para casi todo lo que necesita:
- ¿Cuál es el significado de Travel CRS en el software del sistema de reservas?
- ¿Cuándo usan los desarrolladores JavaScript y por qué?
- ¿Cuáles son algunas ideas de proyectos interesantes para el desarrollo web MVC?
- ¿Qué pasó con Omnisio después de su adquisición por parte de Google?
- ¿Cuál es una buena aplicación para iPhone para rastrear el tiempo dedicado a varias aplicaciones en dispositivos móviles?
https://github.com/facebook/phab…
Para (3), esta es la parte realmente complicada. No es seguro eliminar automáticamente todo este código. Por ejemplo, si recopiló muestras de producción, las funciones utilizadas en el desarrollo / depuración probablemente nunca se llamaron. Si tiene funciones o métodos que manejan errores raros pero ninguno de ellos ocurrió mientras estaba muestreando, sería inseguro eliminarlos. Si trata la lista 2 como una lista blanca (“todo lo que no esté en esta lista se puede eliminar”) es probable que elimine un montón de código que necesita. En cambio, debe tratarlo como una lista negra (“cualquier cosa en esta lista definitivamente no se puede eliminar”).
Puede aumentar su nivel de confianza realizando también análisis estáticos para buscar sitios de llamadas. Esto te dará una segunda lista negra. Si cree que alguna función f(...) nunca se llama pero hay un montón de sitios de llamadas f(...) en la fuente, ciertamente no es seguro eliminarla (podría ser seguro si todos esos sitios de llamadas también están muertos , pero es mejor dejar que el análisis te diga que posiblemente están muertos, eliminarlos y luego dejar que el análisis te diga que f(...) ahora está posiblemente muerto). Como se indicó anteriormente, puede hacer esto de manera cruda con grep y regexps, o menos crudamente con una herramienta más sofisticada. Sin embargo, como se call_user_func() anteriormente, esto no se puede tratar como una lista blanca porque PHP es dinámico y las invocaciones a través de call_user_func() , etc., no se mostrarán.
A menos que sea extremadamente disciplinado sobre el uso de llamadas dinámicas, nunca podrá producir de manera segura una herramienta que elimine automáticamente el código, pero sí puede generar una lista de código “no conocido como vivo” / “probablemente muerto”. puede entregar a un humano para su revisión y eliminación Con las llamadas en vivo muestreadas y las llamadas en vivo estáticas eliminadas, la lista probablemente será bastante buena.
O simplemente puede eliminar automáticamente todo lo que está en la lista maestra que no está en ninguna de las listas negras y ver qué sucede. Mi dinero está en un “desastre terrible”, pero tal vez sería “recuperar algunas funciones raras de depuración / error y luego todo funciona muy bien”.
