Pour ceux qui ne connaissent pas Robert C. Martin alias "Uncle Bob", voici le personnage.

Uncle Bob (photo Tim-bezhashvyly 2015)

Qu'est-ce que c'est, qu'est-ce qu'il a, qui c'est celui-là ?

Uncle Bob fait partie des rares OVNI qui ait participé à autant d'éléments qui aient marqué le monde du développement logiciel avec

  • Le Manifeste Agile [1]
  • Le Software Craftsmanship [2][3]
  • Les Principes SOLID [4]
  • Les 3 lois du TDD [5]
  • Le Serment du Développeur [6]

Sa démarche

Uncle Bob fait quelques constats qui reviennent régulièrement dans ses conférences.

Nombre croissant de développeurs

Voici quelques chiffres qu'il avance [7] :

  • 1945-1946 : une petite dizaine autour de Alan Turing [8]
  • 1960 : quelques centaines d'ordinateurs et quelques milliers de développeurs - il étaient matures (30 ans et plus)
  • 1965 : quelques dizaines de milliers d'ordinateurs et centaines de milliers de développeurs
    • il n'y avait pas de diplômes en informatique mais des gens qui se sentaient la fibre et avaient déjà de l'expérience
    • IBM connait un pic de production en 1966 (jusqu'à plus de 1000 machines "IBM 360" [9] par mois - il s'est vendu 14 000 unités en 13 ans)
  • 1970 : des centaines de milliers d'ordinateurs dans le monde et quelques millions de développeurs - principalement des hommes [10] ! La domination masculine arrive dans un milieu qui était principalement féminin. Robert C. Martin explique qu'avant cela, coder était assimilé à de la dactylographie et n'intéressait pas les mâles qui préféraient le Hardware, ce que l'on peut apercevoir dans le film "Les figures de l'ombre" [11] [12].
  • 1980 : moyenne d'âge des programmeurs 20-30 ans - ratio homme/femme : 50/3 constaté par Uncle Bob, mais des chiffres plus officiels indiquent une chute de 34% dans les années 80 à 16.5% en 2010 [13].
  • 1995 : Uncle Bob évalue la population des développeurs à quelques dizaines de millions.
  • 2015 : Il y aurait plus d'une centaine de millions de développeurs selon Uncle Bob [7] (il y en aurait plutôt 21M en 2018 et 25M en 2025 et seulement 3% de femmes [14] et d'autres estimations prévoient que l'Inde dépasserait les 110M sur les prochaines décennies [15]).

Même si Uncle Bob sur-estimait la croissance explosive (la population doublerait tous les 5 ans), la question de la montée en compétence reste valide : comment les millions de jeunes développeurs (inexpérimentés) prévus sur les prochaines années vont-ils assurer une bonne qualité de code ?

Le problème est que les jeune-hommes ont plein d'énergie mais pas trop de discipline. Ils peuvent travailler de longues heures durant, pas forcément sur les objectifs attendus, en revanche ils sont (étaient ?) peu chers !

Les premières réflexions du premier véritable développeur au monde laissent à réfléchir :

<< Une de nos difficultés sera la maintenance au niveau approprié de discipline afin de ne pas perdre la trace de ce que nous faisons >>

Alan Turing 1945 [16]

Méthodes de travail - l'Agile avant le Waterfall

Uncle Bob rappelle les méthodes de travail des "Grands Anciens" :

  • à la NASA, les développeurs faisaient des itérations des 6 semaines [7]
  • les développeurs du programme Mercury [17] écrivaient les tests unitaires le matin et avaient le code qui passaient des tests dans l'après-midi [7]

Pour canaliser la horde de développeurs inexpérimentés, les Managers ont voulu industrialiser les méthodes de travail... En 1970, Winston W. Royce a proposé un point de vue personnel sur une approche pour faire face à la masse de développeurs qui arrivaient. Il proposait ainsi une première tentative de ce qui s'appellera par la suite le modèle en cascade ("Waterfall") en précisant que "cette description est risquée et laisse la porte ouverte à l'échec" [18]... 8^ [_]

"Etapes d'implémentation pour développer un logiciel de taille conséquente à destination d'un client" - Royce, Winston (1970)

Malheureusement, seul le schéma du waterfall a été retenu et reproduit, en oubliant la note qui est pourtant écrite juste en dessous du graphique (surligné en jaune sur la figure ci-dessus).

