remove - Heredado una pesadilla de PHP, ¿por dónde empezar?

strip_tags wordpress

Question

Heredé un proyecto PHP que se está convirtiendo en una pesadilla. Estos son los puntos destacados:

1. Todos los desarrolladores originales han dejado
2. El código no tiene control de versión
3. Todo el desarrollo y las pruebas se realizaron en el servidor en vivo al cambiar el nombre y editar los archivos PHP. Hay varias copias de cada archivo index.php, index2.php, index3.php, etc. y no está claro qué archivos se están utilizando realmente.
4. Hay múltiples inclusiones en cada archivo a archivos que incluyen otros archivos que incluyen otros archivos, etc.
5. Ha habido múltiples desarrolladores en el proyecto que cada uno tenía su propia forma de hacer las cosas. Por ejemplo, hay una mezcolanza de marcos de JavaScript, algunas consultas de bases de datos usan SQL, otros una interfaz XML y otros llaman funciones de procedimiento en la base de datos.

Debido a todos estos problemas, el desarrollo es frustrantemente lento. Además de expresar mis frustraciones a Stack Overflow, ¿alguna recomendación sobre cómo comenzar con este desastre? Soy bastante nuevo en el desarrollo de PHP, pero parece que configurar un tipo de entorno de desarrollo para que los cambios puedan probarse sin romper el servidor en vivo es el primer paso. ¿Algún consejo sobre cómo comenzar aquí? ¿Cuál es una forma típica de hacer pruebas? Configurar una versión local del sitio en mi escritorio parece mucho trabajo (el servidor es Linux, pero los escritorios aquí son Windows). ¿Puedo crear un subdirectorio en el servidor en vivo para realizar pruebas o ...? ¿Qué hay de la base de datos?

En segundo lugar, ¿hay algún tipo de perfil que pueda habilitar para rastrear qué archivos en el servidor se están utilizando realmente? Me gustaría eliminar las copias renombradas de cosas que realmente no están siendo incluidas. Mejor aún, ¿hay alguna forma de saber qué partes de un archivo no se están ejecutando? Hay muchas funciones copiadas y basura que sospecho que tampoco se están utilizando. Del mismo modo, para el incluye, ¿algún consejo para enderezar el desastre?

Bueno, dejaré de desahogarme aquí y me arrojaré a merced de todos aquí. :)

Answer 1

1. Antes que nada, obtenga los archivos en control de versiones como están. No pase el número 1 hasta que esté listo.
2. Establezca un entorno de prueba.
3. Limpia los archivos

Answer 2

1. Configure un servidor de desarrollo (como lo mencionó Greg Hewgill, VirtualBox y Virtual PC son buenas opciones para esto).

2. Coloque los archivos de sitio actuales (incluido el servidor web relevante y las configuraciones de PHP) en control de versiones.

3. Averigüe qué archivos están siendo utilizados: use la configuración de su servidor de desarrollo para probar eliminando todos los archivos fooN.php y vea si todavía funciona.

4. Ora ... muchas (OK, esto no es obligatorio, pero parece que lo necesitarás).

Answer 3

Aquí hay algunas ideas:

• PHP y Apache también funcionan bien en Windows. ¿Quizás puedas hacer una instalación totalmente Windows después de todo?
• Pruebe grep ''ing (o alguna alternativa de Windows) para "incluir" y "requerir" en todos los archivos PHP. Luego haga una lista de todos los archivos incluidos encontrados. Compare la lista con los archivos en la carpeta. Debería poder deshacerse de al menos ALGUNOS archivos sin referencia.
• También puede hacer una lista de todos los nombres de archivo y buscar todos los archivos para ellos. Podrías hacer algo como un gráfico de dependencia como este.

Answer 4

Creo que todos los 5 de tus puntos coinciden con algunos proyectos clásicos de ASP que he heredado, y uno de PHP también ...

Estoy totalmente de acuerdo con los demás en obtenerlo en control de fuente lo antes posible y usar VMWare, VirtualBox, etc. para un entorno de prueba.

Asegúrese de obtener también su versión de base de datos, especialmente si los procedimientos tienen lógica adicional en ellos (no solo inserte, actualice, elimine directamente). El control de versiones de DB toma más atención que las páginas php. Debe generar todos los objetos en scripts sql y poner esos scripts en control de fuente. Luego, al cambiar la estructura de db, los procedimientos, etc., debe actualizar los scripts para que también tenga un historial de esos cambios.

