Sea o no sea de tu agrado, como un desarrollador profesional, tarde o temprano tendrás que realizar algún tipo de personalización sobre un software existente.

Si no estás familiarizado con el software, es bueno mirarlo un poco antes de aceptar el trabajo. En esta nota, te traemos 10 consejos para identificar rápidamente software PHP basura.

1. El software trata de reinventar el objeto modelo, o fijar las propiedades de lenguaje

Fíjate si puedes encontrar una clase llamada “Object”. Si la encuentras, es una indicación bastante clara de que el autor se encuentra intentando reinventar el objeto modelo (comúnmente esto se da por su falta de conocimiento). Por lo que es seguro asumir que sus “arreglos” no pararán ahí. Así que… ¡Desconecta el teléfono y ocúltate bajo tu escritorio!

2. El código incluye variables globales definidas por el usuario

Una búsqueda en el código por “global” o “$GLOBALS” podría revelar algo como esto:

La infame variable global. Si puedes decirme con seguridad lo que significan estas dos variables… o estás muy relacionado con el software del cual las obtuve, o eres psíquico. De hecho, te damos bonus extra si puedes decir qué parte del código puso sus garras en ellas hasta que el flujo de ejecución llegó a este punto. En definitiva… ¡Evitalas como plaga!

3. HTML y SQL disperso

Busca algunos strings SQL y HTML comunes. Deberías poder determinar de forma rápida si el HTML y el SQL se encuentran en los lugares apropiados. Si encuentras HTML y SQL en el mismo archivo, se trata definitivamente de basura.

4. Las Clases hacen demasiado

Encuentra los 3 archivos de clases más pesados (por ejemplo, ordenándolos por Tamaño). Observa el nombre de la clase. ¿Indica una responsabilidad distinta? Mira los métodos. ¿Las tareas que desempeñan se encuentran relacionadas? Si no lo están, ¡Sal de ahí! ¡Huye!

5. Muchas propiedades son públicas o muchas propiedades son estáticas

Si una gran cantidad de propiedades son declaradas como “public static”, triplica tu cotización. Si tengo que explicarte por qué, quizá haya una vacante en el equipo de desarrollo de ese software para ti.

6. Múltiples niveles de herencia

Más de dos niveles de herencia deberían ser evitados completamente. En serio, si algún día logras encontrar un uso apropiado de dos niveles de herencia, te invitaremos una cerveza (o un refresco de soda, en todo caso).

7. Los autores intentan usar patrones de diseño

Si los autores tienen una pista de lo que están haciendo o no, es fácil de determinar buscando en el código algunos de lo más comunes patrones de diseño. Busca en el código base y/o en la documentación, palabras como “fábrica”, “decorador”, “estrategia” etc. Si las encuentras, podrás determinar de forma rápida si los autores saben lo que están haciendo o sólo intentan parecer interesantes. Si no los encuentras… ¡Rechaza este proyecto!

8. El software se mete con el nivel de error

Las aplicaciones bien escritas funcionan bien a cualquier nivel de error. Buscando en los archivos /error_level(.*)/ debería bastar. En caso de que encuentres uno, trata reemplazar el valor por E_STRICT. Créeme, Se trata de algo más que una formalidad.

9. En el código base, hay un directorio llamado”core”

Esto es usualmente utilizado como una excusa para hacer que toda la aplicación dependa de lo que sea que hay ahí adentro. Más allá de lo atrayente que resulte el término (hace que el contenido suene bastante cool e importante), definir un “core” es una señal de mal diseño.

10. El software utiliza su propio lenguaje de template

Ten miedo. Mucho miedo. Estos diseñadores están tratando de reinventar la rueda. Ignora esta advertencia, y un día te encontrarás pasando toda una tarde tratando de escapar de un loop en un “for”.