Quand en 2001, il a cosigné ce célébrissime Manifeste Agile [1] c'était pour mettre fin à 30 années d’absurdités institutionnalisées par le Management [7].

Le Software Craftsmanship

Pour Uncle Bob, l'analyse est simple à faire. La quantité de développeur croit de façon folle pour répondre à une demande vers laquelle l'humanité s'engouffre. Il y a des processeurs et du code tout autour de nous et vu la jeunesse moyenne des codeurs et les styles de vies que l'on connait, on peut souvent se douter que le code qu'on utilise a été fait à 2h du matin avec une boisson énergétique dans les veines et du heavy metal entre les oreilles...Statistiquement, du code va finir par tuer quelqu'un (si ce n'est déjà fait) et la faute va retomber sur les épaules de notre codeur plein de testostérone et de bonne volonté : rappelons-nous l'affaire de Volkswagen (le Dieselgate) qui a été prise la main dans le sac pour avoir triché sur les chiffres sur la pollution de ses véhicules [19]. Quelle fut l'attitude du CEO de VW Michael Horn ? "C'est la faute de ces développeurs !" [20]. Officiellement, ce sont ces gars qui auraient (intentionnellement ?) mis du code frauduleux en production.

Qui n'a pas déjà vu les conditions de mise en production où un "Manager" pousse les mises en production sous la pression de l'organisation et des actionnaires ? Quand tout un système se ligue pour obtenir quelque chose dont il ne saurait être tenu pour responsable, il n'est pas simple de s'opposer et dire NON !

Il est évident qu'un développeur devrait être fier de ce qu'il a réalisé avec une façon de travailler dont il peut aussi être fier, un peu comme un artisan. Ce sentiment peut aussi être renforcé par l'équipe toute entière qui crée alors un sentiment de confiance avec comme objectif un rapprochement entre la technique et le métier (du Client) [21].

Telle est l'idée du Software Craftsmanship (SC) et pour Robert C. Martin, le SC est la conséquence inévitable de l'agilité et en tant que cosignataire du manifeste, il a même proposé une 5eme valeur "Craftsmanship over Execution" (" l'Artisanat avant l'exécution ") [22].

Les Principes SOLID

C'est une liste de 5 principes [23] que Bob a identifié en 2000, d'abord sous le sigle "SOLDI" avant que Michael Feathers ne vienne lui proposer la version actuelle "SOLID"[24] [25]. Ces principes de conception pour les langages orientés objet. Ces principes apportent une ligne directrice permettant le développement de logiciel plus fiable et plus robuste [26].

Les 3 lois du TDD

Afin de ne livrer que du code qui soit fiable, Uncle Bob a imaginé une approche du TDD [27] [28]

  1. Loi no 1 : "Vous ne pouvez pas écrire un code de production tant que vous n'avez pas écrit un test unitaire qui échoue."
  2. Loi no 2 : "Vous ne pouvez pas écrire plus d'un test unitaire que nécessaire pour échouer, et ne pas compiler revient à échouer."
  3. Loi no 3 : "Vous ne pouvez pas écrire plus de code de production que nécessaire pour que le test actuellement en échec réussisse."

Le Serment du Développeur

Pour concrétiser la prise de conscience de la communauté des développeurs et éviter qu'un jour un code de mauvaise qualité ne vienne tuer quelqu'un ou polluer la planète, Uncle Bob a proposé un Serment du Développeur, un peu comme celui d'Hippocrate pour les Médecins [21] [29]:

  1. Je ne produirai pas de code dangereux.
  2. Le code que je produis sera toujours mon meilleur travail. Je ne déploierai pas sciemment de code défectueux dans son comportement ou sa structure.
  3. Je produirai, avec chaque release, une preuve rapide et répétable que chaque élément du code fonctionne comme il devrait.
  4. Je ferai des releases fréquentes et petites afin de ne pas gêner l'avancée de tiers.
  5. J'améliorerai sans peur et sans relâche le code à chaque opportunité. Je ne dégraderai jamais la qualité du code.
  6. Je ferai tout ce que je peux pour conserver ma productivité et celle des autres aussi haute que possible. Je ne ferai rien qui abaisse cette productivité.
  7. Je m'assurerai constamment que les autres peuvent me couvrir et que je peux les couvrir.
  8. Je produirai des estimations qui sont honnêtes, à la fois en échelle et en précision. Je ne ferai pas de promesses sans être certain.
  9. Je ne cesserai jamais d'apprendre et d'améliorer mon art.

Shu-Ha-Ri Bob

En 2014, David Heinemeier Hansson, le créateur de Ruby on Rails, est venu proclamer que le TDD était mort [30]. Un sacrilège ? Ca a été l'opinion de certains et de l'encre a coulé [31]...

Kent Beck (l'inventeur du TDD, cosignataire du Manifeste et inventeur de la méthode XP [32] dont les pratiques se sont développées jusque dans le DevOps [33]) et a lui-même proposé une approche plus dure que le TDD avec le TCR (Test && Commit || Revert) [34].

Il est de l'ordre naturel des choses de voir les fondamentaux se faire dépasser, c'est le modèle Shu-Ha-Ri [35] qui fait qu'une tradition finit par être transgressée pour être dépassée, mais il semble que le TDD soit toujours convoité par les Développeurs qui encore aujourd'hui éprouvent encore de la peine à faire leur tests unitaires avec deux phénomènes concomitants :

  • le (mauvais) développeur ne voit pas l'intérêt et n'en n'a pas l'envie
  • la pression du PO (ou du Chef de projet) sert d'excuse pour ne pas en faire

Les mimiques et railleries (à la limite de l'enfantillage par moment [36]) de Bobby peuvent venir desservir son message, mais la position du Craftsmanship reste vraie, l'agile et le DevOps renforcent le trait.

Quel est l'apport de Uncle Bob pour le Test ?

Dans un article précédent qui traite de la gestion du patrimoine, il était déjà question de réutiliser les principes SOLID pour avoir des tests structures de façon efficaces entre eux (voir Miserere nobis patrimonium - Ayions pitié de notre patrimoine). Cependant, ce n'est pas l'apport le plus important qui est en filigrane sur ce personnage et qui en fait un apport pertinent sur le test.

Ce n'est pas non plus l'application des avancées dans les techniques de développement qu'il faut appliquer aux scripts de test, car même si on prend conscience que

  • le code généré pour automatiser ses tests doit être SOLID avec une approche de type TDD pour assurer qu'un script soit robuste et maintenable comme c'est le cas avec le design pattern PageObject [37] voire ScreenPlay qui est la version SOLID de PageObject [38] [39]
  • le concept des Katas du Software Craftsmanship [40] porté aux scripts de test [41] [42] permet de résoudre plus rapidement une situation par une habitude assimilée un peu comme un étudiant s'exercerait avec les anales d'un concours pour être plus efficace de le jour de l'examen

le vrai point adressé par Uncle Bob pour les tests est de donner aux Testeurs des outils qu'il pourra communiquer aux développeurs autour de lui, car un code de bonne qualité donnera

  • moins de bugs fonctionnels car l'approche TDD aura vérifié les principales conditions unitaires
  • un meilleur potentiel de testabilité car la structure SOLID permettra de bouchonner et de sonder plus facilement un comportement interne

Cette approche qui privilégie un code de grande qualité est incontournable car on ne pense pas toujours à ce genre d'atouts pour une stratégie de test de type "Tester tôt" ("Shift Left") [43]. On notera que la situation est encore pire avec une approche DevOps où tous les développeurs travaillent sur la même branche et dont le code part en production par la magie de l'intégration et déploiement continus [2]. Un empilement de code de mauvaise qualité ne peut pas donner un produit de bonne qualité [44] :

<< You can't scale crappy code >>

ou comme l'a crié Uncle Bob lors de la Keynote Agile2008 [45] [22] :

<< Craftsmanship over crap! >>

Le Testeur peut posséder et se doit de porter haut dans l'équipe ce genre de valeurs si aucune autre personne dans l'équipe ne sait les porter. Il peut être celui qui coache les codeurs et crée une émulation pour améliorer leur Artisanat plutôt que de chercher des bugs. C'est ce genre de profil qui fera demain la différence avec un Testeur procédurier et peu inventif qui ne fera que répéter la cérémonie d'une campagne de test bien établie qu'un robot remplacera tôt ou tard...

Références

  1. 1,0 et 1,1 http://agilemanifesto.org/iso/fr/manifesto.html
  2. 2,0 et 2,1 Christophe Moustier - "Le test en mode Agile" - ENI - 2019 - ISBN 978-2409019432 - https://tinyurl.com/testagile-amazon
  3. https://fr.wikipedia.org/wiki/Software_craftsmanship
  4. https://fr.wikipedia.org/wiki/SOLID_(informatique)
  5. https://www.youtube.com/watch?v=qkblc5WRn-U&t=55s
  6. http://blog.cleancoder.com/uncle-bob/2015/11/18/TheProgrammersOath.html
  7. 7,0 7,1 7,2 7,3 et 7,4 https://www.youtube.com/watch?v=ecIWPzGEbFc
  8. https://fr.wikipedia.org/wiki/Alan_Turing
  9. https://fr.wikipedia.org/wiki/IBM_360_et_370
  10. https://en.wikipedia.org/wiki/Women_in_computing
  11. https://www.youtube.com/watch?v=bptcvhup36o
  12. https://fr.wikipedia.org/wiki/Dorothy_Vaughan
  13. https://jaxenter.com/women-in-computer-science-majors-133646.html
  14. https://www.quora.com/How-many-software-developers-are-there-in-the-world
  15. https://www.computerworld.com/article/2483690/india-to-overtake-u-s--on-number-of-developers-by-2017.html
  16. B. Jack. Copeland - "The Essential Turing" - Clarendon Press, 9 sept. 2004 - ISBN 978-0198250807
  17. https://fr.wikipedia.org/wiki/Programme_Mercury
  18. Royce, Winston (1970) - "Managing the Development of Large Software Systems" - Proceedings of IEEE WESCON, 26 (August) - http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
  19. https://fr.wikipedia.org/wiki/Affaire_Volkswagen
  20. https://blog.cleancoder.com/uncle-bob/2015/10/14/VW.html
  21. 21,0 et 21,1 Robert C. Martin - "The Craftsman's Oath" - SCLConf 2018 - https://www.youtube.com/watch?v=17vTLSkXTOo
  22. 22,0 et 22,1 https://www.infoq.com/news/2008/08/manifesto-fifth-craftsmanship/
  23. https://fr.wikipedia.org/wiki/SOLID_(informatique)
  24. https://www.composablesystems.com/solid-principles-make-code-flexible/
  25. Fenton, Steve - "Pro TypeScript: Application-Scale JavaScript Development". - Apress - 2017 - ISBN 9781484232491
  26. https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
  27. Robert C. Martin, «  », IEEE Softwarevol. 24, no 3,‎ p. 32–36 (ISSN 0740-7459, DOI 10.1109/ms.2007.85, - https://ieeexplore.ieee.org/document/4163026
  28. https://www.youtube.com/watch?v=AoIfc5NwRks
  29. http://blog.cleancoder.com/uncle-bob/2015/11/18/TheProgrammersOath.html
  30. https://dhh.dk/2014/tdd-is-dead-long-live-testing.html
  31. https://www.infoq.com/fr/news/2014/06/tdd-dead-controversy/
  32. http://www.extremeprogramming.org/
  33. https://explainagile.com/agile/xp-extreme-programming/practices/continuous-integration/
  34. https://www.youtube.com/watch?v=b-aJJtA8Pv8
  35. https://fr.wikipedia.org/wiki/Shuhari
  36. https://cleancoders.com/videos
  37. https://martinfowler.com/bliki/PageObject.html
  38. https://serenity-js.org/design/screenplay-pattern.html
  39. https://dzone.com/articles/page-objects-refactored-solid-steps-to-the-screenp
  40. https://fr.wikipedia.org/wiki/Kata_(programmation)
  41. https://www.soapui.org/testing-dojo/testing-katas/what-are-testing-katas-.html
  42. https://www.techwell.com/techwell-insights/2018/10/code-katas-testers
  43. https://latavernedutesteur.fr/2018/01/12/principe-3-tester-tot/
  44. "On ne peut pas mettre du code de merde à l'échelle" https://v45.scaledagileframework.com/safe-core-values/ https://fr.slideshare.net/rknaster/essential-safe-the-essential-scaling-patterns-that-we-can-probably-all-agree-on
  45. "Le Craftsmanship avant la merde !"
Sauf mention contraire, le contenu de la communauté est disponible sous licence CC-BY-SA.