Je vois parfois passer des annonces de jobs exigeant “minimum 10 années d'expériences en langage ___ ou sur le framework ___ ”.
Mais ce n’est pas tant l’expertise technique qui est recherchée. C’est surtout le vécu sur des projets comparables. C’est la capacité à trouver des marges de manoeuvre parmi toutes les contraintes imposées (délai, budget, périmètre fonctionnel).
Cette vidéo illustre bien cette idée. Un dessinateur (visiblement expérimenté) s’impose 3 délais prédéfinis pour un même dessin : 10 minutes, 1 minute et … 10 secondes !
Dans tous les cas, on obtient à la fin un dessin qui correspond à ce qui était demandé (“la tête de spiderman”).
Evidemment, ce qui change beaucoup, c’est la qualité du dessin.
Et bien c’est pareil pour la conception de logiciels.
La qualité, un concept dépassé.
Disons-le tout net : la qualité du code, tout le monde s'en fout. Car contrairement au dessin, ça ne se voit pas.
Le concensus général est plutôt : “peu importe la méthode pourvu que ça marche”.
Au moins au début. Mais ça peut vite devenir une décision que l’on regrette.
Car un logiciel est vivant. Contrairement à une peinture que l’on ne retouche plus une fois terminée, un logiciel évolue constamment sous l'influence :
- de l'ajout de nouvelles fonctionnalités,
- de la mise à jour des composants et des services dont il dépend,
- de la détection de bugs.
Pour lui éviter de sombrer prématurément, un logiciel gagne à être conçu avec un bon niveau de qualité.
Mais comment mesurer objectivement cette qualité ?
Il existe quelques tentatives pour élaborer des métriques. Je ne les trouve pas très convaincantes, et certaines conduisent à une conclusion erronée.
Par exemple : le nombre de commentaires dans le code. Plus il y en a, et mieux c'est ? Au contraire ! Certains considèrent que les commentaires compensent un mauvais nommage ou un mauvais niveau d'abstraction.
Alors si la mesure est difficile, comment améliorer la qualité dans un projet tech/data ?
Choisir une méthode
Ma conviction est que la qualité est d’abord conditionnée par la méthode. La façon de faire.
Ce ne sont pas les méthode de projets qui manquent : Agile, PERT, Lean, Scrum (bon j'arrête là, on en recense une vingtaine à ce jour). Pourtant aucune de ces méthodes n'entre dans le détail de la production du code.
En cotoyant des personnes expérimentées dans le domaine de la tech, je constate qu'avec le temps elles se sont dotées d'un éventail de méthodes personnelles.
Il ne s'agit pas de recettes miracles. Ce sont plutôt des stratégies qui vont permettre d’adapter sa façon de faire au contexte pour produire ce qui est attendu.
Voici 2 exemples de méthodes possibles pour coder un logiciel.
Quelle est celle qui va permettre de produire ce qui est attendu le plus rapidement ? Aboutir à une meilleure qualité de code ?
"Malaxer le code" signifie le ré-écrire partiellement pour en optimiser ses performances, sa modularité, sa compréhension.
En pratique, les 2 méthodes vont aboutir. La #1 sans doute plus rapidement.
Mais avec 2 niveaux de qualité différents : la réalisation des tests en parallèle du code dans la stratégie #2 amènera davantage de qualité.
Choisir ou placer sa marge de manoeuvre
En fixant fermement les contraintes de délai, de budget ou de périmètre fonctionnel, vous ne vous laissez pas d'autre marge de manoeuvre que le niveau de qualité.
Ce n'est pas toujours un mauvais choix.
Pour la réalisation d'une maquette ou d'un prototype, on peut accepter une exigence faible sur la qualité.
En revanche, pour un logiciel destiné à la mise en production, mieux vaut probablement réduire le nombre de fonctionnalités que d'appauvrir la qualité.
Dans tous les cas, choisissez par vous-même la contrainte que vous accepter d’assouplir plutôt que de la subir.
