Développeur c’est un métier, et un métier ça s’apprend

Faire un logiciel c’est un métier, et un métier ça s’apprend ! Il faut du temps pour l’apprendre. Notre métier ne consiste pas à pondre des vues, réaliser des contrôleurs pour écrire dans des bases de données, et résoudre des bugs au débogueur. Non, ce n’est rien de tout ça ! Notre métier consiste à traduire une idée en du code. Deux choses complètement différentes.

D’après mon dictionnaire, une idée est une représentation abstraite, élaborée par la pensée, permettant d’être à l’origine d’une œuvre ou d’une invention originale. Une idée change ! Elle évolue, elle mûrit. Pour faire correspondre mon code avec une idée, il va falloir en permanence le faire évoluer.

Pour exagérer la métaphore, faire un logiciel c’est un peu comme tenter d’intercepter un missile balistique en plein vol !

amélioration continue

image emmanuel chenu

Comme c’est quelque chose de difficile, on va essayer plusieurs fois, on ne va pas réussir du premier coup, mais on espère qu’à chaque tentative on va se rapprocher de l’objectif. Donc dans notre métier le plus important est de pouvoir changer son code pour qu’il se rapproche de la cible (refactoring) et de s’assurer que ce changement ne casse rien (tests).

Ces concepts impliquent plusieurs choses :

Les tests sont les éléments-clefs d’un bon logiciel. Ils permettent de donner un feedback immédiat sur ça marche, ou ça ne marche pas ! Le feedback immédiat ça implique une notion de temps. Lors du développement il est très important de savoir instantanément si ce que l’on est en train de réaliser ne casse pas ce que l’on a déjà produit. Donc ça sous-entend que l’on doit être capable de lancer les tests sur la machine de développement et pas d’attendre les résultats sur le serveur d’intégration continue.

Maintenant que tu as compris (j’espère) que les tests sont importants, parlons un peu des types de tests. On veut des tests rapides qui nous garantissent le bon fonctionnement de notre application, peu couplés au contexte. On appelle ça des tests unitaires. Tes tests selenium que tu préfères aux tests unitaires, ceux là, tu les abandonnes. Ils sont couteux en temps, et fortement couplés à ton interface. Chaque fois que tu modifies ton interface, tu dois modifier les tests, alors que le métier n’a pas forcement changé ! Par exemple tu réalises toujours le même appel à ton API, mais tu as modifié le workflow sur ta vue. En plus quand un test selenium casse, trouver l’origine du problème, c’est un peu comme chercher une fuite d’eau dans ta maison à travers le pommeau de douche! Le seul moment ou les tests selenium sont très utiles, c’est quand tu cherches à améliorer du code existant, sans test et dont les objets/fonctions sont privés et très peu accessibles.

Pour terminer quand est-ce que l’on doit réaliser les tests ? Les tests, il y a plusieurs façons de les réaliser, avant de réaliser le code de production, ou après le code de production. D’expérience, réaliser les tests après, prends plus de temps que les réaliser avant. Son code de production est souvent moins facilement testable quand il n’est pas pensé pour être testé. Les raccourcis pris pendant le développement entrainent un temps plus long pour faire les tests ! Si tu rajoutes à ça la pression sur les épaules des développeurs pour développer plus vite, généralement les tests disparaissent, laissant un code de production sans protection !

Le développement piloté par les tests (ou TDD), est une méthode pour écrire des tests avant de réaliser son code de production. En plus de garantir que les tests sont présents, il a une particularité très méconnue: il facilite l’émergence d’architecture. Très souvent je ne sais pas comment développer une fonctionnalité. Ça m’arrive très très souvent ! TDD m’oblige à avancer un pas après l’autre. Et donc je me retrouve à trouver une solution pour mon problème beaucoup plus facilement. Comme si la solution émergeait d’elle-même. Cette décomposition du problème complexe en petites briques plus simples à réaliser peut s’obtenir sans TDD. Mais cette émergence presque évidente d’une solution me laisse toujours pantois.

Maintenant je ne force personne à utiliser TDD. Je sais quel développeur je deviens grâce aux tests et au TDD.

Je me suis amélioré quand :

J’ose m’imaginer qu’un bon développeur, qui fait correctement son métier, est quelqu’un qui maitrise le refactoring et le design et réalise des tests.

Alors si toi aussi tu remercies des divinités obscures pour avoir créé TDD, git, les outils jetbrains et les frameworks de tests xUnit, partage ce billet !