14-11-2015, 08:02 PM
Pour moi, tu te lances là dans un projet évolutif et à long terme. C'est donc à l'opposée du prototype. Du coup, je te conseillerai de partir sur de l'OO, pas du procédural.
Okay, pour fixer les idées, c'est une bonne chose que d'avoir un support (les garder juste "en tête", ça ne marche jamais ^^ ).
Huh... Je ne sais pas où t'as pioché cet article sur le versionning, mais si tu procèdes ainsi, tu vas te creuver pour rien
Les "notes des modifications depuis la dernière version", c'est ce qu'on appelle les "messages de commit" (1 commit = 1 changement de code versionné, validé). Quant à diviser son projet, je pense que ce sera une bien plus grosse source d'emm*des que de bienfaits (quand tu auras besoin de ce genre de chose, cad dans 6 mois ou plus, tu pourras te tourner du coté des "branches" des logiciels de versionning).
Regarde du coté de ces logiciels de versionning d'ailleurs, plutôt que des méthodes manuelles. Pour ma part, j'utilise Mercurial (ou "hg", je te laisse chercher, ça se trouve facilement) couplé à Tortoise: Mercurial est le coeur du versionning (c'est le soft de versionning) et TortoseHg fournit une interface avec Windows et l'explorateur (très pratique et intuitif, cela évite de devoir manipuler de la ligne de commande tout le temps; et cette ligne de commande est quand même accessible si besoin).
La partie "Structure MVC" revient en gros au principe d'Akira (séparer la partie Web et le coeur de jeu, qui chez moi se trouve dans le SQL car je n'aime pas l'idée de faire des traitements de données dans le PHP).
Je n'ai pas de site explicatif sur les procédures (à part la doc MySQL, mais c'est pas très "tuto"). N'oublie pas qu'au final, MySQL (ou tout autre *SQL) n'est qu'un serveur (comme Apache en fait) que tu peux requêter avec un logiciel (genre MySQLWorkbench, mais je ne l'aime pas celui-là...) ou avec un module/librarie (façon PHP et sa librairie PDO ou MySQLi; c'est aussi ce que fait phpMyAdmin puisqu'il s'agit de code PHP). Donc la création de procédure fonctionne comme l'exécution de n'importe quelle requête SQL, la requête demande simplement au serveur de créer la procédure (au lieu de lui demander des données). Ensuite, une fois cette procédure créée, le jeu n'a plus qu'à l'utiliser pour dire "faire produire toutes les usines" (par exemple). Donc, inutile de vouloir créer des procédures "à la volée" ou "en temps réel": mieux vaut les créer hors du code du site (perso, j'ai un dossier "sql/*" à coté de mon "php/*") et s'en servir ensuite dans le site. C'est là où se trouve la similarité avec la notion de "librairy" d'Akira, ma bibliothèque étant l'ensemble des fichiers .sql qui déclarent les procédures avec la logique métier.
D'ailleurs, pour la gestion MySQL, j'utilise HeidiSQL (=phpMyAdmin mais en mieux fichu et hors du navigateur): on peut y créer les procédures SQL facilement via l'interface graphique (le contenu de la procédure est à rédiger soi-même, c'est du SQL classique, mais ce qui est "autour" est géré par HeidiSQL).
Okay, pour fixer les idées, c'est une bonne chose que d'avoir un support (les garder juste "en tête", ça ne marche jamais ^^ ).
Huh... Je ne sais pas où t'as pioché cet article sur le versionning, mais si tu procèdes ainsi, tu vas te creuver pour rien
Les "notes des modifications depuis la dernière version", c'est ce qu'on appelle les "messages de commit" (1 commit = 1 changement de code versionné, validé). Quant à diviser son projet, je pense que ce sera une bien plus grosse source d'emm*des que de bienfaits (quand tu auras besoin de ce genre de chose, cad dans 6 mois ou plus, tu pourras te tourner du coté des "branches" des logiciels de versionning).Regarde du coté de ces logiciels de versionning d'ailleurs, plutôt que des méthodes manuelles. Pour ma part, j'utilise Mercurial (ou "hg", je te laisse chercher, ça se trouve facilement) couplé à Tortoise: Mercurial est le coeur du versionning (c'est le soft de versionning) et TortoseHg fournit une interface avec Windows et l'explorateur (très pratique et intuitif, cela évite de devoir manipuler de la ligne de commande tout le temps; et cette ligne de commande est quand même accessible si besoin).
La partie "Structure MVC" revient en gros au principe d'Akira (séparer la partie Web et le coeur de jeu, qui chez moi se trouve dans le SQL car je n'aime pas l'idée de faire des traitements de données dans le PHP).
Je n'ai pas de site explicatif sur les procédures (à part la doc MySQL, mais c'est pas très "tuto"). N'oublie pas qu'au final, MySQL (ou tout autre *SQL) n'est qu'un serveur (comme Apache en fait) que tu peux requêter avec un logiciel (genre MySQLWorkbench, mais je ne l'aime pas celui-là...) ou avec un module/librarie (façon PHP et sa librairie PDO ou MySQLi; c'est aussi ce que fait phpMyAdmin puisqu'il s'agit de code PHP). Donc la création de procédure fonctionne comme l'exécution de n'importe quelle requête SQL, la requête demande simplement au serveur de créer la procédure (au lieu de lui demander des données). Ensuite, une fois cette procédure créée, le jeu n'a plus qu'à l'utiliser pour dire "faire produire toutes les usines" (par exemple). Donc, inutile de vouloir créer des procédures "à la volée" ou "en temps réel": mieux vaut les créer hors du code du site (perso, j'ai un dossier "sql/*" à coté de mon "php/*") et s'en servir ensuite dans le site. C'est là où se trouve la similarité avec la notion de "librairy" d'Akira, ma bibliothèque étant l'ensemble des fichiers .sql qui déclarent les procédures avec la logique métier.
D'ailleurs, pour la gestion MySQL, j'utilise HeidiSQL (=phpMyAdmin mais en mieux fichu et hors du navigateur): on peut y créer les procédures SQL facilement via l'interface graphique (le contenu de la procédure est à rédiger soi-même, c'est du SQL classique, mais ce qui est "autour" est géré par HeidiSQL).