Le serment du programmeur – Traduction du “Programmer’s Oath” Par Uncle Bob

serment-du-programmeur

Considérant l’importance du métier du développement logiciel, Robert C. Martin (Uncle Bob) vient de proposer un “Serment du Programmeur”, comme l’ont les autres professions. Se concentrant encore une fois sur les bonnes pratiques et la qualité du code, Uncle Bob propose 9 règles que chaque programmeur doit prendre afin de “défendre et préserver l’honneur de la profession”. Voici une traduction personnelle du Serment – L’original est accessible ici (The programmer Oath) :

  1. Je ne produirai jamais du code nuisible
  2. Le code que je produirai sera toujours mon meilleur travail. Je ne livrerai jamais, consciemment, du code défectif que ce soit au niveau du comportement ou de la structure.
  3. Je produirai, avec chaque livraison, une preuve rapide, sûre, et répétable que chaque élément du code fonctionne comme il se doit.
  4. Je livrerai mon code par petits bout, fréquemment, de sorte que je ne gênerai pas le progrès des mes collègues.
  5. À chaque occasion,j’améliorerai le code sans crainte et sans relâche. Je ne rendrai jamais le code plus mauvais.
  6. Je ferai tout ce que je peux pour maintenir ma productivité et celle des autres au plus haut niveau possible. Je ne ferai rien qui diminuerait la productivité.
  7. Je veillerai continuellement que les autres peuvent me soutenir, et que je les soutiendrai.
  8. Je produirai des estimés honnêtes en terme de grandeur et de précision. Je ne ferai jamais des promesses incertaines.
  9. Je n’arrêterai jamais d’apprendre et de m’améliorer dans mon métier.

Ce serment a déclenché beaucoup de réactions, entre autres Ron Jeffries qui a publié deux articles  The programmer’s Oath et more on the programmer’s Oath.

Et vous, quel est votre avis? Quels points font plus de sens que d’autres pour vous? Je suis intéressé à discuter avec vous la dessus!

Anis Berejeb

Anis est avant tout un passioné de l'agilité et du développement. Avec plus de 15 ans dans le domaine du développement web, son expertise combine des connaissances accrues dans l'ensemble des notions partant du développement logiciel jusqu'à l'organisation des équipes dans les environnements agiles à grande échelle.

You may also like...

2 Responses

  1. Chantal dit :

    Ici alors et merci d’avoir fait l’effort de traduire, c’est toujours un exercise délicat!

    Je crois que c’est une idée intéressante d’avoir un serment – ceci dit, est-ce qu’il s’agit plus de règles à suivre ou d’objectifs à atteindre?

    Je pense à ce que Ron Jeffries écrivait sur le point 1 (ne pas produire de code nuisible): il a déjà fait du code pour la défense nationale. Code qui pouvait être utilisé pour lancer des bombes. Wow. Au delà des objections morales – je crois qu’il faut surtout comprendre le premier élément comme étant “ne pas produire du code nuisible au système”. Donc oui, je peux adopter le point 1 (ça reste mon problème après si je choisi de travailler dans une industrie qui ne respecte pas ma morale).

    Pour l’élément 2, d’accord, ça me semble être pas mal la base de tout, non? Produire du code qu’on sait minable et pas à la hauteur de nos capacités, c’est presque du sabotage…

    Élément 3: en d’autre mots, faire du code et un système testable. Ici non plus je ne suis pas entièrement d’accord avec Ron Jeffries. Si la seule façon de tester c’est de le faire manuellement, c’est comme ça qu’on teste et c’est valable. Il faut juste documenter comment faire le test manuellement pour pouvoir le répéter.

    Élément 4: rien à redire

    Élément 5: c’est ce que je trouve le plus dur à faire. Oser modifier le code sans avoir des bretelles, une ceinture, du duct tape et un ou deux harnais de sécurité. Pour moi, c’est un objectif à atteindre… Aussi, faut noter que “rendre le code plus mauvais” ça peut être très subjectif.

    Les points 6 et 7 font directement référence au travail d’équipe. Bonne idée. Le point 7 vient ajouter à cette notion en disant qu’il faut informer les autres qu’on a besoin de soutient. Heureusement que ce n’est pas notre responsabilité de deviner ce que les autres pensent. Ceci dit, pour que ça fonctionne, ça prend une bonne dynamique d’équipe: chaque membre de l’équipe doit savoir qu’il est suffisamment en sécurité dans son équipe pour pouvoir exprimer ses idées et opinions. On pourrait créer un “serment de l’équipier agile” pour renforcer cette idée :)

    Point 8: arghhhh je déteste les estimés :)

    Point 9: ça devrait peut-être être le point 1?

    My 2 cents :P

  2. Anis Berejeb dit :

    Merci Chantal! Pour le point 9, à mon avis c’est que Uncle Bob veut mettre l’emphase sur la qualité plus que sur l’apprentissage :-)

Laisser un commentaire