La plupart des entreprises n'ont pas les logiciels dont elles ont besoin pour faire efficacement leur boulot.
Pire, certains projets finissent à la poubelle faute d'avoir réussi à coder quelque chose qui correspond vraiment aux besoins.
La difficulté, c'est de traduire en code ce qu'un utilisateur veut. Ou plutôt ce dont il a besoin (ce n'est pas toujours exactement la même chose...).
Pour réduire cette distance entre le développeur et l'utilisateur, il existe plein de méthodes. Elles sont toutes un peu sur les mêmes principes :
- l'utilisateur et le développeur se parlent directement,
- ils utilisent un vocabulaire commun, pour être sûr d'appeler la même chose par un même nom sans ambigüité,
- le développeur livre tôt et régulièrement un truc qui fonctionne pour que l'utilisateur puisse immédiatement lui faire un retour, et éviter l'effet du tunnel qui débouche sur un précipice.
Et puis il y a aussi l'utilisateur-qui-développe-lui-même, avec des outils no-code par exemple. Ça marche tant qu'il est là. Ça explose quand il part (sur une autre fonction, dans une autre entreprise).
Mais il y a un moyen sous-utilisé de réduire la distance entre l'utilisateur (qui connaît son métier) et le développeur (qui sait coder) : le typage.
Exemple : j'ai oublié mon mot de passe
Michel, représentant officiel des utilisateurs, demande à Bill le codeur de développer une nouvelle fonctionnalité.
Michel : "Hey, Bill, il me faut un truc pour qu'un utilisateur puisse obtenir par mail un lien de ré-initialisation de son mot de passe.
Mais attention : on ne doit JAMAIS envoyer ce lien si l'adresse mail n'a pas été préalablement validée (question de sécurité)."
Sans typage, Bill pourrait écrire ça :
function reinitialisationMotPasse (utilisateur) {
if (utilisateur.adresseMailValidee === false) {
throw new Error("Impossible de réinitialiser le mot de passe avec une adresse mail non validée")
}
...
}
Bill le codeur a été vigilant. Il n'a pas oublié de vérifier la bonne validation de l'adresse.
Oui, mais c'est risqué.
Plus tard, on va migrer vers un nouveau système d'authentification. L'attribut "adresseMailValidee" va être renommé.
Le bug va surgir, car Bill n'aura plus en tête cette histoire d'adresse validée.
Comment Bill peut-il s'enlever cette règle de la liste des choses à penser ?
Avec du typage.
On va contraindre le code à ne PAS pouvoir représenter un état qui ne respecte pas cette règle.
Voici comment :
function reinitialisationMotPasse (
utilisateur : UtilisateurAvecEmailValidé
) {
...
}
Grâce au typage, j'ai pu dire :
la fonction reinitialisationMotPasse ne peut prendre qu'en paramètre d'entrée un utilisateur dont le type est "UtilisateurAvecEmailValidé".S'il existe quelque part dans le code un chemin qui tente d'appeler cette fonction sans avoir démontré que l'email était validé, l'erreur sera détectée.
Encore mieux : elle sera détectée dès qu'un développeur va taper la ligne contenant le code erroné.
Le typage a permit d'interdire d'écrire du code qui ne respecte pas une règle métier (un "invariant").
Avant même toute tentative de vouloir l'exécuter.
En bonus : de la lisibilité
Contrairement à ce que pensent beaucoup de développeurs, le typage consiste d'abord à annoter son code pour le contraindre à respecter des règles métiers.
C'est une façon de "formaliser" le besoin de façon utile, puisque ça alimente le code.
Ce permet de faire entrer un peu de Michel dans le code de Bill.
Alors ce n'est pas magique non plus, car la vérification des types disparaît parfois lors de l'exécution : les annotations ne figurent plus dans le code machine qui va être finalement exécuté par le CPU. Donc, il sera possible de contourner ces limitations après compilation.
Mais ça réduit beaucoup le risque de bug.
Et surtout : ça rend le code plus parlant.
La fonction reinitialisationMotPasse comporte peut-être 100 lignes de code.
Peu importe.
Pas besoin de les lire pour comprendre a prori ce qu'elle fait.
Il suffit de lire le type de la fonction pour comprendre l'intention du développeur, sans se farcir l'analyse de tout le code.
function reinitialisationMotPasse (
utilisateur : UtilisateurAvecEmailValidé
)
: Evenement<"email envoyé"> | EchecEnvoi
Ainsi, le typage n'a pas seulement amené de la fiabilité.
Il a aussi augmenté la lisibilité.
C'est un bon support de discussion entre les développeurs. Il permet de travailler sur les armatures principales du code, sans plonger directement dans les détails d'implémentations.
Les échanges techniques peuvent se maintenir dans le vocabulaire du métier. On parle de "validation de l'adresse mail", "paiement de la commande" plutôt que de contrôleurs, de persistance ou d'API.
L'équipe technique de Bill conserve de la hauteur de vue et s'imprègne du métier de Michel.
Peut-être qu'avec un peu moins de distance entre ces deux-là, on arrivera à déployer un logiciel qui apporte de la sérénité.
