Robert C. Martin disait :

Nous ravirons nos clients en écrivant le meilleur code possible

Dans notre article précédent, nous nous disions que nous nous sentirions plus à l’aise avec une phrase qui ressemblerait davantage à ceci :

Nous ravirons nos clients en écrivant le code de la façon la plus efficiente possible

L’efficience c’est la recherche de l’efficacité finale mais surtout de l’efficacité dans la manière d’y parvenir. Il s’agit de mettre l’accent sur l’optimisation de ce que nous faisons. C’est un concept central dans la production Lean : l’idée de faire au plus juste. Nous parlons alors de ce que nous devons faire, mais aussi de comment nous devons le faire.

Nous sommes une entreprise d’e-commerce. Notre but est de proposer la meilleure offre de produits possible en les expédiant le plus vite possible. Au niveau informatique, cela implique que nous devons nous poser chaque jour la question de savoir ce que nous pouvons faire de mieux pour y contribuer. Nos clients se moquent de savoir si nous faisons le meilleur code possible. Ce qu’ils veulent c’est avoir le meilleur service possible en payant le moins cher possible.

A nous de juger à chaque fois que nous écrivons du code, du niveau d’exigence avec lequel nous devons produire et donc de l’énergie que nous employons :

• Si nous travaillons sur un outil interne qui affiche les ventes de nos produits, nous pouvons tolérer que des pannes se produisent, et si l’utilisateur en est informé, que les données utilisées ne soient pas consolidées ou que la concurrence d’accès ne soit pas parfaitement gérée.
• Si nous travaillons sur un projet qui a peu de chance d’évoluer, ne passons pas trop de temps à le refactoriser pour le rendre parfaitement lisible ou facilement maintenable. Si malgré tout il s’avère un jour qu’il faille le faire évoluer, nous passerons le temps nécessaire à ce moment là.
• Si nous travaillons sur la migration dans le cloud d’un vieux script solitaire qui a fait ses preuves, contentons-nous de l’adapter pour qu’il fonctionne. Ne perdons pas de temps à le réécrire avec les dernières technos à la mode. Nous le ferons quand nous en aurons vraiment besoin.
• Par contre, si nous travaillons sur une API qui est sollicitée en permanence par les fronts de nos sites web et qui calcule le délais de livraison des commandes de nos clients, la défaillance est inenvisageable et nous devons nous donner tous les moyens pour produire un code très réactif et très robuste. C’est un cas où nous devons écrire le meilleur code possible.

La bonne nouvelle c’est que même quand nous travaillons sur un projet qui n’est pas critique, nous avons la possibilité d’appliquer de nombreuses bonnes pratiques de Clean Code qui vont nous faire gagner en efficience : KISS, DRY, YAGNI, SOLID, nommage des variables, nommage des fonctions, etc.

Les domaines où l’on va devoir ajuster nos efforts concernent les tests unitaires, le temps de refactoring, le degré d’encapsulation, le degré de SOC (Separation Of Concerns), la réduction des paramètres des fonctions, etc.