Et maintenant?

Malgré quelques bugs, cette démo de déplacement des trains est une avancée majeure et valide le modèle d'entités graphiques (le bien nommé piglet), le modèle de rails, et le pathfinder. La pose de rails, malheureusement, reste très ardue, mais ce sous-système est suffisamment générique pour être facilement amélioré plus tard, ce qui le rend non prioritaire.

Je peux donc travailler sur l'amélioration du réalisme (accélérations et décélérations), l'interface (simplifier mon modèle d'itinéraires), et enfin m'attaquer à des améliorations de gameplay. Je pense notamment à enfin intégrer l'aspect passagers, avec des gares qui se remplissent de passagers désireux de voyager. L'aspect financier, avec le coût des gares, des rails et des trains, viendra plus tard.

Mais peut-être avant tout ça faut il d'abord trouver enfin un modèle raisonnable pour les callbacks (fonctions de rappel, me dit Wikipedia (!)) entre le moteur et la GUI. L'approche monolithique consistant à faire dériver chaque élément de la GUI d'une interface qui fait tout (sélections de trains et de gares, changements de vitesse, itinéraires, passagers dans les gares, etc) est trop limitée: non seulement cette interface mammouth couplerait tous les composants, mais cela veut dire que des centaines de fois par seconde, chaque train va envoyer sa nouvelle vitesse, chaque gare va envoyer son nouveau nombre de passagers, et bien d'autres événements vont être générés et envoyés à des boites de dialogue qui vont pour la plupart les ignorer.

Inspiré par une approche que j'ai vue au boulot (chut!), je vais tenter quelque chose de plus découplé: permettre à chaque composant de la GUI de s'enregistrer auprès d'un événement donné, en lui passant une fonction de callback, et gérer l'enregistrement dynamiquement au fur et à mesure des besoins de l'utilisateur. Ansi, l'utilisateur cliquant sur une gare, la boite de propriétés de la gare enregistre un callback directement sur un objet représentant le nombre de passagers. Lorsque ce nombre change, la boite de propriétés en est informée, et affiche la nouvelle valeur. Lorsque la gare est dé-sélectionnée, la boite de propriétés se dés-enregistre. Ainsi, pas d'interface monolithique, pas de couplage entre des événements indépendants, et, je l'espère, moins de code à gérer.

Openrailz tech demo 3 - La vidéo

Openrailz tech demo 3

Il a fallu franchement se battre avec les formats, mais enfin, la vidéo est là. L'on remarquera que le train à tendance à défier les lois de la physique avec ses demi-tours sur l'aile et ses démarrages et freinages au quart de tour, mais l'on a bien les fonctionnalités de base.

I've got the power!

Enfin, j'ai les trains bougeant de gare en gare!

Certes, c'est un petit peu bizarre par moments, les "demi-tours" dans les gares sont un poil irréalistes... Mais enfin, l'on peut contrôler le déplacement des trains à la souris, et voir le pathfinder en marche. Je vous poste une vidéo bientôt.

1000ème commit

Alors j'allais quand même sortir une jolie capture d'écran pour cette occasion! Voici donc un train en gare. La plus grande partie de la logique est implémentée, il ne reste plus qu'à ajouter quelques contrôles pour pouvoir indiquer au train où aller, et l'on devrait enfin pouvoir commencer à bouger.

Tests unitaires

Mais comment ai-je pu coder pendant des années sans tests unitaires? Ce truc, c'est LA pratique qui a augmenté mon rendement, m'a permis de mieux dormir la nuit, et m'a sauvé la vie (professionnelle, tout du moins) plus d'une fois.

Il y a quelques années, j'avais eu entre les mains un bouquin sur le développement orienté tests (le TTD, "Test Driven Development"), et j'avais douté leur déclaration qu'une fois touché aux tests unitaires, on ne pouvait plus s'en passer. Eh bien, ils avaient raison. Une fois utilisés correctement, les avantages sont tels qu'il devient évident que l'on ne peut vivre sans.

Cependant, utilisés à mauvais escient, ils peuvent faire plus de mal que de bien. Il y a donc quelques règles à garder à l'esprit quand on se lance à écrire du code.

• Les tests unitaires influencent le design. Il est rare qu'un bout de code quelconque, une fois atteint une complexité minimale, puisse être testé tel quel. Lorsque l'on sait que l'on va devoir tester le code, l'on tend à diminuer les effets de bord, à découpler ses routines, à écrire des interfaces afin de pouvoir "moquer" ses objets. Ça tombe bien, ce sont le genre d'habitudes qui améliorent la qualité du code!


• Corollaire du point précédent: il est généralement difficile d'ajouter des tests unitaires à un projet existant. Le projet dépend probablement de fichiers de configuration non moqués, force les logs vers un fichier, cause à la base de données, n'est pas séparé par bibliothèques indépendantes, dépend d'une GUI, dépend de l'horloge, écrit ses résultats dans un fichier Excel, etc. Demander tout à coup aux développeurs de "tester toute la codebase mais sans y toucher" est voué à l'échec. Pour approcher un gros projet non testé, il va falloir doucement, au fur et à mesure des nouvelles fonctionnalités ou des corrections de dysfonctionnements, tenter d'abstraire et de découpler pour pouvoir tester le changement. Au fur et à mesure que le code évolue, le nombre de tests augmente, et la qualité du produit avec.


• Il existe un point où la loi des rendements décroissants entre en ligne. À moins de coder pour la NASA ou autre cas où la qualité doit être absolue, l'abus de tests unitaires rend le code plus difficile à changer (car il risque de casser une batterie de tests). Le développeur peu scrupuleux (et, croyez le ou non, il y en a!), plutôt que de plonger dans les abîmes de la perplexité, se laisse aller à sa paresse naturelle et désactive les tests urticants. Avant peu, les 3/4 des tests ont été éliminés, et ne testent plus rien du tout (point bonus aux développeurs qui désactivent les tests en commentant l'intérieur de chaque routine, afin que leur forfait n'apparaisse pas dans les statistiques de chaque build).


• À contrario, l'utilité des tests augmente exponentiellement avec leur nombre. Quelques tests sur les fonctionnalités de base ne vont probablement jamais casser, et quand bien même un bug se serait glissé dans le code, il aurait été rapidement trouvé. Tandis qu'une batterie de tests sur les fonctionnalités centrales mais plus complexes vont trouver beaucoup plus de régressions. C'est pour cela qu'il peut être difficile de convaincre certains développeurs: n'ayant rien vu venir après avoir coder leur petite dizaine de tests, ils n'en voient pas l'intérêt. Il faut persévérer!

Le test, c'est comme le chocolat: un incomparable sentiment de plénitude lorsque la dose est bonne.

En voiture Simone

Je ne peux plus reculer, il n'y a plus d'échappatoire possible: la prochaine étape est vraiment de faire bouger les trains entre les gares. Pas mal de plomberie, et quelques soucis à résoudre (par exemple, je ne suis toujours pas sûr de la manière de faire faire demi-tour à mes trains...), avec je l'espère un résultat enfin visible bientôt!

Bonne année 2011!

En plus, cette année est un nombre premier, que demander de plus.

Bisous à toutes et à tous!