Bien programmer

[archANJS]

Bonjour à tous.

Je suis toujours en train de travailler sur Age Lointain ! J'approfondis surtout mon cahier de charges (qui en fait est une dizaine de cahiers papiers sur mon bureau) avant autre chose ces temps-ci. J'ai écris la plupart de mes algorithmes et j'ai pensé à la majorité des fonctions du jeu (comment je les ferai). J'améliore aussi ma méthode de programmation. D'où ma question !

Bon, situation. Je sais que je serais capable de coder tout mon jeu et le rendu serait très bon ! (ce n'est pas pour me vanter loin de là). Mais ça ne voudrait pas dire nécessairement que mon jeu serait bien programmé.

Donc, le problème. J'aimerais savoir ce qu'il faut, en fait, ce qui différencie un projet bien programmé d'un projet correctement programmé.

Mon idée. Je pense qu'il est favorable (nécessaire?) d'avoir une structure MVC. J'ai donc adapté mon site à cette structure. Pour le lien du projet en ligne : Âge Lointain.
Il y a juste la présentation et l'inscription, et même, celle-ci est désactivée. C'était pour tester ce que j'avais comme droit pour mon hébergement. Ce que j'en retiens : aucun droit pour les .htaccess, donc tout mon url rewriting que j'avais programmé -> tombé à l'eau (-.-), mais bon ! mon design marche (). si on peut appeler ça un ''design''... mais bon je suis pas designer donc ! hors-sujet.

J'ai pensé aussi qu'il serait bien d'utiliser un framework. Mais est-ce nécessaire/mieux ? J'ai pensé à CakePHP et CodeIgniter. Mais je sais pas lequel est mieux, selon moi, c'est du pareil au même. Quels sont les critères d'habitude pour choisir ? (dans votre cas ?)

Et finalement, il y a sûrement des techniques ''supérieures'' à utiliser. Je pense à la tamporisation de sortie et l'opérateur ternaire. (j'ai compris les deux) Y en a-t-il d'autres ?

Donc pour ceux qui n'auraient pas compris ma question, je reformule : Qu'est-ce que bien programmer, dans le contexte d'un jeu par navigateur ?

Cordialement,
archANJS

[Sephi-Chan]

À mon sens, bien programmer une application Web, c'est avoir un résultat fonctionnel avec un code facile à lire et à maintenir, assez efficace et qui ne souffrira pas trop de l'augmentation du nombre de joueurs (scalabilité).

Pour atteindre un tel résultat, on peut utiliser des recettes qui marchent bien : les design pattern. Parmi eux, il y a effectivement MVC, qui permet de séparer les couches de l'application pour mieux les contrôler. Le principe étant bien sûr de séparer pour mieux régner, mais pas trop sinon on ne s'y retrouve plus.

Dans cette optique, l'utilisation d'un framework n'est pas optionnelle : on ne peut pas faire ça sans (voici une liste non exhaustive des raisons qui le rendent indispensable : Pourquoi utiliser un framework ?). Idéalement, on utilisera un framework open source car les frameworks maisons sont moins fiables (car moins éprouvés) et — dans la vaste majorité des cas — de moins bonne qualité.

Note qu'on peut aussi faire de la daube avec un framework, mais c'est plus difficile.

Concernant le choix, ça dépend de toi. Voici les principaux pour PHP et mon avis sur chacun :

• Symfony (en version 2) : c'est le gros framework full stack mais qui reste assez facile à prendre en main. Il est assez conventionnel dans son approche. C'est celui que je conseille si on reste sur PHP ;
  
• Zend Framework : c'est également un gros morceau très complet mais à la courbe d'apprentissage très raide et qui ne ressemble à rien d'autre. Même s'il fournit d'excellent outils, il y a pas mal de choses pénibles à faire soi-même et souvent des tas de manières de le faire, donc on ne sait pas vraiment comment faire les choses. Je le déconseille à moins d'avoir une très bonne expérience des frameworks et beaucoup de temps à investir dans son apprentissage ;
  
• CakePHP : Un bon framework mais quitte à l'apprendre, autant changer de langage et se tourner vers son père spirituelle, infiniment plus efficace : Ruby on Rails. Et je dis ça très sérieusement : avec un certain bagage technique, apprendre un langage est plutôt facile. Si ça mène vers la crème des frameworks Web, ça vaut le coup de songer à franchir le pas. C'est ce que j'ai fais et je ne le regrette pas, mais il faut dire que le développement Web est ma passion.
  