En cuanto a averiguar qué está usando qué en el lado de la base de datos sugeriría mirar ApexSQL Clean . Lo usé en un proyecto con varios cientos de archivos ASP, más de 200 tablas y aproximadamente 400 procedimientos almacenados. Pude identificar 20 o más tablas que no estaban en uso y aproximadamente el 25% de los procedimientos almacenados. Con ApexSQL Clean puede agregar todos sus archivos php en la verificación de dependencia junto con las tablas, vistas y procesos almacenados. Tome la versión de prueba de 30 días y compruébelo, le ahorrará mucho tiempo.

Para qué archivos estaban en uso para el sitio web, tenía los registros del servidor web del mes anterior y ejecuté búsquedas en su contra por algo que no estaba seguro. También me gusta una variación de lo que Aistina sugirió al modificar los archivos para que se registren cuando se acceda a ellos. Tal vez tenga que ir a una tabla en la base de datos que configuró, que es el nombre de archivo y el recuento de acceso, y cada vez que se carga ese archivo, aumenta el recuento. Luego, después de un período de tiempo, puede revisar los recuentos y determinar qué puede suceder.

Answer 5

Definitivamente necesita un entorno de desarrollo. Si no quiere meterse con la ejecución del sitio en su cuadro de Windows, podría tomar una imagen de VMWare de alguna distribución de Linux.

Answer 6

El primer paso, por supuesto, sería ponerlo bajo control de versión. De esta forma, al menos puedes volver a la versión original de trabajo. En segundo lugar, puede ser una buena idea sobrescribir las funciones include, require, etc para, por ejemplo, escribir el nombre del archivo que se está incluyendo en algún archivo de registro, de esta forma se puede averiguar qué archivos se están incluyendo (con suerte descartar una gran cantidad de index2.php, index3.php, etc.

Para averiguar, si es necesario, si se usan algunas clases y otras no, puede usar get_declared_classes en conjunción con get_defined_vars y gettype para ver qué tipos se están instanciando.

En cuanto a los números 4 y 5, probablemente sean un poco más difíciles de resolver, pero esto debería comenzar con optimismo.

Answer 7

Esto de hecho es un desastre. Pero comienza a ser creativo sobre dónde cortar algunos de los tentáculos de esta cosa:

1. Obtenga el control de la versión. Recomiendo a Git.
2. Configure un servidor de desarrollo local. Encuentre un paquete WAMP, LAMP o MAMP para comenzar desde que es nuevo en esto.
3. Encuentra los puntos de entrada (index.php, etc.). Verifique los registros de acceso de su servidor para ver cuáles son.
4. Remangue sus mangas con magia de expresión regular y descargue un árbol de incluir / requerir en todos los archivos. Pero tenga cuidado con cualquier include ($ filename) dynamic includes. Si tiene alguno de estos, tendrá que iniciar sesión en $ filename para averiguar qué es lo que posiblemente se incluye, aunque el código que lo rodea debería darle pistas. Con un poco de suerte, puedes eliminar todos tus archivos no utilizados de esta manera.
5. Use más magia negra regex para verificar las funciones y los métodos están siendo referenciados en otro lugar en la base de código. Puede haber un IDE que pueda ayudarlo con esto. Pruebe NetBeans (lo usé para ayudarme a refactorizar un proyecto de C ++ una vez, por lo que puede ser útil aquí).
6. Como alguien más respondió, "averigüe, si es necesario, si se usan algunas clases y otras no, puede usar get_declared_classes junto con get_defined_vars y gettype para ver qué tipos están siendo instanciados". También puede escribir un código para encontrar todas las declaraciones nuevas en la base de códigos.
7. Y así sucesivamente ... solo piensa en cómo puedes debilitar a este monstruo. Y trate de reorganizar el código donde pueda.

Answer 8

Haz lo que dijo Harper Shelby ...

Pero, también agregaría que si no recibe ayuda de la administración para limpiar esto, puede aceptar el hecho de que esto puede ser así por algún motivo. ... Sólo digo. ;-)

Answer 9

He hecho esto Tienes mi simpatía. Si su pasaporte no está actualizado o por alguna otra razón no puede evitarlo, así es cómo lo abordaría:

Step Zero es ponerlo en control de versiones, sin importar cuán malo sea. Si incluso funciona, y usted rompe algo, necesita poder volver al estado de trabajo, o al menos comparar sus cambios para descubrir qué salió mal. Haga check-ins frecuentes y pequeños a medida que realiza la refactorización, y tendrá menos código para revertir cuando las cosas fallan misteriosamente. (Las cosas IRÁN misteriosamente mal)

Después de eso, comenzaría en la base de datos. Asegúrese de que todo esté relativamente bien normalizado, las columnas estén claramente identificadas, etc.

