Il y a quelques temps, j'ai posté sur Twitter une boutade sous forme de diagramme.
À la réflexion, la situation, présentée comme une blague, n'est pourtant pas si éloignée de la réalité.
J'observe des évolutions dans la manière dont je travaille.
J'ai commencé à coder vers le lycée. À cette époque, et pendant plusieurs années, je me lançais dans l'écriture de code avant d'avoir réfléchi. À vrai dire, l'écriture me servait de processus de réflexion, et je ne savais pas vraiment ou je voulais en venir tant que je n'avais pas terminé d'écrire ma fonction.
Quand je rencontrais un bug, ou que mon code ne fonctionnait pas correctement, j'avais tendance à bidouiller « jusqu'à ce que ça marche », sans avoir de vraie compréhension du problème.
« Tiens, cette partie du programme ne fonctionne pas. Et si je modifie ça ? Et là ? Et comme ça ? »
Inutile de dire que d'un point de vue technique, le résultat obtenu n'était pas terrible.
Avec le temps, j'ai commencé à coder moins vite ; à chercher à mieux comprendre la problématique avant de la résoudre.
La pratique déterminante a été le passage au développement piloté par les tests (TDD). Écrire les tests d'une fonction avant d'écrire la fonction nécessite de sacrément bien réfléchir à ce que doit faire ou ne pas faire ladite fonction.
Avec une meilleure compréhension de ce qu'est un code fiable et maintenable dans le temps, il était également inévitable de passer plus de temps à refactoriser du code existant.
À ce moment là, je me suis aperçu que mon code était moins sujet aux bugs et comportements inattendus.
J'ai remarqué que cette évolution a continué jusqu'à aujourd'hui. Je ne suis pas précisément en fin de carrière, mais pas sans expérience non plus.
Maintenant, je suis tellement délicat avec mon code que je me fais l'impression d'être un vieillard tremblotant en train de choisir une tasse dans un magasin de porcelaine.
La moindre ligne nécessite un temps infini.
Il m'arrive parfois de passer une heure juste pour choisir un nom de variable approprié.
Je pense et repense à tous les cas de figures possibles, les cas d'erreurs, les logs, les exceptions, la performance, l'accessibilité, les conséquences à long terme, les impacts métiers, etc.
J'ai souvent entendu dire qu'il était rentable d'embaucher des devs seniors parce qu'ils pouvaient avoir 10x la productivité des juniors. J'y croyais. Mais chez moi, ça n'en prends pas le chemin. À vrai dire, je me sens 10x moins productifs aujourd'hui qu'avant.
J'ai parfois une légère tendance à succomber à la suringénieurisation.
Je ne dis pas que c'est une bonne chose.
Si je fais le point, je trouve que mon travail d'aujourd'hui est vraiment beaucoup plus robuste qu'il y a dix ans. Le code sans bug n'existe pas, mais je suis beaucoup moins souvent confronté à des comportements indésirables ou inattendus qu'auparavant. Étonnamment, une fois le code écrit, je ne refactorise plus tant que ça (en tout cas, moins qu'à une époque).
En contrepartie, je suis effaré par mon manque de productivité. Quand je travaille pour des clients, je m'étonne parfois de ne pas être pris pour un arnaqueur, tant il m'arrive de passer une journée à corriger un seul bug, à réaliser une seule petite fonctionnalité.
Je suis bien convaincu que cette façon de faire a une certaine valeur, mais j'ai l'impression d'être allé trop loin. Le déséquilibre qualité / productivité est trop important (le terme qualité étant à comprendre comme un terme technique, je ne m'envoie pas des fleurs).
Après tout, si d'un point de vue purement technique, il est impossible de faire de la sur-qualité, un projet, c'est aussi des contraintes temporelles, stratégiques, commerciales, économiques, etc.
Faut-il revenir à une écriture de code un peu moins pesante, quitte à refactoriser plus et plus souvent ?
Il est assez facile de reconnaître sa progression, mais plus difficile de déterminer quelle est la prochaine étape. Comment ma façon de travailler va-t-elle évoluer ? Qu'est-ce qui me ferait passer à l'étape d'après ? Je me pose sincèrement la question. Comment ça se passe chez vous ?