No hay una definición canónica de "buen diseño": lo mejor que puede esperar es que su diseño equilibre las diversas fuerzas en su proyecto de la manera óptima. Las fuerzas en su proyecto pueden ser mantenibilidad, rendimiento, escalabilidad, extensibilidad, requisitos no funcionales clásicos, pero también aspectos como la optimización de motores de búsqueda, cumplimiento de estándares y accesibilidad (cosas que se aplican a proyectos web en particular).
Si todas sus URL tienen el formato "www.misitio.es/home.php?action=getDetails & productID = 123", la simpatía de su motor de búsqueda es bastante baja. Es mucho mejor tener URL semánticas: "www.mysite.com/products/DesktopPc/details.php". Puedes lograr esto a través del astuto truco de .htaccess en tu diseño actual.
Desde el punto de vista de la mantenibilidad, su diseño presenta algunos problemas. Si lo he entendido correctamente, agregar una nueva página al sitio requiere que modifique el código en varios archivos fuente diferentes: router.php (su declaración de cambio gigante), la página misma y probablemente también el header.php. Eso indica que el código está estrechamente coupled. La modificación de la declaración de cambio gigante suena como una fuente probable de errores de entretenimiento, y la combinación del enrutador y el encabezado, la manipulación de las variables, además de la página real en sí parece un poco frágil. Esto está bien si eres la única persona que trabaja en el proyecto, y estarás presente a largo plazo; si ese no es el caso, es mejor usar un marco estándar (MVC es el favorito actual; Zend, Symphony y Cake hacen todo esto bien en PHP) porque puedes apuntar a nuevos desarrolladores sobre la documentación y esperar que obtengan hasta la velocidad.
Uno de los mayores enemigos de la mantenibilidad es la complejidad: el código complejo es más difícil de trabajar y alberga más errores. Hay un formal metric para la complejidad, y estoy bastante seguro de que tu declaración de cambio puntúa muy bien en esa métrica, en sí misma no necesariamente un gran problema, pero definitivamente algo a tener en cuenta. Muchos frameworks MVC evitan esto al tener el enrutamiento definido como datos en lugar de código (es decir, tienen las rutas en un archivo de configuración), y/o usando convención sobre configuración (es decir, si la solicitud es para la página "productDetails", incluya el archivo "/inc/productDetails.inc").
La extensibilidad podría ser otra preocupación: imagine tener que exponer el contenido de su sitio como JSON o XML, así como HTML; en su diseño actual, eso requeriría una gran cantidad de cambios, porque cada ítem en el pipeline de procesamiento de su página se preocupa y necesita saber. El home.php necesita saber que no se debe enviar HTML, el encabezado y el pie de página deben saber que el enrutador necesita comprender cómo manejar el tipo de datos adicional, lo que casi seguramente hará que la declaración del conmutador sea aún más grande. Esto de nuevo puede no ser un gran problema.
Tanto la capacidad de extensión como la de mantenimiento se ayudan al poder probar el código de la unidad. Test Driven Development lo convierte en una rutina completa por derecho propio; Supongo que probar tu aplicación es difícil, pero eso es solo una suposición; depende más de cómo haya tenido en cuenta los grumos de código individuales de lo que ha descrito anteriormente. Sin embargo, otro beneficio de MVC es que facilita la escritura de pruebas de unidad para partes clave de su sistema.
Por lo tanto, si las fuerzas en su proyecto no incluyen un énfasis en facilidad de mantenimiento o extensibilidad, y puede manejar el aspecto de SEO, no creo que su diseño sea necesariamente "malo"; incluso si te importan esas cosas, hay otras cosas que puedes hacer para acomodar esas fuerzas: escribe documentación, contrata muchos codificadores baratos.
La mejor manera de ponerse al día con estos temas de diseño no son los libros en PHP o MySQL; Recomendaría "Refactoring" y "Patrones de la arquitectura de aplicaciones empresariales" de Martin Fowler, "Design Patterns" de Gamma et al. y Code Complete por McConnell (aunque ya está un poco desactualizado).
+1 por pregunta honesta. Si home.php es el punto de partida para cualquier solicitud, tiene (al menos un punto de partida) una arquitectura MVC. Felicidades! (y diseño de código perfecto = teoría intacta) – Teson
¡Gracias! Buscaré en la arquitectura MVC. – Chud37
su 'header' está haciendo mucho trabajo ... será difícil mantenerlo en el futuro si desea algunos cambios en futre. – itachi