Haga el código PHP a continuación. Si el código es realmente un mosaico, seguiría adelante y lo ajustaría a un marco. Mire en CakePHP o Symfony : su manera Rails-ish de separar preocupaciones hace que la pregunta "¿a dónde debe ir este fragmento de código?" fácil de responder No es una tarea pequeña, pero una vez que lo haya hecho, probablemente sea mejor que la mitad de tener una aplicación de construcción sensata. Además, las instalaciones de prueba integradas de un buen marco web hacen que la refacturación sea mucho más fácil: escriba una prueba para cubrir una funcionalidad existente antes de cambiarla, y sabrá si rompió algo después del cambio.

Una vez que haya ordenado su base de datos y tenga el código modelo en los modelos y el código del controlador en los controladores, entonces puede preocuparse por cosas a nivel de presentación como estandarizar en una sola biblioteca JS / AJAX, limpiar CSS, etc.

En cuanto a un entorno de desarrollo: debe configurar absolutamente un entorno de desarrollo local. Hay paquetes WAMP listos para usar, o puede instalarlos en una máquina / máquina virtual de Linux (recomiendo VirtualBox para la virtualización). También debe tener un entorno de prueba de integración separado que imita el servidor en vivo. Nada más que código en vivo debería ejecutarse en el servidor en vivo.

En cuanto a las herramientas de depuración / creación de perfiles, sé que Symfony viene con un conjunto de herramientas bastante sofisticado, incluida una pequeña barra de herramientas JS que aparece en sus páginas (solo en modo de depuración) con información de registro y perfil.

Buena suerte.

Answer 10

Intente obtener estadísticas detalladas en el sitio y descubra dónde están los puntos de entrada y salida. Una forma decente de averiguar qué archivos se están golpeando desde la parte superior (y luego buscar en esos archivos para ver qué elementos se están extrayendo).

Answer 11

La mayoría de las veces puede saber si un archivo se está utilizando con grep.

grep -r "index2.php" *

También puede usar el analizador de PHP para ayudarlo con la limpieza. Aquí hay un script de ejemplo que imprime las funciones que se declaran y las llamadas a funciones:

