Après mon article sur le Framework CheckIt, j’ai voulu expliquer comment et avec quels outils j’ai créé ce projet.

J’ai choisi de le créer en TDD et de le rendre open source sur GitHub, ce qui m’a permis d’être agile. Je vous propose d’essayer de comprendre le pourquoi de ces choix et en quoi ils répondent au Manifeste Agile.

Le TDD c’est “Test Driven Design”. Oui et alors ?

Cela veut dire, en résumé, que l’on créé les tests avant le code. Concrètement, c’est tout de même un peu plus complexe.
Nous allons d’abord créer l’intention du test, c’est-à-dire réfléchir à ce que l’on veut ajouter comme fonctionnalité. Il convient d’écrire un nom de test qui permet de refléter ce que le code va faire.
A ce moment- là, le test ne fait rien, j’ai juste créé son intention. Il faut ensuite créer le corps du test, décrire ce que vous avez écrit dans le nom de celui-ci, créer les membres manquants… Bref, on se débrouille pour que cela compile. La création du test va influencer la façon d’écrire votre code. Ce que j’apprécie, c’est de ne plus réfléchir sur l’implémentation du code, mais plus sur ce que doit faire mon code.
A chaque fois que j’ai commencé à modifier mon code de manière assez lourde (Intégration de roslyn, changement de la logique…), je ne me suis pas préoccupé de la pertinence de celui-ci. Dans un premier temps, on remplace une classe par une autre, un constructeur par un autre. Puis on exécute les tests. Et le verdict tombe : 15 tests en erreur.
Pas de problème, j’archive mon code (je suis dans une branche à part). Puis, je prends le premier test. (NotImplementeException)
J’implémente la méthode. J’exécute tous les tests. Je suis dans un cas où l’ensemble de mes tests met moins de 2 secondes à s’exécuter. Du coup, peu importe le test qui remonte en premier, je corrige l’erreur. Et là, je vois la liste des tests diminuer rapidement.
L’avantage de cela, c’est de garantir que ce que j’avais écrit fonctionne toujours. Ainsi, je peux factoriser, changer le moteur d’analyse, … J’ai toujours le même comportement.
Pendant mes développements, je ne me suis pas posé la question : “Comment vais-je implémenter cela ?”, j’ai plutôt laissé faire les choses pour me concentrer sur ce que je voulais obtenir comme fonctionnalité.
Dans un second temps, j’ai eu un avis critique sur mon code. Ainsi, mon code se factorise maintenant et évolue dans le bon sens. Je me rends compte en travaillant le code qu’il y a des cas que je n’ai pas implémenté, ou pas testé. A moi d’ajouter des tests pour couvrir ceux-ci.
Avec le TDD, j’ai une documentation de mon code qui se créé toute seule. Et comme j’ajoute de petits incréments, j’ai toujours une application fonctionnelle. Je respecte une valeur de l’agilité : “Du logiciel qui fonctionne plus qu’une documentation exhaustive.”

Pourquoi GIT c’est bien ?

Je me suis créé une première branche en local pour intégrer Roslyn en parallèle du code existant. Ensuite, j’ai créé une autre branche pour changer la logique actuelle en utilisant ma nouvelle logique. J’ai, du coup, continué à ajouter mes fonctionnalités en parallèle de l’ajout de Roslyn pour remplacer le fonctionnement des load assemblies.
De base, je fais toujours une branche par fonctionnalité dans mes développements. Ainsi, ma branche master est toujours stable. Il m’arrive souvent de commencer un développement, d’arrêter le développement, de passer à autre chose et de revenir plus tard dessus. Dans ce cas là, mon code est archivé, en local, mais au moins cela me permet de passer à la suite. Le principe n’est pas nouveau avec git. C’est du branch features. Néanmoins, git facilite ce fonctionnement. Souvent, je commence le code dans la branche master. Si à ce moment-là je me rends compte que mon code n’est pas terminé ou que la fonctionnalité que je souhaite implémenter va me prendre plus de temps, je créé une branche et archive le code sur celle-ci.

Pourquoi GitHub

J’ai fait le choix de GIT comme contrôleur de code source, mais j’aurais pu choisir CodePlex ou un repos privé. Il s’agit avant tout de proposer ce Framework en open-source. Chacun peut s’en inspirer, le modifier, me proposer des modifications… C’est le gros avantage. On a un Framework ou une application qui va évoluer en fonction des envies des utilisateurs et non pas des développeurs. Vos utilisateurs vont avoir un œil critique sur votre Framework.
J’ai choisi GitHub pour plusieurs raisons. GitHub utilise le contrôleur de code source git. On peut créer des repos privés, transformer des repos publics en privés et vice versa. Github a une approche plus orientée code que projet. La première page que l’on voit le prouve puisqu’elle affiche les fichiers de l’application.
Il utilise MarkDown pour générer la page de garde, cette page même qui est sous contrôle de code source. Il possède également un wiki, un suivi des demandes de modifications… Bref, tout ce que l’on peut demander à un repos de code moderne.
Même si je ne vois pas mes clients, je peux suivre leurs demandes et interagir avec eux. Encore une fois, cela fait partie d’une valeur de l’agilité : “La collaboration avec les clients plus que la négociation contractuelle.”

Il y a beaucoup d’intégrations de GitHub avec des plateformes tierces. Exemple : MyGet qui permet de créer ses propres repos de package NuGet.

MyGet

Un petit mot pour vous parler de MyGet. C’est un repos de packages NuGet gratuit tant que vous faîtes des repos publics. Il dispose d’un serveur de build. Ainsi, mon code archivé dans GitHub sera automatiquement compilé, les T.U. seront exécutés… Je l’utilise comme un repos de continues delivery.
http://www.myget.com

Où je veux en venir ? En quoi je répond au Manifeste Agile ?

Pour résumer, j’ai utilisé deux gros patterns de développement : le TDD et le Branch Feature. Plus on utilise ce genre de pratiques de développement, plus votre modèle de développement sera agile. Ainsi, je peux modifier des bouts de codes entiers sans impacter la branche principale et sans bloquer les nouveautés ou les corrections de bugs. Pour le branch feature, git n’est pas indispensable, mais il apporte énormément de flexibilité. Malgré mon code en open source, j’ai tous les outils pour faire du continues delivery. A tout moment, je peux faire une livraison. Aujourd’hui, je suis sur un modèle à deux temps. Une build dîtes “non stable” est sujette à évoluer tous les jours tout comme un système de promotion d’un package qui peut passer de non stable à stable.

Sur ce projet perso, je respecte 3 des valeurs du Manifeste Agile :

  • Du logiciel qui fonctionne plus qu’une documentation exhaustive. Ma branche master fonctionne toujours et une documentation qui se créé grâce au TDD.
  • La collaboration avec les clients plus que la négociation contractuelle. Les demandes des utilisateurs seront intégrées par des “Pull requests” ou “Issues”
  • L’adaptation au changement plus que le suivi d’un plan. Je n’ai aucun plan fixe. J’ajoute des TU à chaque envie de fonctionnalités. Stable à stable.