Récemment, j’ai entendu un développeur tenir les propos suivants :
Non mais ça ne sert à rien de faire du bon code, tout ce que le client demande c’est que ça fonctionne.
Et malheureusement, sur la deuxième partie de l’assertion il n’a pas tort. Mais c’est parce que le client ne connait pas le métier et n’a aucune idée des répercussions sur le moyen/long terme d’un code de mauvaise qualité. Alors il faut que ça cesse !
Et si au lieu de profiter de la situation pour justifier du travail de sagouin, on en profitait plutôt pour prendre ses responsabilités ?
Être vraiment professionnel
Laissez-moi vous raconter une histoire :
Vous vous rendez à la boulangerie, ça sent bon le pain chaud, la baguette est bien dorée, croustillante à l’extérieur, moelleuse à l’intérieur, une véritable baguette 100% fonctionnelle. Vous en salivez déjà.
Et maintenant, si je vous raconte que j’ai surpris le boulanger la main dans le froc en train de se gratter l’anus pendant qu’il pétrissait la pâte. Toujours envie de vous en faire des tartines ?
Livrer une baguette seulement fonctionnelle est-ce vraiment tout ce qu’on demande à un artisan boulanger ? Non, on exige de lui qu’il prépare son pain dans les règles de l’art, en respectant les bonnes pratiques de son métier et en suivant scrupuleusement les règles sanitaires.
Si je vous raconte qu’en cette période de crise covid19, votre boulanger travaille sans porter de masque et en éternuant allégrement sur la pâte des croissants qu’il est en train de préparer. Vous voyez la scène ? Un gros ATCHOUM accompagné d’un feu d’artifice de postillons et de sécrétions nasales qui viennent se déposer gaiement un peu partout dans la pâte. Mmmm, un délice. Vous en pensez quoi ? Sérieusement ? C’est professionnel comme comportement ?
Ça vous dit un croissant totalement fonctionnel aromatisé à la crotte de nez ?
Bien entendu, vous avez parfaitement le droit de répondre oui et de trouver que c’est normal de travailler comme ça tout en prétendant être un professionnel du métier. Mais je n’irai pas manger chez vous ni vous recommander auprès de mes clients !
Parce qu’un produit fonctionnel, c’est juste le B-A-BA, c’est le niveau zéro du métier. C’est ce qu’on demande de produire à un étudiant pour son projet de première année. Juste un truc qui marche. Mais être professionnel, c’est un peu plus que ça non ? Non !?
Artisan développeur
Bien entendu, je ne prétends pas que tout est toujours parfait, peut-être le boulanger va-t-il y laisser un poil de bras ou une goutte de sueur. On ne peut pas tout prévoir, on n’est pas toujours au top. Parfois aussi on se trompe, c’est humain. Je vous le dis discrètement, ça reste entre nous, mais on n’a pas non plus la science infuse. Parfois on ne sait pas bien faire et on aurait pu faire mieux.
Alors quoi ?
Alors, on prend soin de respecter au mieux les bonnes pratiques, on se forme, on s’exerce, on ne se cache pas derrière un de toute façon le client attend juste que ça fonctionne. On se comporte comme un véritable artisan du code.
C’est-à-dire que s’il y a des bugs, c’est accidentel. Si le code lève une exception, c’est parce qu’on a rencontré un cas exceptionnel (le terme d’exception n’a pas été choisi par hasard).
Un bug issu de l’erreur humaine est acceptable. Un bug issu de non mais ce n’est pas la peine de coder proprement il suffit juste que ça fonctionne est juste inacceptable. Vous saisissez la nuance ?
Autrement dit, on évite autant que possible d’éternuer sur le clavier et de laisser des crottes de nez partout dans le code.
C’est quoi une crotte de nez dans le code ? Il est où le problème ?
Je pourrais écrire une thèse sur le sujet mais, que vous soyez développeur ou que vous ayez un projet de développement, je vous recommande plutôt la lecture du fantastique The Pragmatic Programmer, from journeyman to master de Andrew Hunt et David Thomas.
Ce livre qui date de plus d’une vingtaine d’années reste complètement d’actualité tant les thèmes qu’il aborde sont tranverses au développement informatique et se basent avant tout sur les bonnes pratiques et surtout les risques de ne pas les suivre.
Vous y apprendrez par exemple pourquoi en vertu de l’hypothèse de la vitre brisée, si un développeur laisse traîner quelques crottes de nez par-ci par-là, le code finira irrémédiablement recouvert de sécrétions nasales.
Et en informatique, une crotte de nez peut avoir des répercussions graves.
En fait, une crotte de nez dans le code, c’est ce truc-là, qu’on ne voit pas de l’extérieur, qui ne semble pas influer sur le fonctionnel du point de vue de l’utilisateur mais qui, dans certains cas, laisse un arrière-goût plutôt désagréable.
Comme oublier de crypter des mots de passe. Je veux dire, au niveau du code, ce n’est pas grand-chose, hein (ah si ?). On oublie juste de passer le mot de passe dans la moulinette, rien de très grave en soit, personne ne s’en rend compte, tout est parfaitement fonctionnel. Et puis, un beau jour, c’est le scandale…
- Facebook stockait des millions de mot de passe instagram en clair
- Petite crotte de nez chez Google : des mots de passe stockés en clair pendant des années
J’ai une autre anecdote sympa, c’est cocasse vous allez voir. J’ai assisté à une scène surréaliste ou un développeur a voulu montrer à un opérateur comment supprimer des données dans la base clients. Jusque-là, rien de dramatique, on manipule des données, on les insère, on les modifie, on les supprime, c’est la raison d’être des bases de données.
Sauf qu’il a, par mégarde, sélectionné l’ensemble des données d’une table. Et que cette table avait une relation directe ou indirecte avec l’ensemble de toutes les autres tables de la base de données.
Vous voyez le coup venir ? Une crise d’éternuement en approche !
Dans le meilleur des mondes, il aurait dû y avoir une boite de dialogue de confirmation de suppression au niveau applicatif. Il aurait dû y avoir un contrôle au niveau de la base de données, en particulier sur une table critique comme celle-ci.
Mais voilà, la boite de dialogue est restée engluée dans une flaque de morve et la base de donnée a supprimé toutes les données en cascade sans broncher.
Quand le développeur a demandé, l’espoir dans l’âme, Ce n’est rien, nous allons restaurer les données, vous avez bien une sauvegarde récente ?, l’opérateur a constaté que les scripts de sauvegarde ne tournaient plus depuis des semaines, sans envoyer les messages d’avertissement prévus dans ce cas. La faute à une crotte de nez. Encore.
Conclusion
Être professionnel, ce n’est pas seulement produire du code fonctionnel, c’est aussi garantir une qualité , une pérennité , une évolutivité du code. C’est-à-dire un code qui fonctionne aujourd’hui et continuera de fonctionner demain, même après modification.
Je pourrais également parler de stabilité (ça fonctionne mais c’est un peu bancal), de fiabilité (ça fonctionne très bien… quand ça fonctionne), ou de performance (ça fonctionne mais il faut être patient, très patient).
Ou encore, insister sur la lisibilité d’un code que d’autres développeurs n’auront pas de mal à lire et à comprendre. D’un code qui coule de source (ah ah ah) dans lequel les autres n’auront pas peur de mettre les mains. J’ai failli dire les doigts… dans le nez, bien entendu.
Code toujours comme si la personne qui va maintenir ton code est un violent psychopathe qui sait où tu habites.
John F. Woods
Alors évidemment, comme je l’ai dit, on ne pas toujours être au top, on va parfois laisser quelques gouttes de sueurs perler dans la farine, le pain sera un peu moins cuit ou la pâte moins croustillante que d’habitude. C’est comme ça, c’est la vie.
Mais s’il vous plait, cessez de vous gratter le cul ou de vous curer le nez en bossant sous prétexte que ça ne va pas se voir !
Top comments (0)