#!/usr/bin/php
<?php
class Token {
public $type;
public $contents;
public function __construct($rawToken) {
if (is_array($rawToken)) {
$this->type = $rawToken[0];
$this->contents = $rawToken[1];
} else {
$this->type = -1;
$this->contents = $rawToken;
}
}
}
$file = $argv[1];
$code = file_get_contents($file);
$rawTokens = token_get_all($code);
$tokens = array();
foreach ($rawTokens as $rawToken) {
$tokens[] = new Token($rawToken);
}
function skipWhitespace(&$tokens, &$i) {
global $lineNo;
$i++;
$token = $tokens[$i];
while ($token->type == T_WHITESPACE) {
$lineNo += substr($token->contents, "/n");
$i++;
$token = $tokens[$i];
}
}
function nextToken(&$j) {
global $tokens, $i;
$j = $i;
do {
$j++;
$token = $tokens[$j];
} while ($token->type == T_WHITESPACE);
return $token;
}
for ($i = 0, $n = count($tokens); $i < $n; $i++) {
$token = $tokens[$i];
if ($token->type == T_FUNCTION) {
skipWhitespace($tokens, $i);
$functionName = $tokens[$i]->contents;
echo ''Function: '' . $functionName . "/n";
} elseif ($token->type == T_STRING) {
skipWhitespace($tokens, $i);
$nextToken = $tokens[$i];
if ($nextToken->contents == ''('') {
echo ''Call: '' . $token->contents . "/n";
}
}
}

Answer 12

Lo primero que haría sería configurar un entorno de prueba utilizando una máquina virtual de algún tipo. VirtualBox o Virtual PC serían buenas opciones. De esa manera, puede comenzar a cambiar las cosas sin temor a romper el entorno de producción. No importa cuánto trabajo esto parezca (con la base de datos y el servidor web y todo), al final valdrá la pena. Uno de los grandes beneficios es que puede copiar la máquina virtual y dársela a otra persona, si encuentra que necesita ayuda.

Answer 13

Me gustaría:

1. Siéntate y respira profundo;
2. Decide si realmente es donde quieres trabajar;
3. Suponiendo que sí, entonces enrollaré mis hojas, elegiré un desastre para trabajar a la vez y me pondré a trabajar.

Sé que no podemos limitarnos a una sola tarea a la vez; sin embargo, puede limitar su trabajo a resolver un desastre a la vez mientras trabaja en las tareas diarias que se realizan.

Answer 14

Si es el peor de los casos, el código está fragmentado, y toda la pantalla se entremezcla con la lógica y las llamadas a la base de datos, puede hacer lo que tengo que hacer con un proyecto PHP.

Le di tres pasos para probar el enfoque de refactorización. Era como escalar una colina en una motocicleta y obtener el 10% del camino cada vez. Así que tomé otro enfoque que terminó funcionando mucho mejor.

1. Inicié sesión como usuario,
2. y trabajé en cada pantalla y cada caso de uso que pude encontrar.
3. Guardé el html en archivos estáticos
4. y tomó notas sobre la operación de procedimiento y las reglas comerciales obvias.

Hice esto por 3 días seguidos, y luego tomé mis notas y mantuve una larga conversación con las partes interesadas.

Después de obtener un acuerdo sobre algunos primeros pasos, reimplementé toda la interfaz de usuario html correctamente, usando un buen diseño y abstracción consistentes. Después de rodar, podría hacer un par de pantallas al día.

Luego devolví el resultado a los interesados ​​y revisé varios casos de uso. (Las partes interesadas se sintieron inmensamente complacidas con los pasos 1 y 2, porque no les gustó la primera implementación de todos modos (sorpresa) y ahora parecía que había una esperanza de mejora, no solo la recuperación de una aplicación vieja y sensata.

Eso resultó ser el final del arduo trabajo (y también el final del riesgo percibido del proyecto para las partes interesadas).

Resultó que la primera tripulación se había atado tanto en sus propios espaguetis mal concebidos que en realidad había relativamente poco contenido para el trabajo, así que duplicarlo tenía menos alcance del que todos sospechaban.

Pero la decisión clave fue que el código original, tanto el contenido como la estructura, eran irrecuperables y que necesitaba trabajar desde una perspectiva totalmente exterior con un nuevo marco diseñado correctamente.

Answer 15

Muchos mensajes útiles sobre cómo lidiar con esto.

Sin intentar repetir lo que todos han dicho:

1. Obtenga una copia del entorno de producción en funcionamiento. Puede ser una máquina virtual u otra máquina real. Pero debes ser Dios en eso. Si la base de datos prod está en otra caja, también necesitará una versión dev.
2. Ponlo todo en control de versiones. En otra caja. Uno que está respaldado al menos semanalmente.
3. Asegúrese de saber cómo funciona la bifurcación en su aplicación de control de versiones. Probablemente lo necesites.
4. Haga que el servidor de prod bloqueado. No quiere que se realicen más cambios que no salgan del control de la versión.
5. Cree instrucciones para liberar el código del control de versión al servidor de prod. La unidad más pequeña de cambio liberable debe ser toda la base de código.

Los próximos pasos dependen de qué tan unidos estén los usuarios. Si no puede cambiarse demasiado por el motivo que sea, necesitará un enfoque progresivo. Si el desarrollo y mantenimiento aún tienen que suceder, entonces esta es probablemente su única opción. Recuerde utilizar esa función de bifurcación para separar tales modificaciones de sus esfuerzos de reescritura.

Para darle sentido a la estructura, básicamente debes crear una nueva estructura junto con lo que hay allí. Un nuevo controlador de bases de datos suele ser un buen lugar para comenzar, incluido a partir de un archivo de inclusión genérico que cada página debe cargar. El objetivo aquí es crear una estructura de inclusión mínima que se pueda expandir más adelante sin indicarle a cada página que cargue archivos adicionales.

Ahora debe comenzar a transferir la funcionalidad a sus nuevos archivos incluidos. Necesitará una forma de tener varios archivos abiertos a la vez, como un editor de múltiples archivos, o una pantalla + vi (o emacs). Comience con funciones de utilidad y bloques de código que se repiten en varios lugares. Trata de no distraerte para arreglar mucho a la vez. Algunos tipos de problemas van a tener que moverse solo a medida que otros problemas se arreglan. Regresarás a ellos más tarde.

No sienta que necesita agregar un marco de terceros. Agregar tal cosa rápidamente lleva a una reescritura completa. En este punto, esto será mucho más trabajo que simplemente domesticar su estructura de inclusión. Así que soluciona eso primero.

A medida que transfiere la funcionalidad, necesitará que los archivos usen su nuevo archivo de inclusión. Los primeros archivos que haga esto por usted perseguirán conflictos por un tiempo. Se sentirá desalentador e inútil, pero esta es probablemente la parte más difícil. Después de algunos archivos, será más fácil. Habrá momentos en los que podrá migrar media docena de páginas a los nuevos archivos de inclusión reemplazando una docena de inclusiones con solo una. La otra cara de la acción es que habrá archivos que puedes borrar.

Si te apegas a eso, eventualmente llegarás al punto donde todos los archivos de inclusión son los que has escrito y estarás en todo el diseño de inclusión. En ese punto, será significativamente más fácil hacer cambios mucho más invasivos, como poner un marco de terceros.

Answer 16

Además de las cosas geniales que otras personas han dicho, para obtener una primera pasada sobre qué archivos están siendo utilizados activamente, puede instalar un caché de código de operación como APC o eaccelerator en su servidor de desarrollo (o incluso un servidor de producción, esto no se romperá) cualquier cosa). Luego, haga clic en la aplicación web en su servidor de desarrollo (o deje que los usuarios lo hagan en su servidor de producción).

Ahora mira la lista de archivos en caché en tu página de administración de caché. Si un archivo no aparece en la lista como caché de su caché de código de operación, es muy probable que no lo cargue.

Esta no es una solución completa, pero si cada directorio tiene 10 archivos index.php (por ejemplo, index.php, index2.php, etc.), al menos sabrá cuál está siendo utilizado por su aplicación.

Answer 17

Acabo de pasar por esto yo mismo.

Mi consejo número uno es no intentar y cambiar todo el día uno. Necesitas amigos si realmente quieres arreglar esto. Necesita respeto de sus colegas antes de sugerir cómo cambiar todo en lo que han estado trabajando durante meses (¿años?).

Primero, obtenga el código bajo control de versión tan pronto como sea posible. Si eso no va a ser fácil para usted, al menos comience a realizar copias de seguridad diarias, incluso si eso significa simplemente descomprimir los archivos y nombrar el archivo zip con la fecha. Si nadie conoce el control de versiones, compre un libro de programador pragmático en CVS o SVN y configúrelo usted mismo. Los libros se pueden leer en un día y puede comenzar a funcionar rápidamente. Si nadie más quiere usar el control de versiones, puede usarlo usted mismo ... luego, cuando alguien pierde un archivo, puede guardar el día con una copia de su repositorio. Tarde o temprano, los demás verán la sabiduría que es el control de versiones.

Segundo, sumergete en el código lo más fuerte que puedas. Vívelo y respíralo por un mes. Muestra a las personas que están allí que vas a aprender su código.

En tercer lugar, mientras revisas el código, toma notas copiosas. Escriba todo lo que le molesta sobre el código. Solo consigue tus pensamientos en papel. Puede organizarlo más tarde, después del primer mes.

En cuarto lugar, instale un generador de perfiles de código (como xdebug). Eso te dirá qué archivos y funciones se están llamando en cada página, y cuánto tarda cada fragmento de código en ejecutarse. Puede usar esto para descubrir sus problemas de inclusión y encontrar bits lentos de código. Optimiza esos primero.

Después de un mes de arduo trabajo, revisando el código y tomando notas, conviértalo en un documento adecuado. Las diferentes secciones pueden abarcar desde la seguridad hasta el almacenamiento en caché, la arquitectura o cualquier otra cosa que lo moleste. Por cada crítica que haga, ofrezca una mejor solución y una estimación del tiempo que llevaría arreglarla. Aquí es donde te deshaces de todos los frameworks javascript competidores, etc.

Revise este documento tanto como sea posible. No puedo enfatizar eso lo suficiente.

Asegúrese de que su audiencia pueda decir que lo está haciendo por el bien de la compañía, no solo por sus preferencias personales.

Preséntelo a su jefe, en persona. Establezca un tiempo para discutirlo.

Podrían despedirte por haberlo escrito. Si lo hacen, estarás mejor sin ellos, porque no quieren mejorar y tu carrera se estancará.

Es posible que quieran implementar todas sus recomendaciones. No es probable, pero es posible. Entonces estarías feliz (a menos que tus recomendaciones fallen).

Lo más probable es que deseen implementar algunas de sus recomendaciones, y eso es mejor que nada. Por lo menos, ayudará a aliviar sus preocupaciones.

En cuanto a las pruebas, configure otro "host virtual" en Apache (compatible con Windows y Linux). Los hosts virtuales le permiten ejecutar múltiples sitios en un solo servidor. La mayoría de los sitios más grandes tienen al menos 3 hosts virtuales (o servidores reales): dev.domain.com (para el desarrollo diario), staging.domain.com (para que las personas de QA realicen las pruebas justo antes de una versión) y www.domain. com (su servidor de producción). También debe configurar las versiones de desarrollo, distribución y producción de la base de datos, con diferentes inicios de sesión y contraseñas para que no las confunda accidentalmente.

Una solución alternativa sería dar a cada desarrollador su propio host virtual en el servidor Linux, y pueden trabajar a través de FTP / SCP o compartir la red usando samba.

¡Buena suerte!

Answer 18

Puede ver una lista de todos los archivos incluidos / requeridos poniendo esto cerca de la parte inferior de la página:

<?php var_dump(get_included_files()); ?>

Answer 19

Sí, Version Control es definitivamente el paso # 0.

También recomendaría una buena herramienta de búsqueda de código .

El agente Ransack es bastante bueno (suponiendo que estés en Windows) http://www.mythicsoft.com/agentransack/Page.aspx?page=download

Estaría volando a ciegas sin la búsqueda de código.

Answer 20

1. Ponlo bajo control de revisión.

2. Decidir sobre convenciones de nombres y estructura de archivos / directorios.

3. Asegúrate de tener herramientas decentes / IDE.

4. Configure un entorno de desarrollo / prueba por separado si aún no lo ha hecho

ENTONCES ...

5. Lamentablemente, deberá examinar todos los archivos 1, 2 y 3 y determinar cuáles están en uso y cuáles pueden eliminarse. No hay otra manera además de una fuerza bruta que se mueva, archivo por archivo.

6. Aunque tengo un RCS en su lugar, a menudo muevo lo que creo que son guiones no utilizados a un lugar oculto, digamos .mausoleum y luego hago que el RCS ignore esa ubicación. Es bueno poder echar un vistazo localmente sin volver al repositorio.

7. Separar HTML y PHP en la mayor medida posible . ¡No puedo enfatizar esto lo suficiente! Si esto se hace en cada archivo, bien. Siempre que tenga trozos separados de PHP y HTML. Por supuesto, HTML estará salpicado de echos aquí y allá, pero trate de tener todas las pruebas, los interruptores, todo lo demás movido fuera del bloque HTML y dentro del bloque PHP. Esto solo puede ser GRANDE cuando se trata de resolver las cosas.

8. Si el código es principalmente de procedimiento, supongo que en su caso lo es, probablemente sea mejor hacer una limpieza primero, antes de hacer una refactorización seria o refactorizar en clases.

9. A medida que encuentre archivos / scripts que lógicamente se pueden combinar, hágalo. (He visto proyectos, probablemente no muy diferentes al suyo, donde la cantidad total de archivos supervivientes es aproximadamente 1/4 de lo que comenzamos).

Una vez que haya llegado tan lejos, podrá comenzar una refactorización o refactorización adecuada en las clases.

¡Bonne chance!

Answer 21

Bueno, primero lo primero. He estado en la situación en la que estás, y apesta. Creo que estás en el camino correcto con el deseo de poner en marcha un entorno de desarrollo.

Entorno de desarrollo

Esto incluirá un servidor web / motor de script / pila de motor de base de datos, y un IDE más probable.

Para un instalador de pila LAMP , recomiendo usar uno de estos:

• http://www.apachefriends.org/en/xampp-windows.html
• http://www.easyphp.org/
• http://www.nucleex.com/nucserv/

Lectura adicional en la pila LAMP:

El sitio OnLamp de O''Reilly

Para un buen IDE de PHP , recomiendo usar uno de estos:

• Zend Studio
• ActiveState Komodo
• Jetbrains PhpStorm

Artículo sobre el sitio para desarrolladores de IBM que compara varios IDE

Para el control de Fuente , puede usar Team Foundation Server, SVN o Git; solo use algo que sepa. Yo recomendaría tener todo en control de fuente primero (para cualquier mantenimiento de emergencia que pueda tener), pero luego planeo hacer una revisión bastante grande.

La revisión

Mencionaste que ni siquiera sabías qué archivos se estaban utilizando y que usaban una convención de nomenclatura de archivos como pseudo-control de versiones. Es posible que desee comenzar la revisión allí, una vez que tenga un entorno de desarrollo en funcionamiento. Hay algunas cosas que pueden ayudarte:

• Su aplicación clientes / usuarios
• Toma de notas meticulosas y organizadas
• Un buen marco de trabajo

Tus clientes / usuarios son importantes , porque parece que eres nuevo en el proyecto y sabrá cómo debería comportarse la aplicación mejor que tú (lo más probable).

La toma meticulosa de notas es importante , ya que esencialmente se volverá a escribir cualquier requisito / diseño / documentación del usuario final desde cero. Necesitas entender las partes internas si vas a hacer eso. Y si va a entender algo sobre este sistema, tendrá que escribirlo usted mismo (o estaría examinando la documentación prefabricada en este momento en lugar de leer ) ;-)

