2010-03-06 4 views
6

Tengo un gran sitio web de PHP del cual me voy a ocupar ahora. Contiene cientos de archivos PHP separados, pero sospecho que solo se está utilizando realmente menos de la mitad. La mayoría de ellos probablemente se pueden eliminar.¿Cómo saber qué archivos PHP se usan realmente y cuáles no?

Pero lo último que realmente quiero hacer es revisar el código de cada archivo y verificar si está vinculado, incluido, requerido ... etc. a otros o si se puede eliminar de forma segura.

¿Sabes si hay alguna herramienta que sea capaz de hacer esto?

+0

Buena pregunta, tenga en cuenta que es posible que no capture todos los archivos. Porque puede incluir archivos dinámicamente y qué archivos están incluidos puede depender del estado de las variables. – Thirler

+0

No veo una razón por la cual esta pregunta se suspendió como fuera de tema, mientras que esta http://stackoverflow.com/questions/1811421/determining-which-php-source-files-are-not-used pregunta no estaba. Además, creo que la mayoría de las respuestas a continuación son útiles y marqué la que me sirvió mejor como respuesta. – NumberFour

+0

Pruebe también este: http://php.net/inclued –

Respuesta

8

Eche un vistazo a phpxref, Podría hacer lo que necesita.

Referencias cruzadas entre clases de PHP, funciones, variables, constantes y requiere/incluye el uso.

+3

Eso no manejará las invocaciones a través de ** eval **. Tampoco manejará grupos de archivos que se referencian entre sí, pero para los cuales no hay referencia desde el exterior. –

0

Existen varias formas de lograr esto, pero todas requerirán algún trabajo manual.

Probablemente pueda instalar y usar mejor un depurador (como Xdebug) que pueda mostrarle la ruta que recorre PHP al hacer clic en ellos.

Otra forma es escribir un script que coincida con 'incluir', 'include_once', 'require', 'require_once'. Es posible que también compruebe 'eval' y 'fopen', 'file_get_contents', etc. Asegúrate de probar/hacer una copia de seguridad.

+0

Y acabo de darme cuenta de que cualquier href = file.php también es una posible coincidencia. Por lo tanto, el enfoque de script/grep también debe tener eso en cuenta. – MattW

2

Tenga una mirada en phpdcd

phpdcd es un Detector de Código Muerto (DCD) para el código PHP. Escanea un proyecto de PHP para todas las funciones y métodos declarados y los informa como "código muerto" que no se invocan al menos una vez.

Pero no esperes nada de eso.

2

El problema con el análisis del código con una herramienta automatizada es que puede encontrar lotes de archivos que se vinculan entre sí, pero el lote de archivos nunca se utiliza. Por el contrario, puede haber un archivo al que se accede directamente, pero no usa otros archivos, ni está incluido en ningún otro archivo.

Normalmente, lo que hago, desesperado, es agregar el registro a cada archivo. Simple escriba __FILE__ en un archivo de registro cuando se accede al archivo. Esto agrega carga general en todos los ámbitos. Pero después de un cierto período de tiempo, entonces tiene su lista de archivos a los que realmente se accede y se utiliza.

También podría analizar el archivo de registro de forma regular y eliminar el registro de los archivos que sabe que se utilizan, reduciendo la sobrecarga a medida que avanza. Al final, puede buscar archivos que aún tengan su código de registro para ver cuáles no se han utilizado.

+0

La cobertura de prueba básicamente agrega todo este registro para usted. Automáticamente. Ver mi respuesta –

0

Puede usar __construct method y registrarlo si se usa. No puede establecer __construct method después de crear una instancia. Así que agrégalos manualmente;

class Someclass{ 
private $clsName; 
public function __construct(){ 
$this->clsName = get_class($this); 
YourStaticLogger::yourlogFunction("whatever you want to log" . $this->clsName); 
} 
//other things 
} 

Solo puede rastrear las clases llamadas. Eso es lo que yo haría.

+0

Esta es la misma respuesta que "agregar el registro a cada archivo". –

+0

bueno, pero no funcionará para clases abstractas y clases principales que se extienden por clases secundarias ya que la clase secundaria sobrescribirá el método __construct de la clase principal y solo habrá una ejecución __construct para cada instancia. – eyurdakul

1

Si utiliza una herramienta de cobertura de prueba, indicará cuáles se usan definitivamente, para cualquier funcionalidad del software que haya ejercido.(Obviamente, cuanto más se ejercite el software, más se ejecutará por la parte no muerta). Esto incluye cualquier archivo accesible a través de un enlace html externo; por supuesto, tiene que ejercer ese enlace, ya que es parte de la funcionalidad de su aplicación.

A continuación, puede inspeccionar los que dice que no se utilizan decidir qué es realmente el caso.

Nuestra SD PHP Test Coverage tool aceptará una lista de todos los archivos que desea verificar y le permitirá recopilar fácilmente dichos datos de cobertura de prueba. Proporciona un informe resumido que muestra qué archivos tienen cobertura; aquellos con 0% de cobertura son los que probablemente estén muertos.

+0

¿Cubre los scripts PHP que están incluidos? ¿Y los que se llaman a través de una acción AJAX? Considero que para encontrar el código muerto entre un script en particular, usar una herramienta como la que se utiliza en @Pekka o @gordon sería más apropiada. – Eldros

+0

@Eldros: no importa cómo se invoca el script (incluir, a través de AJAX). La instrumentación colocada en un archivo en la lista de proyectos, notará si se invoca el script, y también notará la * ausencia * de invocación del script. –

+0

@Eldros: Las llamadas herramientas de "análisis estático" para determinar la respuesta inspeccionando solo el código fuente probablemente no sean precisas. Uno puede ensamblar un nombre de método en tiempo de ejecución y usar eval para llamarlo; muy pocas técnicas de análisis estático (y mucho menos las de las herramientas específicas enumeradas por otros como respuestas) pueden determinar esto; para que puedan decirte que algo no se usa incluso si se ejecuta a menudo; pueden decirle que algo se usa incluso si nunca se ejecuta. Por el contrario, la herramienta de cobertura de prueba siempre te dirá correctamente si se usa * algo * como lo demuestra la ejecución. –

Cuestiones relacionadas