Spiria logo.
Jimmy Lahaie
 
06 décembre 2013.

Les trois lois des... développeurs

J’ai lu le livre d’Asimov récemment et je me suis demandé ce que ces trois lois devraient être pour un promoteur… Voici ce que j’en pense : Un développeur n’écrira pas un code illisible, un code qui casse un logiciel ou qui, par inaction, permet au code de devenir désordonné. Un développeur doit répondre aux exigences données par le client, sauf si ces exigences entrent en conflit avec la première loi. Un développeur doit innover tant que cette innovation n’entre pas en conflit avec la première ou la deuxième loi.

J'ai lu le livre d'Asimov récemment et je me suis demandé ce que ces trois lois devraient être pour un promoteur.

Voici ce que je pense :

  1. Un développeur n'écrira pas un code illisible, un code qui casse un logiciel ou qui, par inaction, permet au code de devenir désordonné.
  2. Un développeur doit répondre aux exigences données par le client, sauf si ces exigences sont en conflit avec la première loi
  3. Un promoteur doit innover tant que cette innovation n'entre pas en conflit avec la première ou la deuxième loi.

Un peu plus de détails

Un développeur n'écrira pas un code illisible, un code qui casse un logiciel ou qui, par inaction, permet au code de devenir désordonné.

Nous ne devrions pas produire de bogue, c'est évident. Mais nous ne devons pas non plus écrire un code que seul l'auteur comprend. Lorsque vous écrivez du code, vous devez vous demander "Les développeurs qui m'entourent, seront-ils capables de comprendre cela ? La réponse devrait toujours être "Oui".

Et pour la dernière partie, lorsque vous mettez à jour un code qui n'est pas le vôtre, et que vous trouvez qu'il est très difficile à comprendre ou que vous trouvez même un bogue qui n'a pas été déposé, vous devriez corriger ce code. Ce sera bon pour vous et pour tout autre développeur qui devra faire de la maintenance sur cette partie du programme..

Le promoteur doit satisfaire à l'exigence donnée par le client, sauf si cette exigence est en conflit avec la première loi

Cela arrive tout le temps, un client veut une nouvelle fonctionnalité et c'est pour hier. Le problème, c'est que si vous commencez à écrire du code mal rangé et que vous vous dites "je le réparerai plus tard"... eh bien... il y a de fortes chances que vous ne le répariez pas plus tard. C'est pourquoi vous devez toujours respecter la première loi.

Vous devriez parler au client et lui demander quelle partie est vraiment importante ou s'il existe un moyen de simplifier l'exigence ou pourquoi c'est si urgent. Il y aura toujours un moyen de fournir les fonctionnalités demandées par le client sans précipiter votre code.

Un développeur doit innover tant que cette innovation n'entre pas en conflit avec la première ou la deuxième loi.

Il y a toujours place à l'amélioration. Que ce soit en apprenant un nouveau cadre, de nouveaux outils, de nouvelles bonnes pratiques, une nouvelle architecture, un nouveau langage... il y a beaucoup à apprendre. Vous pouvez également vous pencher sur votre dernier projet et vous demander "Comment pourrais-je mieux construire cela ?

Mais, lorsque vous travaillez pour un client, vous ne devez pas livrer une fonctionnalité qui n'est pas demandée par le client dans le seul but de la tester.

Je pense que lorsqu'on démarre un nouveau projet, il faut essayer de nouvelles choses, mais si cela prend trop de temps ou si cela ne fonctionne pas, il faut avoir un plan de secours dont on sait qu'il fonctionne et qu'il est facile à mettre en œuvre.

Dernière réflexion

Je ne sais pas si trois lois suffisent pour définir un développeur, mais il y a une chose dont je suis sûr... J'espère qu'ils ne seront jamais remplacés par des robots.

Partager l’article :