Y, por último, un marco de trabajo de registro es importante porque necesita arreglar cosas, y no puede arreglar cosas que no sabe que están rotas. Un marco de trabajo le proporciona visibilidad de partes de la aplicación que no tienen una interfaz de usuario obvia. Insertarlo en varias partes de la aplicación y luego mirar los registros le da una buena idea de cuándo se está ejecutando el código y en qué orden.

Querrá enfocarse en capturar (en papel) cómo debería funcionar la aplicación, y luego eliminar lentamente archivos innecesarios mientras intenta no romper nada. Esté atento a los registros para ayudar con la depuración. Asegúrese de que sus clientes no estén gritando que algo no funciona. Asegúrese de que sus notas estén de acuerdo con lo que se registra y lo que dicen sus clientes.

Previniendo esto en el futuro

Vuelva a verificar todo en control de fuente . Con suerte, habrá llegado a una estructura de directorios mejor, nueva y mejor en este punto.

Obtenga una estructura de prueba en su lugar . Aunque esto solo signifique implementar un marco básico de pruebas unitarias y realizar algunas pruebas básicas de detección de humo después de cada implementación, es mejor que nada. Idealmente, debe tener un ingeniero de pruebas o un cliente conocedor y confiable que pueda pasar el tiempo probando después de cada implementación.

