Salut,
n'hésite pas à confronter tes arborescence avec celles qui existent, au travers des CMS (ie, Wordpress) ou Frameworks (ie y'en a un tas).
En règle générale, une arborescence est "bonne" si:
• Elle est efficace quand tu cherches un trucs c'est à dire que si tu cherches un truc dans l'arborescence, alors tu ne fais que descendre dedans: tu ne remontes jamais à un parent
• Elle est univoque, c'est à dire que si tu as un élément à ranger dans l'arborescence, alors il n'a qu'une et une seule place logique.
Là, je peux te dire plusieurs choses pour ton arbo:
• "include", "admin", "header", "url_rewriting" vs "erreurs", "jeu": choisie une seule nomenclature de noms de fichiers/dossiers, et respecte-la. Par exemple, tu peux dire "je mets tous les noms en français, sans accent, et avec des "_" (snake_case). Ou alors, tu peux te dire "je mets tout en anglais, avec des Majuscules façon CamelCase". Choisis.
• Pas de section dédié aux fichiers accessibles depuis le web. Cela va te jouer des tours et de poser des difficultés pour les droits d'accès. N'hésite pas à séparer la section "ceci est accessible par le web (css, images, php recevant la requête entrante, etc)" de "ceci n'est pas accessible du web (fichiers sql de BDD, fichiers PHP du core du jeu, scripts bash, etc".
• Où sont les logs? "erreurs" va probablement les contenir, mais je pencherai pour un "logs/errors" + "logs/access" etc, bref un dossier dédié aux logs dans lequel se trouvera le dossier des erreurs (d'ailleurs, pourquoi un tel dossier?).
• Tes fichiers PHP ne sont pas dans un dossier dédié ("vendor namespace"), aka comment tu vas faire si tu veux ajouter des fichiers PHP issus d'un framework?
Pour info, j'ai cette arbo (je m'aperçois que j'ai des noms et des verbes dans mon arbo, c'est un peu dommage):
→ config/ (configurations de l'environnement, pas les configs du jeu, aka Apache, phpunit, Netbeans, etc)
→ data/ (données générées par les utilisateurs du jeu)
→ deploy/ (scripts de déploiement, mais je le trouve mal placé...)
→ php/ (codes du jeu)
→ resources/ (ressources internes, aka XSL, XML, etc)
→ sql/ (fichiers SQL, créant les procédures SQL ou générant les données pour la BDD; donc 2 sous-dossiers: procedures/ et initialize/)
→ www/ (fichiers accessibles du web, aka interface du jeu avec le web; 2 sous dossiers handler/ et resources/ contenant pour le 1er les PHP réceptionnant les requêtes et pour le 2nd, les fichiers CSS, JS etc)
PS: Il y a des remarques qui sont peut-être en "anticipation", donc tu peux éventuellement les ignorer.
PSS: ton cycle de "on copie de dev/ dans un dossier dédié avec un dump BDD blabla" s'appelle une "mise en prod", ou "deploy" ("déploiement"). Des scripts déjà faits existent, des outils puissants aussi (façon Jenkins, totalement surdimensionné dans ton cas je pense mais à essayer pour la culture). Alors je te conseillerai de laisser tomber le déploiement manuel (avec une gestion des numéro de version totalement à la mano
) au profit d'un outil existant, dont tu n'auras pas à assurer la maintenance et qui t'obligera à bien séparer les choses (aka, séparer la phase "je développe des trucs", la phase "je partage mes modifs" et la phase "je publie la nouvelle version").
n'hésite pas à confronter tes arborescence avec celles qui existent, au travers des CMS (ie, Wordpress) ou Frameworks (ie y'en a un tas).
En règle générale, une arborescence est "bonne" si:
• Elle est efficace quand tu cherches un trucs c'est à dire que si tu cherches un truc dans l'arborescence, alors tu ne fais que descendre dedans: tu ne remontes jamais à un parent
• Elle est univoque, c'est à dire que si tu as un élément à ranger dans l'arborescence, alors il n'a qu'une et une seule place logique.
Là, je peux te dire plusieurs choses pour ton arbo:
• "include", "admin", "header", "url_rewriting" vs "erreurs", "jeu": choisie une seule nomenclature de noms de fichiers/dossiers, et respecte-la. Par exemple, tu peux dire "je mets tous les noms en français, sans accent, et avec des "_" (snake_case). Ou alors, tu peux te dire "je mets tout en anglais, avec des Majuscules façon CamelCase". Choisis.
• Pas de section dédié aux fichiers accessibles depuis le web. Cela va te jouer des tours et de poser des difficultés pour les droits d'accès. N'hésite pas à séparer la section "ceci est accessible par le web (css, images, php recevant la requête entrante, etc)" de "ceci n'est pas accessible du web (fichiers sql de BDD, fichiers PHP du core du jeu, scripts bash, etc".
• Où sont les logs? "erreurs" va probablement les contenir, mais je pencherai pour un "logs/errors" + "logs/access" etc, bref un dossier dédié aux logs dans lequel se trouvera le dossier des erreurs (d'ailleurs, pourquoi un tel dossier?).
• Tes fichiers PHP ne sont pas dans un dossier dédié ("vendor namespace"), aka comment tu vas faire si tu veux ajouter des fichiers PHP issus d'un framework?
Pour info, j'ai cette arbo (je m'aperçois que j'ai des noms et des verbes dans mon arbo, c'est un peu dommage):
→ config/ (configurations de l'environnement, pas les configs du jeu, aka Apache, phpunit, Netbeans, etc)
→ data/ (données générées par les utilisateurs du jeu)
→ deploy/ (scripts de déploiement, mais je le trouve mal placé...)
→ php/ (codes du jeu)
→ resources/ (ressources internes, aka XSL, XML, etc)
→ sql/ (fichiers SQL, créant les procédures SQL ou générant les données pour la BDD; donc 2 sous-dossiers: procedures/ et initialize/)
→ www/ (fichiers accessibles du web, aka interface du jeu avec le web; 2 sous dossiers handler/ et resources/ contenant pour le 1er les PHP réceptionnant les requêtes et pour le 2nd, les fichiers CSS, JS etc)
PS: Il y a des remarques qui sont peut-être en "anticipation", donc tu peux éventuellement les ignorer.
PSS: ton cycle de "on copie de dev/ dans un dossier dédié avec un dump BDD blabla" s'appelle une "mise en prod", ou "deploy" ("déploiement"). Des scripts déjà faits existent, des outils puissants aussi (façon Jenkins, totalement surdimensionné dans ton cas je pense mais à essayer pour la culture). Alors je te conseillerai de laisser tomber le déploiement manuel (avec une gestion des numéro de version totalement à la mano
) au profit d'un outil existant, dont tu n'auras pas à assurer la maintenance et qui t'obligera à bien séparer les choses (aka, séparer la phase "je développe des trucs", la phase "je partage mes modifs" et la phase "je publie la nouvelle version").