• Code Igniter : Plus modeste que les autres, il reste efficace et propose le minimum. C'est pas mal quand on est vraiment débutant ou qu'on prépare un petit site.
  

Ensuite, bien programmer, c'est écrire des tests. Au minimum des tests unitaires qui testent individuellement chaque méthode pour s'assurer qu'elles font bien leur travail.
Les tests d'intégration sont également très important : est-ce les features de l'application fonctionnent ? Pour ça, on a des outils comme Cucumber. Créer du code fiable qui ne régresse pas et qui n'introduit pas de bug dans l'existant, c'est bon pour la qualité (car mine de rien, écrire du code facile à tester unitairement n'est pas toujours facile et oblige à bien réfléchir) et ça rassure lors des déploiement et des développement de nouvelles fonctionnalités profondes.

[Akira777]

Pour poursuivre un petit peu le post de Sephi-chan, il y a plusieurs points que je mettrais au clair.

Premièrement, ton modèle, pour ma part, j'aime bien, avant de m'occuper de l'affichage, mettre au point des objets qui tiennent la route, avec une classe par fichier. Et une classe qui gère ton affichage. Tes autres objets vont communiquer avec cette classe pour lui transmettre les messages d'erreurs destinés à l'utilisateur.

Secondement, une classe abstraite qui gère les connexions avec ta base et les données de tes joueurs. Qui intègre également un Singleton, c'est pas mal non plus

Concernant l'URL Rewriting, je ne te le conseillerai pas sur un jeu par navigateur, surtout si tu commences par un mutualisé. Parce que le rewriting, c'est vraiment gourmand en ressource...

Pour revenir sur la base de donnée je te conseillerais de faire dès que possible des INNER JOIN plutôt que des LEFT ou RIGHT JOIN. MySQL (si tu l'utilises) ne gère pas de manière optimale les jointures externes. Petit exemple, j'ai fait un benchmark récemment, la même requête avec LEFT JOIN et INNER JOIN, sur une série de 1.000.000 de requêtes sur ma base (grosse requête qui plus est). Résultat 8 minutes pour le LEFT, 7 secondes pour INNER, oui c'est impressionnant.

Les fonctions quand à elle, ne doivent faire qu'une chose, vraiment c'est important pour la lecture et la maintenabilité. Par exemple, pour l'affichage d'une page avec des droits spéciaux, j'aime bien faire 3 fonctions privées et une publique, la publique qui s'intégrera au template avec un nom très clair et les privées qui gèrent le fonctionnel, une pour la récupération MySQL, une pour la structure de contrôle (si niveau supérieur à 85, si argent inférieur à 1000) et la dernière qui gère les connexions avec les logs, l'affichage (message d'erreur) et le retour au contrôlleur (architecture MVC).

J'ai vu que tu parlais de l'opérateur ternaire. Tu as raison, c'est super optimisé, mais ça freine un peu la lisibilité, je dirais qu'il faut l'utiliser avec parcimonie.

Voilà, pour le moment, c'est tout ce que j'aurais à dire et qui me vient à l'esprit. Si tu as d'autres questions n'hésites pas !

[Hideaki]

Ta question se rapproche d'avantage de "Bien concevoir" que "Bien programmer" pour ce qui est MVC, Framework, ...

"Qu'est-ce que bien programmer ?" (liste non exhaustive) :
* C'est de bien commenter.
* C'est de mettre des noms auto-informant.
* C'est bien tester son application.
* C'est d'éviter le copier-coller.
* C'est de respecter les normes de nommage.
* ...

"dans le contexte d'un jeu par navigateur ?" (liste non exhaustive) :
* C'est que la vue du joueur soit irréprochable.
* C'est optimiser ces pages, séparer les CSS et JS du HTML
* C'est vérifier que le jeu fonctionne bien quelques soient les navigateurs cibles.
* C'est être le plus clair possible avec les messages destinés aux joueurs ( message d'erreur, action possible, etc )
* Les autres questions sur l'accessibilité et autres designs voir le designer
* ...

BONUS
"Qu'est-ce que bien concevoir ?" (liste non exhaustive) :
* C'est anticipé les futurs évolutions
* C'est anticipé les futurs difficultés que l'architecture peut avoir.
* C'est de facilité la tâche du développeur en lui préparant tout ou presque à l'avance
* C'est de choisir un framework et de préparer une architecture en fonction de celui, tout en prévoyant la possibilité d'en changer sans que celui n'affecte trop profondément le code.
* C'est de prévoir une architecture facilement maintenable.
* ...