Ponga en marcha un proceso de implementación si desarrolla más de un desarrollador. Controlar el cambio a su entorno de producción debe ser su primera prioridad. (Lo último que desearía hacer es volver a pasar por esto, ¿no?). Debe tener un proceso claro y simple para moverse entre los límites del entorno (como Dev -> Prueba y Prueba -> Producción).

Answer 22

1. comience a usar el control de versiones en el proyecto (recomiendo git)
2. escribir pruebas unitarias para todo el código
3. empiece a usar ORM (recomiendo fuertemente la doctrina)
4. empiece a usar framework (recomiendo Symfony / nette)
5. comience a refactorizar el código php

Answer 23

1. Haga una copia de seguridad del código ahora.

2. Control de versiones.

3. Crea un sitio de prueba ¿El sitio se ejecuta bajo Apache? Incluso puede instalar Apache + PHP + MySQL en su propia computadora, y usar eso para probar.

4. Tratar con problemas de seguridad. Asegúrese de que el sitio esté protegido contra la inyección de SQL y de la inyección de correo electrónico. Por lo menos, puede hacer una búsqueda de llamadas a la base de datos y agregar llamadas a mysql_real_escape_string() (bueno, si está usando una base de datos MySQL) ... puede hacer una corrección real más adelante una vez que comprenda mejor el código. Para la inyección de correo electrónico ... escriba una función de filtro que filtra el código de spammer y asegúrese de que se filtran todos los campos de formulario que se usan en un correo electrónico. (Sí, agrega más código de spagetti, pero tomará un tiempo antes de que esté listo para refactorizar significativamente el código).

5. Después de eso, sugiero actualizaciones incrementales. Eres nuevo y el código es un caos enorme, por lo que te tomará un tiempo entenderlo todo ... y comprender completamente el dominio. Así que solo haga su trabajo un poco, arregle lo que debe arreglarse y agregue lo que se debe agregar. Mientras lo haces, estás aprendiendo cómo se arma el sistema. Una vez que sepa cómo el código está organizado (o no organizado) un poco mejor, puede comenzar a planificar una refactorización / reescritura importante del sistema. Con suerte, puede hacerlo componente por componente para que siempre tenga un nuevo hito en perspectiva.

Answer 24

Se como te sientes. Heredé el desarrollo de tal proyecto. Estuvo conmigo por un año y para ser honesto, me convirtió en el desarrollador que soy hoy. No hay mejor oportunidad para el progreso personal que trabajar metido en la mierda.

Aquí están las cosas que más me han ayudado:

• identifica cuáles son los archivos clave del sistema. Los encontrarás porque la mayor parte de tu trabajo se hará en ellos
• cree una versión local del proyecto (incluida la base de datos) y póngala bajo control de versiones
• trabajar solo en una pequeña cantidad de archivos con pequeños cambios
• no coloque nada dentro de la versión de producción hasta que lo haya probado completamente y luego esté listo para volver a colocar la versión anterior