Parmi eux, il y a effectivement MVC, qui permet de séparer les couches de l'application pour mieux les contrôler. Le principe étant bien sûr de séparer pour mieux régner, mais pas trop sinon on ne s'y retrouve plus.

@Sephi-chan: ta définition est fausse car il ne s'agit pas de séparer les couches mais de séparer les données, la présentation et les traitements, MVC est utilisé dans la couche de présentation. Pour séparer les couches, c'est le modèle n-tiers qui peut ou pas utiliser le MVC dans sa couche de présentation

[pascal]

10 cahiers papier comme cahier des charges ?

Bien programmer, c'est aussi :
- programmer moins
- éviter le bla bla, coder au lieu de faire des cahiers des charges à rallonge
- moins d'options
- moins de fonctionnalités
- mettre en production

++

[Akira777]

@Hideaki, un bon programme n'a pas besoin d'être commenté pour être compris. Ca reste mon avis, mais j'applique cette règle très souvent. En séparant bien ton code et en mettant des noms clairs, explicites et des fonctions qui font exactement une chose bien précise, tu as besoin que de très peu de commentaires. Sinon, j'suis plutôt d'accord avec toi sur tous tes points.

[Hideaki]

@Akira777 effectivement pour un programme simple, mais entre lire une ligne expliquant le fonctionnement exacte et lire tout le code pour le comprendre au niveau vitesse, il n'y a pas de soucis l'autre avantage est de générer de la documentation. Dans un projet où interviennent différentes personnes ou des noms de méthode / fonction qui font une tâche presque identique mais de fonctionnement différente exemple l'utilisation d'interface.

@Pascal Ce n'est pas au développeur de s'occuper d'un cahier des charges mais de le respecté.

[pascal]

@Pascal Ce n'est pas au développeur de s'occuper d'un cahier des charges mais de le respecté.

Tous les cahiers des charges ne sont pas respectables.

Je te conseille de lire getting real, par les créateurs de Ror : le CDC est peut être un élément en dehors de la programmation, n'empêche qu'il a sa place - ou pas dans un projet informatique.

En gros, les 3/4 du CDC sont des scpéculations, on ne sait pas ce que le programme (jeu, site...) va donner avant d'avoir un début de programme. Ils conseillent donc de faire des spécs très courtes et de coder à partir de ses spécs, en commençant par les écrans.

Bien programmer c'est aussi choisir une méthodologie adaptée et un projet pas trop foireux

++

[archANJS]

@Sephi-Chan : Merci pour tes réponses. Pour ce qui est scabilité, j'y avais déjà pensé (et justement c'est un des trucs qui compliquent beaucoup mon jeu, côté administration en tout cas).
Les conseils pour les frameworks sont très appréciés : je crois que je vais choisir Symfony 2. Je vais chercher pour les tests... comme de fait, je n'en avais jamais utilisé aucun.

@Akira777 : C'est drôle parce que j'avais pensé aux mêmes classes : Page (affichage), Connexion (pour la bdd), Traitement (erreurs et vérifications), Accès (accès aux pages), etc.

Pour ce qui est de l'URL Rewriting, je sais que ce n'est pas nécessaire, mais selon moi c'est un plus.
En plus, j'avais pensé (tant qu'à réécrirre l'url, autant le faire à mon gout héhé) à faire une url personnalisée du type : /controleurouscontroleur?action (ex. agelointain.com/ville:ecurie?acheter pour les pages, et pour les forums, profils, etc., agelointain.com/forum:1054_1_Presentations-des-joueurs.html?editer (controleur:id_page_nom-du-topic.html?action)...