• Descubra cómo se manejan los usuarios del sistema (sesiones, cookies). Cree un súper usuario y luego, cuando necesite probar su código en vivo en el sistema, colóquelo en un bloque como este:

  if($_POST[''your_registered_user_name'']{
  //Your live code being tested, which will be visible only to you when you are logged in
  }

  otros usuarios no podrán sentir los cambios. Esta técnica me ayudó mucho cuando no pude reemplazar el estado del sistema en mi máquina local

• prueba de escritura y siga estrictas pautas de ingeniería para todo el código que está escribiendo

Answer 25

Considere volver a escribir y use el sitio antiguo como una especificación de características

Sorprendentemente, nadie siquiera mencionó esto, hasta donde puedo ver, pero hay otra alternativa: renunciar al código y simplemente usar la funcionalidad del sitio como una nueva especificación de conjunto de características (es decir, la primera vez para este proyecto) y luego reconstruir el sitio, basado en esas características, con un marco establecido (como Symfony, Laravel o Drupal).

Sí, hay quienes se avergonzarían de la palabra malvada reescribiendo ... pero hay casos en que esto es realmente una mejor manera de hacerlo, y usted insinuó algunas razones:

• eres bastante nuevo en el desarrollo de PHP, tú mismo
• Probablemente será mejor que comiences con algo limpio en lugar del código de mierda puro que has heredado
• en el análisis final, a la mayoría de los usuarios no les importa un comino el código fuente , y si parece que les "funciona", pueden mirarlo como si estuvieras loco si intentas decirles que algo está terriblemente mal
• Te divertirás más y vivirás una vida más larga si retomas las prácticas del control de revisión de fuente y el diseño de la base de datos dentro de un marco unificado que parece que alguien realmente se preocupó lo suficiente como para tener su nombre adjunto.

Claro, todos en esta posición han tenido que trabajar con códigos como este antes, pero a veces es suficiente y es mejor desechar los espaguetis y comenzar con un plato nuevo.

Si lees el artículo de Joel sobre por qué es malo volver a escribir, notarás que casi ninguna de las circunstancias que cita se aplican a ti aquí.

Answer 26

Una cosa que podría considerar es instalar la extensión PHP "xdebug" en un entorno de desarrollo, configurarlo para rastrear todas las llamadas a funciones y, a continuación, lo más completamente posible (posiblemente a través de pruebas de UI automatizadas) ejercer toda la aplicación. A continuación, podrá analizar / analizar los archivos de rastreo xdebug para encontrar todos los archivos / funciones utilizados por la aplicación.

Answer 27

Otras personas en este hilo tienen buenos consejos. He estado en esta situación también. Probablemente, todos al mismo tiempo en su carrera entraron en un proyecto que parece haber sido golpeado por un tornado.

Una sugerencia que agregaría es que antes de realizar la limpieza descrita por otras personas, debe obtener la aprobación de la administración.

• Haga un plan basado en sugerencias sobre este hilo.
• Describa cualquier hardware o software nuevo que necesite para crear un entorno de desarrollo y prueba, y cueste el precio.
• Averigüe en qué nuevas habilidades debe capacitarse para configurar y usar el entorno de desarrollo y pruebas. Estime el tiempo y los gastos necesarios para que pueda obtener esas habilidades. Ej. Libros o entrenamiento pagado.
• Estime un horario de trabajo para que haga la limpieza. ¿Cuánto tiempo para obtener el código bajo control de fuente? ¿Cuánto tiempo entender la base de datos? ¿Cuánto tiempo para entender el PHP y el código de JavaScript?
• Preséntele esto a su gerente y defina el objetivo en términos de beneficio para su resultado final. Por ejemplo, una vez que se haya limpiado todo, realizar cambios o desplegar nuevas funcionalidades será más rápido, los errores de depuración serán más predecibles, y aumentar el personal nuevo será más fácil.

Naturalmente, debe seguir trabajando con el lío actual, porque es un sitio en vivo. Administrar el sitio en vivo tiene prioridad, por lo que el trabajo de limpieza debe ser una tarea de fondo. Eso significa que tomará aún más tiempo. Mis experiencias en la limpieza de un proyecto de tamaño moderado como una tarea de fondo generalmente han tomado de seis a doce meses. Debido a que el sitio continuará evolucionando durante este período, es posible que algunas de sus tareas de limpieza completadas deban revisarse o volver a realizarse. Asegúrese de que su gerente comprenda todo esto también.

Si el gerente se niega a su plan para limpiar este desastre, o no valora limpiarlo, al menos sabrá por qué todos los demás desarrolladores han abandonado esta empresa.

Tengo algunas sugerencias específicas sobre cómo proceder:

• Además de todos los otros excelentes consejos, sugeriría utilizar Joel Test como referencia. Su plan de limpieza debería resultar en un ambiente de trabajo que tenga una buena calificación en la Prueba Joel.
• Lea mi respuesta a " ¿Cuáles son las mejores formas de entender una base de datos desconocida? "
• Habilite el inicio de sesión en el sitio web para que pueda analizar qué páginas PHP se están llamando en realidad. Al menos eso te dice cuál de index2.php, index3.php, index4.php, etc. están realmente obsoletos.
• PHP tiene una función get_included_files() que devuelve una matriz de todos los archivos incluidos durante la solicitud actual. Al registrar esta información, puede averiguar qué archivos PHP están en uso, incluso si no aparecen en el registro del servidor web.
• Realmente necesita tener un entorno de prueba y desarrollo que coincida con su servidor de producción. No es bueno probar en Windows e implementar en Linux. No es bueno usar MySQL 5.0 durante el desarrollo y MySQL 4.0 en producción. Probablemente pueda salirse con la suya con una plataforma de hardware más modesta (aunque compatible).