Je pourrais contacter mon hébergeur (qui est un ami) pour me donner le ''pouvoir'' .htaccess.. mais tu viens de me dire que ça bouffe en ressources... Me conseilles-tu quand même de faire mon URL Rewriting, ou je laisse tomber ? (du moins jusqu'à ce que j'achète mon dédié l'année prochaine)

@Hideaki : En effet, ''Bien concevoir'' définit mieux ma question Merci pour les listes ! Utile.

@pascal : Dans mon cas, le cahier de charges est essentiel. Détrompe-toi, les 10 cahiers ne sont pas remplis : je préfère juste bien séparer les sujets.

Bien programmer, c'est aussi :
- programmer moins
- éviter le bla bla, coder au lieu de faire des cahiers des charges à rallonge
- moins d'options
- moins de fonctionnalités
- mettre en production

En effet, ça se résume à ce que j'en pense aussi. C'est ce que j'essaie de faire^^
sauf pour le quatrième point o.O

En tout cas, merci à tous pour vos réponses ! Ça m'a beaucoup aidé... mais a également suscité une autre question !

C'est au sujet de la carte du jeu.. la question trotte dans ma tête depuis un moment déjà mais je n'ai pas encore trouvé de solution (plus ou moins disons).

Contexte : Dans mon jeu, le monde évolue selon le nombre de joueurs. Plus il y a de joueurs, plus de villes seront créées. Ainsi les villes ne seront jamais surchargées, et le monde ne sera pas fixé dans le béton.

Problème : Au niveau de la carte surtout. Comment gérer les déplacements ?

Voici comment elle est conçue pour le moment : 2 paliers, 3 couches. La carte est séparée en x et y, en cases dans le fond, mais on ne les voit jamais.

Palier 1 : carte du monde avec les pays. au survol, les pays s'illuminent. on ne peut que cliquer sur les pays (pas de villes), qui nous dirige vers le palier 2.
Palier 2 : la carte en tant que tel, avec toute les villes. au clic de celles-ci, on a une pop-up pour avoir des infos (nombres d'habitants, seigneur, etc.) et un bouton Voyager vers.

Couche 1 : le fond de la carte. c'est une image qui ne change pas, avec les montagnes, forets, rivieres, etc.
Couche 2 : le niveau. 0: Plaines, 1: Collines, 2: Forêts, 3: Rivières, 4: Lac, 5: Fleuve, 6: Océan, 7: Désert, 8: Montagnes, 9: Falaise, 10: Inaccessible. Pour gérer l'accessibilité et le temps de déplacement. Exemple : une plaine (30 min), une colline (35 min), une falaise (infranchissable), une rivière (naviguable et traversable), un fleuve (seulement naviguable), etc.
Couche 3 (la seule cliquable) : les évènements. C'est en gros les villes (éventuellement les foires).



Voir l'image ci-haut. Normalement, on ne verrait pas le quadrillage, mais notez que ce n'est pas l'image officielle (nan, pour vrai ?).

Donc, je sais quoi faire si je vais de A à B. Je n'ai qu'à augmenter le temps, vu qu'une rivière est traversable. Je sais quoi faire pour de C à D. Le joueur ne peut pas traverser, il a besoin d'un bateau. Mais quoi faire pour de E à F ? Je souhaiterais que le programme note qu'il y a un détour, qu'il le spécifie au joueur et qu'il calcule le détour à faire. Hum.

Comment je pensais le faire, c'est de prendre le point de départ, le point d'arrivée et de faire un chemin, case par case, puis de vérifier le niveau, faire le calcul de temps, etc. Qu'est-ce que vous en dites ?

QUESTION DEUX

Surtout posée à Sephi-Chan. J'ai envisagé de changer pour programmer en Ruby. Est-ce le bon choix ? Je veux dire, j'ai déjà tout appris en PHP, est-ce que ce sera très différent ? Plus compliqué et long qu'utile ?


Merci pour vos réponses futures.. (s'il y en a )

[Sephi-Chan]

Pour gérer ces déplacement, il faut que tu modélises un graphe et que tu y appliques un algorithme de recherche de plus court chemin (tel que A* ou celui de Dijkstra), je te conseille A*, il est plus simple à implémenter et plus performant et donnera d'excellents résultats pour un tel graphe peu complexe.


Pour ce qui est d'apprendre Ruby et Rails, c'est plutôt facile dès lors que tu lis l'anglais. Le fait que tu connaisses bien un autre langage aidera aussi : Ruby n'utilise pas de paradigme trop exotique donc il sera assez simple d'assimiler le gros du langage. De plus, étant entièrement objet, tu n'as pas cette séquence débile qui consiste à apprendre en procédural pour ensuite tout désapprendre et réapprendre avec l'objet.

Les gens que j'ai poussé sur les Rails ont rapidement été opérationnels (2 semaines à 1 mois, en y accordant seulement une poignée d'heures par semaine). C'est d'autant plus rapide si tu es aidé (et ça, je peux faire ^^).