👶 FERMETURE : L'Atelier est fermé jusqu'au 29 août en raison d'un congé paternité. 👶

Veille Académique

Commencée en 2020, mais publiée à partir de 2021, cette veille académique est le fruit d'un fastidieux travail de lecture, tri, analyse, recoupement, classification et vulgarisation. Si vous en avez les moyens, pensez à nous encourager sur Tipee, ce contenu est rendu public de manière totalement gratuite.

The Difficult Art of Combining Design Patterns with Modern Programming Languages 🔗

🧩 Design (Anti-)Patterns · 🔣 Science des Langages · 🎓 Thèse

🩹 Les langages de programmation et les design patterns ont une relation compliquée. Déjà à l’époque du Gang of Four, Peter Norvig signalait que la plupart des patterns n’étaient que des rustines autour de langages trop pauvres. Les lambda des langages fonctionnels dispensent d’utiliser des factory, par exemple. Certains langages supportent nativement certains patterns et d’autres non ? Trop binaire et réducteur nous répond Eirik Emil Neesgaard Årseth.

🎨 A une vision binaire, il répond en classifiant les relations entre langages et patterns en 4 groupes, dans son mémoire de master (!). Ceertains langages incluent certains patterns dans leur syntaxe, nativement. D’autres absolument pas. Entre ces deux extrêmes, certains langages facilitent certains patterns sans les proposer pour autant. Par exemple, Javascript et son système de types facilite grandement le pattern Prototype. Enfin, certains langages ne proposant pas le support d’un pattern sont rattrapés par leur bibliothèque standard. Que serait C# sans Linq, par exemple.

🦽 Alors, les patterns sont-ils des prothèses pour des langages déficients ? Certains, assurément, mais il est abusif d’employer cette formule pour l’ensemble. Alors que les patterns créationnels sont presque tous des features manquantes, l’auteur prend le pari que les patterns structurels sont là pour de bon.

SOURCE

Årseth, Eirik Emil Neesgaard. The Difficult Art of Combining Design Patterns with Modern Programming Languages. Master thesis, University of Oslo, 2020

An Introduction to Software Architecture 🔗

🧮 Méthodes de développement

🏗️ Aussi étrange que cela paraisse, l’architecture logicielle n’est pas une discipline unifiée ou clairement définie. Une des définitions est celle donnée il y a 30 ans par Garlan et Shaw. Pour eux, l’architecture est la réponse à la complexité de certains logiciels, qu’un bon design ne peut plus juguler. Il faut alors ajouter une couche d’abstraction.

⛔ L’architecte ignore volontairement le code, encapsulé dans des blocs de design. Chaque bloc, nommé composant, interagit ou n’interagit pas avec les autres, selon des règles définies par l’architecte. L’ensemble de ces règles d’architecture détermine la forme du système. L’architecture, pour Garlan et Shaw, consiste à sculpter le système par des règles, qui viennent restreindre la manière dont peuvent se connecter les composants.

🪠 Un exemple ? Obligez les composants à avoir x entrées et y sorties dans un format standardisé. N’autorisez que les connecteurs reliant l’entrée d’un composant à la sortie d’un autre. Vous obtenez une architecture Pipes&Filters omniprésente dans la BI, le low-code ou les shells Unix.

👁️ La vision de Garlan&Shaw donne des règles sur la manière dont les composants ne doivent pas agir. Aux développeurs de les respecter. Elle s’oppose à l’architecture positive, qui inverse la logique : l’architecte dit comment les composants doivent interagir, explicitement. Ces deux visions donnent deux types d’architectes très différents. L’architecte négatif pose des règles, l’architecte positif détermine à chaque instant le comportement des équipes.

SOURCE

Garlan, David and Mary Shaw. “An Introduction to Software Architecture.” Advances in Software Engineering and Knowledge Engineering (1993). DOI: 10.1142/9789812798039_0001


DOIs: 10.1142/9789812798039_0001

A survey on software smells 🔗

🦨 Code Smells

🏛️ J’aime les classifications. Alors quoi de mieux qu’un papier classifiant les classifications des odeurs du code ? C’est ce que proposent 2 chercheurs … grecs. Débat de philosophes ou vrai outil ? Analysons leurs résultats.

☣️ Ils ont recensé plus de 200 (!) odeurs du code dans la littérature existante, rangés dans 14 classifications différentes. Pour les chercheurs, toutes ces classifications peuvent être regroupées en 4 cohortes selon qu’elles classifient eles odeurs selon :

👉 Les principes qu’elles violent

👉 Les effets qu’elles produisent

👉 Les types qu’elles touchent (data, interfaces, etc.)

👉 Leur granularité (intra-classe, design, architecture, etc.)

🐜 Cette clarification n’est pas le seul résultat de ce travail de fourmi ! En comparant les travaux des chercheurs, ils ont noté plusieurs problèmes :

🔴 Peu de chercheurs différencient odeur et antipattern avéré.

🔴 Les définitions de certaines odeurs sont contradictoires entre les papiers.

🟡 La détection et la contextualisation automatique de celles-ci est au mieux balbutiante.

🟡 Nous n’avons pas de preuve solide corrélant odeur et baisse de productivité.

🌋 Les odeurs du code sont un champ de recherche très actif, il faudra encore des années avant d’en voir la maturité.

SOURCE :

Tushar Sharma, Diomidis Spinellis, A survey on software smells, Journal of Systems and Software, Volume 138, 2018, Pages 158-173, ISSN 0164-1212, DOI:10.1016/j.jss.2017.12.034.


DOIs: 10.1016/j.jss.2017.12.034

Comparing four approaches for technical debt identification 🔗

👌 Qualité logicielle · #️⃣ Façonnage de code

🔎 Quels sont les meilleurs outils pour identifier la dette technique* ? Certains repèrent des odeurs du code, d’autres des violations de modularité, d’autres encore des violations d’usage des patterns tandis qu’une dernière catégorie repère des défauts connus.

🧩 Tous et aucuns ! Les problèmes que ces outils identifient se recouvrent très peu, il vaut mieux les cumuler.

* Le terme de dette technique désigne ici la complexité accidentelle du code, non la prise de dette au sens ou l’entend Ward Cunningham. Le terme aurait pu être mieux choisi.

SOURCE

Zazworka, N., Vetro’, A., Izurieta, C. et al. Comparing four approaches for technical debt identification. Software Qual J 22, 403–426 (2014). DOI:10.1007/s11219-013-9200-8


DOIs: 10.1007/s11219-013-9200-8

Why Large IT Projects Fail ? 🔗

📜 Lois du développement

😱 Chaque jour qui passe, le besoin réel à l’origine de vos spécifications évolue. Les spécifications, purs documents légaux, sont figées jusqu’à la prochaine livraison. Plus celle-ci est éloignée du recueil du besoin plus le produit sera décevant pour l’utilisateur. C’est le Glissement des Exigences (Requirements Drift) d’Henderson.

🚀 Ce phénomène est vicieux car très progressif en apparence. Si 0,1% de votre spécification devient obsolète chaque jour par rapport au besoin, les coûts de développement d’un produit satisfaisant auront rapidement doublé !

💡 Le glissement des exigences n’est pas seulement une reformulation de la première loi de Lehman, c’est une explication.

🔃 La morale de l’histoire : plus vous faites des itérations courtes, plus vous vous remettrez souvent en phase avec le besoin réel de votre client, moins le projet débordera.

SOURCE

Henderson, Peter B. “Why Large IT Projects Fail.” (2010).

Value and benefits of model-based systems engineering (MBSE): Evidence from the literature 🔗

🥼 Épistémologie · 🧮 Méthodes de développement

🗺️ Qui n’a pas eu à l’école ce prof convaincu que dans l’avenir, il suffira de dessiner un diagramme UML pour créer un système ? L’intendance suivra. Cette idée, nommée Model-Based Software Engineering (MBSE) est venue remplacer les tombereaux de documents qui servent encore de source de vérité dans de nombreuses entreprises. Une revue de littérature de 2021 vient jeter un pavé dans la mare : il n’y a aucune preuve de l’efficacité de cette pratique.

💨 En démêlant le millier de papiers sortis sur le sujet, Henderson et Salado ont découvert très peu de preuves solides. 360 papiers affirment un bénéfice que 2 seulement mesurent objectivement. 36 “observent”, 240 “perçoivent” et 109 référencent un autre papier. L’homme qui a vu l’homme qui a perçu le loup !

❗ Pire, parmi les bénéfices prétendus de MBSE, des contradictions sont présentes et les chercheurs ne s’accordent pas sur une définition claire.

📣 La NASA ou L’International Council on Systems Engineering font de MBSE le standard de la profession pour 2025 sur la base de l’abondance des publications en sa faveur, mais la quantité est-elle la qualité ? Notre discipline a encore du chemin a faire vers la rigueur scientifique.

SOURCE

Henderson, K, Salado, A. Value and benefits of model-based systems engineering (MBSE): Evidence from the literature. Systems Engineering. 2021; 24: 51– 66. DOI:10.1002/sys.21566


DOIs: 10.1002/sys.21566

The business value of agile software development: Results from a systematic literature review 🔗

🧮 Méthodes de développement

💣 L’intérêt de l’agilité ne réside pas dans son meilleur respect des délais et des coûts. La recherche n’a d’ailleurs jamais affirmé que l’agilité ferait mieux que les méthodes dites “traditionnelles” à ce sujet. Un groupe de chercheurs allemands démontre grâce à une revue de littérature que la “valeur métier” de l’agilité dépasse de loin la simple performance économique :

😎 A un niveau individuel les développeurs se sentent plus motivés et impliqués dans leur travail

🏉 Les équipes sont plus soudées et interagissent mieux

🏢 L’entreprise tend à se réorganiser plus facilement

📊 Les process tendent à être plus souples et performants

🤩 L’agilité est une culture de la satisfaction client, non une méthode de conduite de projet.

❌ Pour enfoncer le clou, ils remarquent que les gains de performance attribués à l’agilité sont en réalité parfaitement corrélés à des pratiques distinctes de celle-ci :

🏭 Le refactoring réduit le nombre de bugs, le temps de débug et la performance du code

🧪 Les tests intensifs et le pair programming réduisent la densité de défauts des logiciels

🕯️ Les rituels augmentent la cohésion et la communication de l’équipe

🪢 Y a-t-il un intérêt à rassembler sous l’étiquette “agilité” des pratiques et une culture disparates ? Oui selon les chercheurs, car toutes ces pratiques forment un tout où chacune renforce l’efficacité des autres. Ils valident une intuition déjà exprimée il y a 30 ans par eXtreme Programming.

SOURCE :

Meckenstock, Jan-Niklas; Hirschlein, Nico; Schlauderer, Sebastian; and Overhage, Sven, “The business value of agile software development: Results from a systematic literature review” (2022). ECIS 2022 Research Papers. 24. https://aisel.aisnet.org/ecis2022_rp/24

A controlled experiment in maintenance: comparing design patterns to simpler solutions 🔗

🧩 Design (Anti-)Patterns

🏹Les design patterns sont-ils overkill par rapport à ce qu’ils apportent ? Tout dépend de la situation, nous répond une étude allemande. Dans certains cas ils alourdissent un code qui ne demande qu’à être laissé tranquille, dans d’autres ils sont une solution élégante.

👨‍💻 Seule l’expérience du professionnel permet de juger efficacement de la pertinence d’un pattern par rapport à une solution n’en comportant pas. Encore faut-il que ledit professionnel respecte 2 conditions :

👉 Connaître les patterns

👉 Ne pas les déifier

♻️ Je recommande pour ma part de développer les deux options « quick&dirty », sous forme de prototype jetable, afin de dissiper les doutes sur la meilleure solution.

🔰 Chose notable, l’étude a été réalisée sur des professionnels confirmés, non sur des étudiants.

SOURCE :

L. Prechelt, B. Unger, W. F. Tichy, P. Brossler and L. G. Votta, « A controlled experiment in maintenance: comparing design patterns to simpler solutions » in IEEE Transactions on Software Engineering, vol. 27, no. 12, pp. 1134-1144, Dec. 2001, doi: 10.1109/32.988711.


DOIs: 10.1109/32.988711

Bad Smells in Software – a Taxonomy 🔗

🦨 Code Smells

🦨 Il est temps de ranger les odeurs du code ! Perdu par leur trop grand nombre et par leur manque de formalisation, le chercheur Mika Mäntylä s’est attelé à les classifier dans sa thèse qui figure au rang des classiques. Son classement a même été repris par des sites grand public comme Sourcemaking ou Refactoring Guru.

💩 Les Bloaters désignent les objets qui sont devenus trop gros pour pouvoir être appréhendés par notre esprit. Méthodes longues, God Classes, mais également plus étonnant, Primitive Obsession et Data Clumps.

📦 Tout ce qui contrevient aux principes de l’orienté-objet est rangé dans la catégorie Object Orientation Abusers. Les switchs, champs temporaires, refus d’héritages y figurent, avec les duplications d’interfaces.

⛓️ Les odeurs ralentissant ou entravant le changement sont nommées Change Preventers.

🗿 Tout ce qui est inutile, mort ou contrevenant au principe YAGNI est un Dispensable.

🪢 Le couple Message Chains/Middle Man, est appelé Encapsulators.

🖇️ Les Couplers, eux, créent du couplage superflu, donc néfaste, entre les classes.

🪄 Cette classification a des défauts dont était déjà conscient Mäntylä : catégories pour 2 odeurs, odeurs ne rentrant dans aucune. Il s’agit d’un outil perfectible, mais pas dépassé depuis 20 ans à ma connaissance.

SOURCE

Mäntylä, Mika & Vanhanen, Jari. (2003). Bad Smells in Software – a Taxonomy and an Empirical Study.

Bad Smells in Software – Software Maintainability 🔗

📜 Lois du développement · 🎓 Thèse

👎 La maintenance des logiciels n’existe pas, dans les faits. C’est une conséquence des lois de Lehman. Pour un logiciel, maintenir son contenu fonctionnel intact, c’est déjà décliner. Pour le chercheur Mika Mäntylä, il faut oublier l’idée de maintenance au profit de la notion d’évolution.

♻️ Le vocabulaire de la maintenance du logiciel, hérité de la maintenance industrielle (adaptative, perfective, corrective) n’est pas pertinent pour décrire le cycle de vie des logiciels. En effet, la maintenabilité n’est pas, comme pour un pont ou une route, la capacité à rester identique, mais bien la capacité à évoluer.

🧑‍🏫 Si la maintenance évolutive est une arnaque sur le plan contractuel, elle est la routine dans le fonctionnement des logiciels. Beaucoup de pédagogie est nécessaire pour le faire accepter aux clients.

SOURCE

Mäntylä, Mika & Vanhanen, Jari. (2003). Bad Smells in Software – a Taxonomy and an Empirical Study.

Partition testing does not inspire confidence 🔗

🧪 Tests

🤠 Dans la vie il y a deux types de testeurs : ceux qui utilisent l’aléatoire et ceux qui partitionnent. Ceux qui utilisent de l’aléatoire trouvent des bugs. Ceux qui partitionnent augmentent leur confiance.

🧠 Partitionner consiste à sélectionner soigneusement les valeurs utilisées lors des tests, contrairement à l’aléatoire qui les teste virtuellement toutes, sur la durée.

🎲 Dans un papier déjà ancien (1990), Hamlet et Taylor réaffirment que, moyennant une puissance de calcul que nous n’avons pas encore en 2022, le test aléatoire est la Rolls, car il permet de trouver plus de bugs.

🚵‍♂️ Attention cependant à ne pas caricaturer. Une Rolls consomme énormément et ne sert à rien sur les chemins de terre que l’on appelle « phase de spécification » !

🪧 Pour résumer grossièrement un papier que je vous recommande de lire :

1️⃣ Commencez par des tests partitionnés afin de définir votre domaine.

2️ « Hackez » les valeurs choisies pour vos tests dans le but de trouver des bugs.

3️⃣ Seulement dans un troisième temps, passez en aléatoire pour détecter des bugs résiduels.

🐛 Si chaque type de test est à sa place, les bugs seront bien gardés.

SOURCE

D. Hamlet and R. Taylor, « Partition testing does not inspire confidence (program testing), » in IEEE Transactions on Software Engineering, vol. 16, no. 12, pp. 1402-1411, Dec. 1990, doi: 10.1109/32.62448.


DOIs: 10.1109/32.62448

How Development and Personality Influence Scientific Thought, Interest, and Achievement 🔗

🧠 Psychologie

🤓Existe-t-il des traits de personnalité et des conditions de développement prédisposant à être scientifique ? Il semble que oui !

🛬 Vous avez 3 fois plus de chances de faire partie de l’élite scientifique de votre pays si vous êtes enfant d’étrangers.

♀️ Si vous êtes une fille sensibilisée aux sciences après l’adolescence, vous avez moins de chance d’en faire votre métier.

🚸 Un scientifique a de grandes chances de s’être intéressé aux sciences avant 12 ans.

🥇 Les premiers-nés sont en général plus conservateurs scientifiquement que les suivants dans la fratrie.

🤬 Être consciencieux, franc, dominant ou avoir confiance en soi diminuent les chances de s’intéresser aux sciences.

⌨️ Je suis à la recherche d’une étude similaire pour les développeurs !

SOURCE

Feist, Gregory J.. “How Development and Personality Influence Scientific Thought, Interest, and Achievement.” Review of General Psychology 10 (2006): 163 – 182. DOI:10.1037/1089-2680.10.2.163


DOIs: 10.1037/1089-2680.10.2.163

Motivated Humans for Reliable Software Products 🔗

🧠 Psychologie · 🧑‍💼 Management

😌 Vous voulez des développeurs productifs ? Fichez-leur la paix en leur épargnant les réunions et les sollicitations incessantes (notifications, téléphone, etc.). Ne les surchargez pas. Ainsi ils pourront entrer plus souvent dans un état de concentration propice à leur art.

📢 Les Open Space ne semblent pas propices non plus à la concentration. Le papier date de 1997, il ne pouvait donc pas évoquer le télétravail, mais celui-ci pourrait être un moyen de laisser les développeurs tranquilles lors des phases où ils ne doivent pas être sollicités.

🥼 Bon sens ? Peut-être, mais avec de la science le message passe toujours mieux.

SOURCE

Frangos, S.A. (1997). Motivated Humans for Reliable Software Products. In: Gritzalis, D. (eds) Reliability, Quality and Safety of Software-Intensive Systems. IFIP — The International Federation for Information Processing. Springer, Boston, MA. DOI:10.1007/978-0-387-35097-4_7


DOIs: DOI:10.1007/978-0-387-35097-4\_7

An exploratory study of the impact of antipatterns on class change- and fault-proneness 🔗

🧩 Design (Anti-)Patterns

🧂 A-t-on des preuves que les antipatterns sont vraiment générateurs d’erreurs ? Oui, et ils sont même corrélés à du code qui est changé plus souvent (avec le risque de le casser, donc).

⛏️ Ce résultat a été obtenu par une équipe italo-canadienne, en minant le code de projets open-source. Cette technique a permis de grandes avancées dans les sciences du logiciel, mais depuis Lehman, on sait que ces résultats sont à prendre avec prudence : l’open-source ne suit pas les même lois que le développement commercial.

SOURCE

Khomh, Foutse, Massimiliano Di Penta, Yann-Gaël Guéhéneuc and Giuliano Antoniol. “An exploratory study of the impact of antipatterns on class change- and fault-proneness.” Empirical Software Engineering 17 (2011): 243-275. DOI:10.1007/s10664-011-9171-y


DOIs: 10.1007/s10664-011-9171-y

Architectural Styles and the Design of Network-based Software Architectures 🔗

📐 Architecture · 💾 Histoire de l'informatique · 🎓 Thèse

🌐 Si Tim Berners-Lee est le papa du Web, alors le parrain en est Roy Fielding. Sa thèse 👇 devrait être lue par tout développeur web. Dans le chapitre 4, notamment, il définit avec précisions les problèmes que doit résoudre l’architecture dont le web a cruellement besoin en l’an 2000 : REST.

Lire la suite

Design patterns impact on software quality : Where are the theories ? 🔗

🧩 Design (Anti-)Patterns

⁉️ Les Design Patterns ont-ils une influence positive sur la qualité des logiciels ? Si quelqu’un vous affirme que les patterns sont obsolètes ou au contraire, qu’ils sont indispensables, il manque clairement de prudence. La recherche n’avait pas tranché en 2018 et de nombreuses questions restent aujourd’hui sans réponse.

🌫️ Nous connaissons beaucoup de propriétés des patterns. Des centaines d’études de cas, positives et négatives, s’accumulent depuis 30 ans dans les tiroirs des chercheurs. De ce brouillard, rien de clair n’est encore sorti, sinon des recommandations limitées, sans aucun caractère général et universel.

💎Que faut-il donc faire ? En attendant que la recherche tranche, ce qui peut prendre des décennies, le plus prudent est de se fier à l’expérience des maîtres. Elle n’est pas unifiée, elle se contredit, mais elle est encore ce qui fonctionne le mieux.

🏺Cette complémentarité, je la nomme Evidence Based Software Craftmanship. La tradition, que chaque génération trie en fonction de ce que la science éclaire.

SOURCE

Khomh, Foutse & Guéhéneuc, Yann-Gaël. (2018). Design patterns impact on software quality: Where are the theories?. 15-25. 10.1109/SANER.2018.8330193.


DOIs: 10.1109/SANER.2018.8330193

Toward a Catalogue of Architectural Bad Smells 🔗

🦨 Code Smells · 📐 Architecture

🦨 Existe-t-il des « odeurs du code » au niveau architectural ? 4 chercheurs californiens proposent une première liste, qui ne sera validée qu’à la condition de les relier à des anti-patterns architecturaux connus.

👉 Connector Envy : Un Composant réalise des opérations normalement propres à un connecteur (Conversion, Coordination, Communication, Facilitation).

👉 Scattered Parasitic Functionality : Plusieurs composants sont chargées de la même fonctionnalité haut-niveau. Il s’agit souvent d’une manifestation d’un Crosscutting Concern.

👉 Ambiguous Interfaces : Les interfaces ne sont pas explicites, c’est à dire qu’un composant communique avec un autre en utilisant des canaux génériques, sans avoir typé les échanges.

👉 Extraneous Adjacent Connector : Il existe plus d’un connecteur reliant deux composants entre eux. Par exemple un appel direct et un bus.

SOURCE

Garcia, J., Popescu, D., Edwards, G., Medvidovic, N. (2009). Toward a Catalogue of Architectural Bad Smells. In: Mirandola, R., Gorton, I., Hofmeister, C. (eds) Architectures for Adaptive Software Systems. QoSA 2009. Lecture Notes in Computer Science, vol 5581. Springer, Berlin, Heidelberg. DOI:10.1007/978-3-642-02351-4_10


DOIs: 10.1007/978-3-642-02351-4\_10

Improving evolvability through refactoring 🔗

♻️ Refactoring · 🦨 Code Smells

🦨 Les odeurs du code sont passées dans la jargon courant des développeurs. A tel point qu’elles ont eu des déclinaisons. Les change smells par exemple, sont des odeurs que l’on ne remarque qu’en analysant l’historique des commits.

🕵️ Les chercheurs nous proposent le « Man In The Middle », où une même classe est modifiée sur la majorité des commits, même s’ils n’ont rien à voir fonctionnellement.

🗃️ On retrouve également le « Data Container », qui se remarque paire la présence d’un binôme de classes toujours modifiées ensembles, l’une portant des données, l’autre des comportements.

🔧 Les chercheurs n’ont pas établi un protocole vraiment solide pour vérifier la solidité de leur proposition, mais l’idée mérite d’être méditée par les développeurs et les éditeurs d’outils.

SOURCE

Jacek Ratzinger, Michael Fischer, and Harald Gall. 2005. Improving evolvability through refactoring. SIGSOFT Softw. Eng. Notes 30, 4 (July 2005), 1–5. DOI:10.1145/1082983.1083155


DOIs: 10.1145/1082983.1083155

An empirical study about the effectiveness of debugging when random test cases are used 🔗

🧪 Tests

🔢 La génération semi-aléatoire de tests unitaires plaît beaucoup aux managers. S’il était possible de détecter les bugs sans que les développeurs n’aient à tester, on pourrait livrer plus ! Une équipe italienne a voulu le vérifier.

🐛 L’aléatoire obtient de bons résultats pour identifier des bugs qui seraient passés hors des mailles des tests classiques. Le débug est légèrement plus difficile que sur des tests manuels, ce qui est compensé par la facilité de créer de tels cas de tests.

🐱‍💻 Ces résultats ne remettent certainement pas en cause l’intérêt des tests fonctionnels ! Ils restent nécessaires dans tous les cas. Cependant, l’aléatoire est un bon moyen d’éviter les raisonnements ad-hoc et de véritablement « hacker » son code à la recherche de bugs.

🧑‍🎓 Seul bémol du papier : toutes les expériences ont été faites avec des étudiants.

SOURCE

Ceccato, Mariano, Alessandro Marchetto, Leonardo Mariani, Duy Cu Nguyen and Paolo Tonella. “An empirical study about the effectiveness of debugging when random test cases are used.” 2012 34th International Conference on Software Engineering (ICSE) (2012): 452-462. DOI: 10.5555/2337223.2337277


DOIs: 10.5555/2337223.2337277

L'informatique de Claude Pair 🔗

💾 Histoire de l'informatique

👴 « Une découverte scientifique ne porte jamais le nom de son auteur ». Ainsi s’énonce la Loi de Stigler, qui n’a d’ailleurs probablement pas été inventée par Stigler. Cette loi s’applique parfaitement à l’informaticien Claude Pair. Ce précurseur de la science des langages de programmation est largement oublié aujourd’hui malgré une carrière riche en inventions capitales.

🧮 Si je vous parle de pile, de récursivité, de types, de structures de données ou d’analyse syntaxique, première étape de toute compilation ? Ou encore de compilateurs de compilateurs, yacc étant le plus célèbre ?

⚖️ Tous ces outils omniprésents dans nos langages modernes sont des inventions de Claude Pair, bien qu’elles lui soient rarement attribuées. Ses anciens étudiants, feu Marion Créhange (première doctorante en informatique) en tête veulent lui rendre justice depuis vingt ans.

📝 Je vous invite à lire l’article qui a servi de source à ce post, il est très accessible.

SOURCE

L’informatique de Claude Pair Marion Créhange, Pierre Lescanne et Alain Quéré: N°18, Novembre 2021, pages 91-116 DOI:10.48556/SIF.1024.18.91


DOIs: 10.48556/SIF.1024.18.91

Flavors : A non-hierarchical approach to object-oriented programming 🔗

💾 Histoire de l'informatique · 🔣 Science des Langages

🍨 Parmi les tentatives pour remédier aux défauts de l’héritage, les mixins figurent en bonne place. Ce concept, créé entre 1979 et 1982 a survécu de nos jours, mais inspira aussi d’autres mécanismes comme les traits, les méthodes d’extension ou les méthodes d’interface.

🔷 Les mixins se présentent comme une solution au problème du diamant, casse-tête à la fois sémantique et pratique courant en POO.

🪟 Dans une interface graphique, vous avez des fenêtres. Certaines ont des labels, d’autres non. Certaines ont des bords, d’autres non. De qui hérite une fenêtre à bords avec label ?

❌ Les deux solutions instinctives sont l’héritage multiple et l’usage de patterns. Les deux apportent de la complexité et ne sont pas satisfaisantes sémantiquement. Une fenêtre n’est pas une fenêtre à bords et une fenêtre à label. C’est une fenêtre, avec des bords et un label.

🎨 Les mixins permettent cela. Sémantiquement, ils expriment une inclusion, non un héritage. Un même objet peut inclure plusieurs flavors, dont le mélange créé le mixin. Ces flavors peuvent hériter d’autres flavors, mais en aucun cas être instanciés seuls.

🤯 L’inconvénient de ce système est de laisser une grande place aux conventions, ce qui augmente la charge mentale qui pèse sur les développeurs et les équipes. En outre, ils ne protègent aucunement des paradoxes logiques comme le Diamant de Nixon.

SOURCE

Cannon, Howard I.. “Flavors : A non-hierarchical approach to object-oriented programming.” (2007).

The Economics of Software Development by Pair Programmers 🔗

🤝 Pair Programming

💰 Un des arguments les plus employés contre le pair-programming est son coût. L’idée est simple : mettre deux développeurs sur un même PC double le coût, sans doubler la vitesse d’exécution. L’entreprise perd de l’argent !

❌ Rien de plus faux, déjà en 1975, Brooks dénonçait ce fameux mythe du mois/homme.

📊 30 ans après Brooks, 2 chercheurs ont rassemblé les chiffres issus de la littérature sur le pair programming. Ils ont effectué une simulation économique comparée. D’un côté deux développeurs seuls, de l’autre une paire. Dans tous les cas, la paire produisait plus de valeur.

📈 Les chercheurs ne sont pas allés plus loin, leur seul objectif était de débunker le faux-argument économique contre le pair programming. Ils ont en revanche noté que seul ou en paire, le développeur produit plus de valeur s’il travaille de manière incrémentale.

SOURCE

Erdogmus, Hakan and Laurie Ann Williams. “The Economics of Software Development by Pair Programmers.” The Engineering Economist 48 (2003): 283 – 319.

Ariane 5: Who Dunnit ? 🔗

💩 Cas d'échecs

🚀 4 juin 1996. Ariane 5 décolle de la base de Kourou. 37 secondes plus tard, le lanceur explose avec à son bord des expériences scientifiques. Aucun humain n’était à bord, fort heureusement. A qui la faute ? A la gestion du logiciel dans le programme.

🐛 Une exception non rattrapée a provoqué une conversion incorrecte, puis un arrêt des systèmes du gyroscope. Ce logiciel avait été porté d’Ariane 4 vers Ariane 5 sans avoir été retesté. La faute à qui ? Comme dirait Jacques Ellul, à personne car le processus était trop complexe pour désigner un coupable. Nous pouvons cependant désigner des suspects.

💥 Les développeurs ont fait une erreur. Elle était dormante sur Ariane 4 et ne s’est déclenchée qu’une fois le logiciel porté sur Ariane 5. Ils ne pouvaient pas l’anticiper, les tests étant incapables de prouver l’absence de bugs. Elle aurait pu être évitée par l’usage d’un langage plus fortement typé, mais ils n’ont probablement pas eu le choix.

🧪 Les testeurs pourraient être coupables, mais ont-ils eu le budget et le temps de revérifier tous les systèmes portés d’Ariane 4 à Ariane 5 ? Le rapport indique qu’il n’y a pas eu de tests de cette partie, sans en indiquer la cause.

🪄 Comme d’habitude c’est la faute au process, donc à personne, sauf à la responsabilité individuelle, éventuellement.

SOURCE

Bashar Nuseibeh. 1997. Ariane 5: Who Dunnit? IEEE Softw. 14, 3 (May 1997), 15–16. DOI:10.1109/MS.1997.589224


DOIs: 10.1109/MS.1997.589224

Higher Order Mutation Testing 🔗

🧪 Tests

👾 Les tests de mutation sont incapables de détecter plus que des bugs triviaux. Pour aller plus loin, il faudrait combiner plusieurs mutations par test. Cette technique se nomme HOMT, Higher Order Mutation Testing en Anglais. Le loup ? Le nombre de tests à générer est exponentiel. Comment surmonter cela ?

🧬Deux chercheurs britanniques expliquent que peu de combinaisons correspondent à des bugs potentiels. Tout le défi est de savoir lesquelles. Ils ont essayé plusieurs méthodes pour y parvenir et il semble que les algorithmes génétiques offrent les meilleurs résultats.

🤖 Tenons-nous enfin une application de l’IA au développement qui ne soit pas du marketing ? Pas si vite. Les résultats montrent aussi qu’un modèle entraîné sur un programme ne fonctionne pas sur un autre. La recherche est encore balbutiante, ces outils ne seront pas dans les mains des devs avant longtemps.

SOURCE

Jia, Yue and Mark Harman. “Higher Order Mutation Testing.” Inf. Softw. Technol. 51 (2009): 1379-1393.

An empirical study of the impact of modern code review practices on software quality 🔗

🧮 Méthodes de développement

👓 Nous savons qu’une mauvaise code review baisse la qualité du code. Mais qu’est-ce qu’une bonne review ? Est-ce seulement atteignable ? Les revues formelles des années 70 ont été abandonnées au profit des analyseurs statiques et autres compilateurs avancés. Seules ont survécu les revues modernes, « légères », ritualisées, mais à l’efficacité discutée.

3️⃣ Pour une bonne revue, il faut 3 ingrédients. Si l’un vient à manquer, ça n’est pas la peine de poursuivre.

👉 Une bonne couverture. La revue doit couvrir une bonne partie des modifications. C’est souvent le seul critère retenu pour les revues modernes, d’où leur échec.

👉 Une participation élevée. Si personne ne s’intéresse vraiment au code, autant ne pas organiser de revues.

👉 Un bon niveau d’expertise. Les participants doivent être adaptés au code revu, inviter tout l’open-space n’a aucun intérêt.

🤝 Vous savez quoi ? Le pair programming garantit automatiquement et en direct la satisfaction de tous ces critères. Une revue n’a pas à être forcément asynchrone, contrairement à un mythe bien ancré*.

*Ce paragraphe est un avis personnel

SOURCE

McIntosh, S., Kamei, Y., Adams, B. et al. An empirical study of the impact of modern code review practices on software quality. Empir Software Eng21, 2146–2189 (2016). DOI:10.1007/s10664-015-9381-9


DOIs: 10.1007/s10664-015-9381-9

Who needs software engineering ? 🔗

📜 Lois du développement

👉 Qu’est-ce que le logiciel ? C’est la question que Steve McConnell a posée à plusieurs experts collaborant à l’IEEE Software en 2001. Parmi les réponses, celle de Robert Cochran a particulièrement retenu mon attention. Elle synthétise les propriétés de ce matériau que nous façonnons.

1. Le logiciel est intangible.

2. Il possède un haut contenu intellectuel.

3. Il n’est pas reconnu comme un actif par les comptables et n’est donc pas dans le compte de résultat.

4. Son développement nécessite beaucoup de main d’œuvre, organisée en équipe autour d’un projet. Les développeurs oublient souvent que peu de métiers dans le monde travaillent ainsi.

5. Il ne possède aucune distinction entre R&D et production.

6. En principe, un logiciel peut changer indéfiniment.

💡 Ces principes peuvent paraître évidents, mais je ne les ai jamais retrouvés aussi clairement listés ailleurs.

SOURCE

Mcconnell, Steve. (2001). Who Needs Software Engineering?. Software, IEEE. 18. 5 – 8. 10.1109/MS.2001.903148.


DOIs: 10.1109/MS.2001.903148

The Effects of Layering and Encapsulation on Software Development Cost and Quality 🔗

🔣 Science des Langages

💊 Contrairement à l’héritage, l’encapsulation obtient de bons résultats en matière de qualité logicielle. Deux groupes d’étudiants ont été formés. Le premier avait le code source complet d’une dépendance, le second n’en connaissait que l’interface publique.

⏲️ Le groupe n’ayant que l’interface à disposition a mis moins de temps à développer une même fonctionnalité que celui ayant les sources complètes. Bien entendu, l’interface fournie était claire et sans effets de bord. Une interface trompeuse ou obscure aurait pu largement changer le résultat.

🧑‍🎓 Hélas, l’étude est peu significative à cause de du faible échantillon (18 personnes) et du fait qu’il s’agisse d’étudiants.

SOURCE : Stuart H. Zweben, Stephen H. Edwards, Bruce W. Weide, and Joseph E. Hollingsworth. 1995. The Effects of Layering and Encapsulation on Software Development Cost and Quality. IEEE Trans. Softw. Eng. 21, 3 (March 1995), 200–208. DOI:10.1109/32.372147


DOIs: 10.1109/32.372147

Experimental assessment of the effect of inheritance on the maintainability of object-oriented systems 🔗

🔣 Science des Langages

↕️ Arrêtez l’héritage ! Il n’est pas nécessaire à l’orienté-objet et serait potentiellement néfaste. Un code avec héritage est plus difficile à modifier que le même code sans héritage.

📝 3 chercheurs on demandé à 4 groupes de 12 étudiants de lire différents codes, utilisant plus ou moins de niveaux d’héritage pour la même fonctionnalité. Ils leur ont ensuite soumis un questionnaire évaluant leur compréhension du code. Le résultat montre une corrélation assez claire.

🗜️ Cependant, les chercheurs notent que la taille du code est encore plus néfaste à la lisibilité. L’héritage pourrait donc être utile s’il amène de la concision. Plus d’études seraient nécessaires.

SOURCE

R. Harrison, S. Counsell, R. Nithi, Experimental assessment of the effect of inheritance on the maintainability of object-oriented systems, Journal of Systems and Software, Volume 52, Issues 2–3, 2000, Pages 173-179, ISSN 0164-1212, DOI:10.1016/S0164-1212(99)00144-2.


DOIs: 10.1016/S0164-1212(99)00144-2

On the Danger of Coverage Directed Test Case Generation 🔗

🧪 Tests

✈️ Générer des tests automatiquement à partir d’une mesure de coverage est toujours une mauvaise idée. Pourtant c’est un standard dans l’aéronautique et le spatial, y compris sur le programme F-35.

🎲 La génération aléatoire avec régression ou la génération dirigée par coverage ne font pas mieux que le pur hasard en matière d’efficacité des tests. Cela signifie que des tests générés parfaitement aléatoirement obtiennent des résultats meilleurs (jusqu’à 2 fois) ou équivalents aux méthodes précédemment citées.

👽 Évidemment, l’étude est légèrement biaisée par l’usage de tests de mutation comme mètre-étalon, mais il est raisonnable de penser que si le coverage est incapable de créer des tests efficaces sur les défauts simples, il ne fera pas mieux que des bugs réels ou complexes.

⚠️ Les chercheurs recommandent de s’en tenir au consensus scientifique : le coverage ne doit être utilisé que comme révélateur des parties du code les moins testées. Pas plus.

SOURCE

Staats M., Gay G., Whalen M., Heimdahl M. (2012) On the Danger of Coverage Directed Test Case Generation. In: de Lara J., Zisman A. (eds) Fundamental Approaches to Software Engineering. FASE 2012. Lecture Notes in Computer Science, vol 7212. Springer, Berlin, Heidelberg. DOI:10.1007/978-3-642-28872-2_28


DOIs: 10.1007/978-3-642-28872-2\_28

Code coverage for suite evaluation by developers 🔗

🧪 Tests

👾 Les tests de mutation sont utiles, mais coûteux à exécuter. Mieux vaut les réserver à l’environnement d’intégration continue. 3 chercheurs américains nous montrent que le statement coverage constitue une bonne approximation aux tests de mutation, suffisante en tout cas pour indiquer aux développeurs les parties sous-testées du code.

🎯 En effet, rappelez-vous : le coverage ne doit JAMAIS être un objectif.

SOURCES

Rahul Gopinath, Carlos Jensen, and Alex Groce. 2014. Code coverage for suite evaluation by developers. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). Association for Computing Machinery, New York, NY, USA, 72–82. DOI:10.1145/2568225.2568278


DOIs: 10.1145/2568225.2568278

On the effectiveness of unit tests in test-driven development 🔗

🧪 Tests

🔥 J’ai trouvé la perle rare : une étude sur TDD qui compare cette méthode à Test-Last ! La plupart ont le biais de comparer TDD vs Pas de tests. Malgré son faible échantillon, elle obtient des résultats positifs : TDD serait plus efficace pour obtenir une couverture acceptable que Test-Last.

👾 Cependant l’étude a un biais : la mesure servant à comparer les deux méthodes est le score de mutation. Or, on sait que celui-ci n’est pas totalement corrélé aux fautes réelles.

🏢 Cette étude va dans le bon sens, mais notre profession manque cruellement d’études de cas sur le long-terme, faute de dialogue entre chercheurs et entreprises. Si vous êtes manager, aidez-les ! Contactez l’université la plus proche pour leur proposer de vous étudier.

SOURCES

René Just, Darioush Jalali, Laura Inozemtseva, Michael D. Ernst, Reid Holmes, and Gordon Fraser. 2014. Are mutants a valid substitute for real faults in software testing? In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2014). Association for Computing Machinery, New York, NY, USA, 654–665.

Tosun, A., Ahmed, M., Turhan, B., & Juristo, N. (2018). On the effectiveness of unit tests in test-driven development. In M. Kuhrmann, R. V. O’Connor, D. Houston, & R. Hebig (Eds.), ICSSP 2018 – May 26-27 – Gothenburg, Sweden: Proceedings of the 2018 International Conference on Software and System Process (pp. 113-122). Association for Computing Machinery (ACM). DOI:10.1145/3202710.3203153


DOIs: 10.1145/3202710.3203153

Exploring the relationships between design measures and software quality 🔗

👌 Qualité logicielle

📏 Les années 90 ont laissé derrière elles pléthore de mesures quantitatives du code : CBO, RFC, MPC, DAC, ICP, etc. Elles sont passées de mode dès la décennie suivante, faute de preuves de leur efficacité contre les bugs. On leur doit tout de même l’abandon progressif de l’héritage en orienté-objet, plus avantageusement remplacé par la composition dans la plupart de ses usages.

🔎 Le papier du jour analyse l’efficacité de différentes mesures et leur corrélation avec la probabilité de découvrir des défauts. Si les mesures d’héritage ou de couplage s’en sortent bien, les mesures de cohésion ne semblent pas donner de résultats.

🐛 Autrement formulé, si les mesures de cohésion et d’héritage sont bien corrélées à la probabilité qu’il existe un défaut dans un classe, il n’y a aucune garantie que ces défauts quantitatifs soient corrélés à de vrais bugs, qualitativement ressentis comme tel. La plupart des études des années 2000 ont confondu ces notions, ce qui les rend caduques avec le recul.

SOURCE

Briand, Lionel Claude, Jürgen Wüst, John W. Daly and D. Victor Porter. “Exploring the relationships between design measures and software quality in object-oriented systems.” J. Syst. Softw. 51 (2000): 245-273. DOI : 10.1016/S0164-1212(99)00102-8


DOIs: 10.1016/S0164-1212(99)00102-8

Non-software examples of software design patterns 🔗

🧩 Design (Anti-)Patterns

👨‍🏫 Certains design patterns peuvent être illustrés par des exemples réels, qui aident à les enseigner. Ainsi le commercial agit comme un Proxy pour les questions techniques, le contrôleur aérien est un Médiateur, le médecin un Visiteur, et la chaîne de commandement à l’armée est une Chaîne de Responsabilité.

💭 D’autres, sans doute trop abstraits ou liés aux propriétés particulières du logiciel (personne n’a jamais vu un maçon réaliser une toiture avant les fondations, alors que c’est le quotidien d’un développeur), manquent de tels exemples. Leur enseignement reste, encore aujourd’hui un défi.

🧠 Les exemples, bien qu’utiles, doivent cependant être utilisés avec prudence : ils illustrent bien, mais décrivent mal. Une fois initié à l’aide d’exemples, le développeur doit s’en détacher pour progresser.

SOURCES

Duell, Michael, John Goodsen and Linda Rising. “Non-software examples of software design patterns.” OOPSLA ’97 (1997).


DOIs: 10.1145/274567.274592

Realizing quality improvement through test driven development : results and experiences of four industrial teams 🔗

🧪 Tests

🧪 TDD fonctionne et ses effets positifs s’accumulent dans le temps à condition de ne pas baisser la garde et de correctement respecter la méthode. La papier n’a rien d’original, il est une étude de plus sur le sujet. Son originalité est d’indiquer une corrélation entre la compétence des praticiens et le rapport bénéfices/coûts de TDD.

🧠 Plus les développeurs sont formés, moins le temps supplémentaire passé à écrire les tests se ressent et plus les bugs sont rares. Hélas, les résultats sont statistiquement peu significatifs, à cause de la faiblesse de l’échantillon.

✅ Les papiers s’accumulent sur TDD et aucun n’est encore venu infirmer l’hypothèse que cela fonctionne très bien, avec un peu de formation et beaucoup de sérieux.

SOURCES

Nagappan, Nachiappan, E. Michael Maximilien, Thirumalesh Bhat and Laurie A. Williams. “Realizing quality improvement through test driven development: results and experiences of four industrial teams.” Empirical Software Engineering 13 (2008): 289-302.


DOIs: 10.1007/s10664-008-9062-z

The effects of development team skill on software product quality 🔗

👌 Qualité logicielle · 🧠 Psychologie

🤯 Les Juniors ont tendance à produire des logiciels de moins bonne qualité que des Novices, remarquent deux chercheurs américains. Comment est-ce possible ? Deux explications :

🎖️ Les chercheurs émettent l’hypothèse que les Junior sont considérés comme des développeurs « comme les autres » par le management, ils se voient attribuer les mêmes tâches que leurs collègues Senior, sans en avoir l’expertise.

⛰️ Je postule que l’effet Dunning-Kruger n’est pas étranger à ce phénomène. Alors que le Novice tâtonne avec prudence, le Junior prend la confiance sans avoir le niveau de ses aînés, il se situe donc sur la « Montagne de la Stupidité », le pire alignement possible. En mûrissant, il comprendra qu’il ne sait rien.

SOURCES

Beaver, Justin & Schiavone, Guy. (2006). The effects of development team skill on software product quality. ACM SIGSOFT Software Engineering Notes. 31. 1-5. 10.1145/1127878.1127882.


DOIs: 10.1145/1127878.1127882

On the Composition of Well-Structured Programs 🔗

👌 Qualité logicielle

🤬 Aucun gain de performance n’a de valeur si un programme n’est pas fiable ! Le vrai défi ne consiste pas à gratter le moindre bit ou la moindre microseconde. La priorité est d’organiser des programmes de plus en plus gros et complexes, grâce à une rigueur et des méthodes prenant en compte les limitations fondamentales de nos cerveaux. Les développeurs doivent être humbles et s’interdire de déployer des programmes qu’ils ne maîtrisent pas complètement.

💰 Économiquement, le salaire des développeurs est plusieurs ordres de grandeur plus cher que le temps de calcul. En gâcher 90% en maintenance est inexcusable.

🤦‍♂️ Ce propos n’a rien d’innovant ? C’est bien le problème, il a été écrit en 1974 par Niklaus Wirth. Rien n’a changé.

SOURCES

Niklaus Wirth. 1974. On the Composition of Well-Structured Programs. ACM Comput. Surv. 6, 4 (Dec. 1974), 247–259. DOI:10.1145/356635.356639


DOIs: 10.1145/356635.356639

Enough About Process : What We Need are Heroes 🔗

🧠 Psychologie · ✊ Corporatisme · 🏺 Artisanat

🧠 Début février, je postais un article sur l’opposition entre artisanat et ingénierie. Une différence dont je n’ai pas parlé, pour ne pas alourdir mon propos, est le lien entre process et compétences.

🤖 L’industrie, que ce soit voulu ou non, remplace la compétence par le process, qui est sa version encapsulée et simplifiée pour être comprise par une machine.

🦾 L’artisanat assiste la compétence par le process, qui n’en est que l’auxiliaire.

🦸 Cette distinction fait écho à la notion d’héroïsme, telle que la souhaite Roger Pressman, dans un papier resté célèbre. Il peste contre le tout-process, qui consiste à jeter le héros dans le même sac que le hacker ou le cowboy, deux figures mal-vues, souvent à raison, dans notre métier.

✨ Notre métier n’accumule les réussites que lorsqu’une mentalité artisanale permet aux héros de prendre le leadership sur les projets, même si Pressman n’utilise pas ce terme.

SOURCE

Bach, James. “Enough About Process: What We Need are Heroes.” IEEE Softw. 12 (1995): 96-98. DOI : 10.1109/52.368273


DOIs: 10.1109/52.368273

Science and substance : a challenge to software engineers 🔗

🥼 Épistémologie

🛑 Le travail que je réalise ici est probablement trompeur. Il y a presque 30 ans, Fenton, Pfleeger et Glass nous alertaient contre un ennemi subtil : la mauvaise science. La situation n’a probablement pas changé et ça n’est que maintenant que je découvre cet article édifiant.

🧠 Mon but avec cette veille est de privilégier l’empirisme à l’intuition. Un raisonnement même brillant ne suffit pas : il faut des chiffres, solides de préférence.

🥼 Je n’ai pas de formation scientifique et les écoles ne sensibilisent pas les étudiants à la recherche. Il me manque des bases solides et ça n’est que par intérêt pour l’empirisme (organisateur de bien des aspects de ma vie), que je me suis lancé dans ce travail d’intérêt général. J’y amène mes limites.

👁️ C’est ce « mieux que rien » qui me fait continuer. Toutefois, après la lecture de cet article, je vais veiller à améliorer progressivement ma manière d’interpréter la recherche.

🔝 Quels seraient ces axes d’amélioration selon les auteurs ?

👉 Vérifier l’adéquation entre l’expérience et l’hypothèse testée.

👉 Ne pas automatiquement croire les données issues de recherches sur des étudiants ou sur des projets conçus pour l’occasion. Il faut recueillir des données de vrais praticiens sur de vrais projets.

👉 Vérifier que les mesures effectuées sont légitimes sur les données recueillies.

👉 Vérifier la temporalité, un résultat peut être différent à court et long-terme.

👉 Vérifier la représentativité, certaines expériences sont trop courtes ou avec un échantillon trop restreint, ou biaisé.

🤑 Ce n’est que comme cela que notre profession sortira de l’immaturité et des promesses des vendeurs de solutions-miracle.

SOURCE

N. Fenton, S. L. Pfleeger and R. L. Glass, « Science and substance: a challenge to software engineers, » in IEEE Software, vol. 11, no. 4, pp. 86-95, July 1994, doi: 10.1109/52.300094.


DOIs: 10.1109/52.300094

Critical success factors for software projects : A comparative study 🔗

🧑‍💼 Management

🔝 Tel un Youtubeur en manque d’inspiration, je vais résumer le papier du jour par un TOP 5 (le dernier va vous étonner, pouce bleu, abonnement). Quels sont les facteurs de succès les plus critiques dans un projet logiciel, selon 43 publications étudiées ?

5️⃣ Avec 22 papiers le mentionnant, le soutien du top management, incluant la confiance envers l’équipe de développement, n’est pas à négliger.

🥉 Les compétences du management et la pertinence de la méthode utilisée sont cités par 23 papiers. Si vous me suivez, j’ai déjà donné quelques pistes sur ce que la recherche en pense.

🥉 Ex-aequo, l’adoption d’un planning réaliste. Si vos devs acceptent mollement VOS estimations ou alertent qu’elles sont irréalistes, écoutez-les. Imposer une deadline relève souvent du caprice si les devs vous disent que c’est impossible.

🥈 Des objectifs clairs sont cités par 24 papiers. Trop souvent cette évidence manque. Le projet ne peut pas réussir, faute d’avoir une définition de la réussite connue de tous.

🥇 Avec 26 citations, la clarté des exigences&spécifications mérite sa place en tête. Là encore, si vous me suivez, vous savez que c’est un serpent de mer et que seule une démarche itérative et pilotée par les tests (EATDD) produit des effects significatifs.

🔧 Vous noterez qu’il n’y a AUCUN facteur technique. Les développeurs ne sont pas le facteur limitant dans le marais de sous-qualité contemporain. Le gâchis logiciel est dans les méthodes.

SOURCES

Nasir, Mohd Hairul Nizam Bin Md and Shamsul Sahibuddin. “Critical success factors for software projects: A comparative study.” Scientific Research and Essays 6 (2011): 2174-2186. DOI:10.5897/SRE10.1171


DOIs: 10.5897/SRE10.1171

Iterative enhancement : A practical technique for software development 🔗

💾 Histoire de l'informatique · 🧮 Méthodes de développement

🔁 Le développement itératif et incrémental (IID), souvent rebrandé « Agilité », n’est certainement pas une technique nouvelle sur laquelle nous n’aurions pas de recul. Avant que l’OTAN ne créé l’ingénierie du logiciel en 1968, les développeurs ont accumulé de beaux succès avec une méthode que Basili et Turner ont synthétisée en 1975.

🦴 Tout commence avec « une implémentation initiale d’un squelette de sous-problème », autrement dit peu de choses. Les développeurs viennent ensuite dépiler des tâches présentes sur une liste, pour bâtir itérativement le logiciel.

8️⃣ A tout moment, 8 règles doivent être respectées :

👉 S’il y a une difficulté, le refactoring doit faciliter sa résolution

👉 Si les modifications ne sont pas circonscrites à un module, il faut redesigner.

👉 Même chose pour les tables

👉 Plus une itération progresse, plus la modification doit être simple à achever. Sinon il faut refacto.

👉 La durée de vie d’un patch ne doit jamais dépasser 2 itérations

👉 Le code doit être relu fréquemment à la lumière des objectifs

👉 Les outils d’aide au développement doivent être utilisés le plus fréquemment possible, pas seulement à la fin d’une itération

👉 Il faut en permanence collecter les retours utilisateurs et améliorer l’implémentation.

🗑️ Cette méthode n’a jamais cessé d’être appliquée, même si les années 80 ont préféré recourir massivement aux méthodes Waterfall, gonflant les taux d’échec et ruinant la réputation de notre profession.

SOURCES

Basili, Victor R. and Albert J. Turner. “Iterative enhancement: A practical technique for software development.” IEEE Transactions on Software Engineering SE-1 (1975): 390-396. DOI : 10.1109/TSE.1975.6312870


DOIs: 10.1109/TSE.1975.6312870

Object-oriented programming with flavors 🔗

💾 Histoire de l'informatique · 🔣 Science des Langages

🍦L’orienté-objet n’est pas né d’une traite. Son histoire est jalonnée de prototypes, qui ont pavé la voie à ce qu’il est aujourd’hui. Les flavors en font partie. Ancêtre direct des mixins/traits modernes, ils n’ont jamais été implémentés hors de LISP.

🧑‍🔬 Outre l’intérêt historique du papier, il me permet d’évoquer le creuset de ce paradigme : OOPSLA. Il s’agit d’une conférence annuelle de chercheurs en langages de programmation. Aujourd’hui fondue dans SPLASH, elle était autrefois indépendante.

🧠 En sont sortis une grande partie des papiers présentés ici et beaucoup de grands noms de la profession y ont développé leurs idées : Barbara Liskov, John Vlissides, Kent Beck, David Parnas et j’en passe.

💮 C’est à l’OOPSLA 1986 que David Moon et Howard Cannon ont proposé l’idée des Flavors. Il s’agit d’une manière de faire partager des méthodes et attributs communs entre deux classes, sans qu’elles ne dépendent d’un parent commun.

🧩 L’héritage simple est débattu depuis longtemps. L’abandon de l’héritage multiple, expérience malheureuse de C++, et l’insuffisance de la composition, jugée lourde par certains praticiens, ont abouti à l’idée de « traits » partagés par plusieurs classes sans lien hiérarchique. On les retrouve aujourd’hui en Kotlin, PHP, Ruby, Rust, Scala, pour ne citer que les principaux.

💣 Plus suprenant, C# et Java implémentent un système de traits sans l’assumer, en permettant la définition de méthodes dans les interfaces. L’idée aura mis 20 ans à percer, nul doute qu’elle ne sera pas correctement utilisée avant encore 20 ans. Tout ce qui rend passionnant ce métier en somme.

SOURCE

David A. Moon. 1986. Object-oriented programming with flavors. SIGPLAN Not. 21, 11 (Nov. 1986), 1–8. DOI:10.1145/960112.28698


DOIs: 10.1145/960112.28698

Coverage and Its Discontents 🔗

🧪 Tests

Pour bien enfoncer des portes ouvertes, encore un papier sur le lien entre coverage et qualité des tests :

❌ Attacher une prime ou un objectif quelconque au coverage est la pire des idées. Elle poussera les développeurs à faire de mauvais tests.

❌ Branch-coverage, statement-coverage, etc. Aucun ne sort du lot en matière de bugs découverts.

❌ Les tests de mutation semble posséder les mêmes biais que le coverage. D’autres recherches sont nécessaires.

✔️ Le Coverage restera toujours un meilleur indicateur que le nombre de tests ou leur temps d’exécution.

✔️ Le Coverage permet de repérer les parties du code sous-testées, c’est son principal (seul ?) avantage.

💡 En résumé, utilisez le coverage pour repérer les oublis de votre politique de tests, pas comme indicateur d’absence de bugs !

SOURCES

Groce, Alex & Alipour, Mohammad & Gopinath, Rahul. (2014). Coverage and Its Discontents. 10.1145/2661136.2661157.


DOIs: 10.1145/2661136.2661157

The Impacts of Low/No-Code Development on Digital Transformation 🔗

🧮 Méthodes de développement · 🦥 Low/No Code

💸 Je lis parfois des propos rageurs, souhaitant le chômage à ces incompétents de développeurs, enfin rendus inutiles par le Low/No Code (LNC). Outre le manque de charité flagrant, la recherche n’est pas du même avis : LNC et développeurs sont complémentaires, et ce pour longtemps.

🇨🇦 Le chercheur Zhaohang Yan, de l’université de Toronto, synthétise une vingtaine d’articles présentant les avantages et inconvénients des outils LNC.

✔️ Une application LNC est bien plus agile qu’un développement classique, avec un temps de développement divisé par 5 ou 10.

✔️ L’utilisation de LNC permet de libérer les développeurs des tâches à faible valeur, auxquelles peuvent se consacrer les utilisateurs, directement.

✔️ LNC offre un exutoire aux utilisateurs, moins tentés d’utiliser des outils non-conformes aux politiques de sécurité, dits « Shadow IT »

➖ Les applications LNC semblent plus maintenables que les projets classiques, mais les données sont peu significatives.

❌ Une application LNC n’est ni scalable, ni customisable. Si les briques logiques offertes par une plateforme ne permettent pas d’exprimer un besoin, développer un logiciel sera moins coûteux que de créer une chimère, infecte à maintenir.

❌ Adopter LNC c’est faire une confiance totale à une plateforme. Confiance en matière de sécurité (gros acteurs = gros intérêt des assaillants), de confidentialité (les GAFAM vivent de vos données) et de durabilité (la plateforme sera-t-elle là dans 10 ans ?). Totale, car il est très compliqué de migrer une application LNC.

SOURCES

Yan, Zhaohang. (2021). The Impacts of Low/No-Code Development on Digital Transformation and Software Development.


DOIs: 2112.14073v1

« Cloning Considered Harmful », Considered Harmful 🔗

#️⃣ Façonnage de code

🍸 DRY : Don’t Repeat Yourself. Un slogan rabâché aux étudiants du monde entier, souvent comme un dogme. Largement sorti de son sens original (ne pas dupliquer de connaissance), il devient souvent une chasse aux sorcières anti-duplication du code, créant des monstres.

🇨🇦 Deux chercheurs canadiens ont décortiqué ce problème en distinguant plusieurs buts à la duplication, chacun présentant un bilan plus ou moins positif en faveur de la duplication.

🍴 Le forking, où le clone vit indépendamment de sa source, pose très peu de problèmes, tant que les deux codebases sont régulièrement nettoyées et qu’elles n’ont pas d’interactions entre elles.

🗋 Le templating, simple copier-coller d’un snippet pour en reproduire les effets présente deux grands dangers : multiplier les coûts de maintenance et dupliquer un code buggé. Il est déconseillé sauf si les avantages contrebalancent ce choix.

🪄 La customisation est une simple inspiration, avec ou sans copier-coller, d’un code qui sera remanié ensuite pour résoudre le problème. Elle est un bon moyen de gagner du temps à court-terme, mais créé une dette technique qui devra être tracée et résorbée.

🧪 Les auteurs ne parlent pas de duplication dans les tests, qui sont un 4ème cas à ajouter au papier : on sait qu’il vaut mieux un test dupliqué qu’un test obscur, la clarté primant sur tout le reste.

📝 Chacune de ces catégories est subdivisée plus finement, je vous encourage à lire le papier pour avoir une vision plus fine du sujet que LinkedIn ne le permet !

SOURCES

Hunt, Thomas, Pragmatic Programmer, The: From Journeyman to Master. Pearson. 2000.

Kasper, C. and Godfrey, M.W. (2008) Cloning Considered Harmful, Considered Harmful: Pattern of Cloning in Software. Empirical Software Engineering, 13, 645-692 DOI:10.1007/s10664-008-9076-6


DOIs: 10.1007/s10664-008-9076-6

Does code decay ? Assessing the evidence from change management data 🔗

📜 Lois du développement · ♻️ Refactoring

☠️ Le code se décompose-t-il ? Pas au sens biologique, car il est une pure information, immuable. Cependant, tout développeur le sait, un code qui prend de l’âge devient plus difficile à éditer, coûte plus cher et se constelle de bugs. Ce phénomène est inévitable autant bien le connaître !

🩺Ses symptômes sont connus :

👉 Le code devient bouffi et complexe, les développeurs s’engluent dans des modifications interminables.

👉 Les bugs se multiplient et la satisfaction des utilisateurs baisse.

👉Les commits n’ont plus de cohérence (shotgun surgery)

👉 Les développeurs ne vont plus droit au but, ils beurdassent* le code pour espérer arriver à leurs fins.

🕳️ La décomposition du code doit alerter les développeurs : ignorer cette odeur est extrêmement dangereux et se soldera inévitablement par la mort du projet à moyen ou long terme. Si rien n’est fait, une part de plus en plus grande de la productivité de l’équipe ira dans le trou noir des intérêts de la dette, jusqu’à la paralysie complète.

♻️ Une lueur d’espoir persiste cependant : il existe une cure de jouvence facile d’accès qui se nomme refactoring.

* Traduction libre de « code churn » via ce verbe saintongeais. Amitiés aux québécois qui en ont hérité.

SOURCES

S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron and A. Mockus, « Does code decay? Assessing the evidence from change management data, » in IEEE Transactions on Software Engineering, vol. 27, no. 1, pp. 1-12, Jan. 2001, doi: 10.1109/32.895984.


DOIs: 10.1109/32.895984

The magical number seven: still magic after all these years ? 🔗

🧠 Psychologie

🪄 Pourquoi le chiffre 7 est-il si magique ? Selon le psychologue Miller, il est une bonne approximation de la capacité de la mémoire immédiate humaine sur des tâches génériques (auxquelles le sujet n’a pas été entraîné). Mais en quelle unité s’exprime cette capacité ? En éléments ? Non ! En chunks.

🧠 Un chunk est une « case » dans notre mémoire. Pour Miller et la psychologie cognitive, lorsque nous devons accomplir une tâche, notre cerveau doit charger des éléments en mémoire, afin de les manipuler pour obtenir un résultat. Pour un développeur, ce sont des arguments d’une méthode, des classes ou tout autre artefact du code.

📦 Chez un novice, chaque chunk correspond en général à un élément. L’intérêt du concept apparaît avec l’entraînement : un individu apprend rapidement à « compresser » les informations pour augmenter la densité d’éléments par chunk. Le cerveau possède un grand nombre d’outils pour cela, comme l’abstraction, le mapping avec des éléments stockés dans la mémoire à long terme ou encore l’utilisation de représentations visuelles ou sonores.

📊 En réalité 7 (6.5 précisément) est une moyenne, mais en réalité la capacité de nos cerveaux s’échelonne entre 3 et 15 éléments, suivant une courbe en cloche.

🤝 Ces travaux nous aident à comprendre nos cerveaux et ceux des utilisateurs qui consomment nos produits, afin de tirer le meilleur parti des limites biologiques de notre condition.

SOURCES

Baddeley, Adrian J.. “The magical number seven: still magic after all these years?” Psychological review 101 2 (1994): 353-6 DOI:10.1037/0033-295x.101.2.353


DOIs: 10.1037/0033-295x.101.2.353

Can testedness be effectively measured ? 🔗

🧪 Tests

🔨 C’est dans les vieilles controverses que l’on trouve les meilleurs papiers. 5 chercheurs démontrent que le score de mutation ne fait pas mieux que le coverage pour éviter des bugs futurs. Leur résultat va à l’encontre du consensus établi. Artefact statistique ? Non, nouvelle méthode de calcul et critique rigoureuse des précédents travaux.

🐛 La méthode de calcul précédemment admise, consistait à introduire des bugs dans un programme, puis à vérifier le pourcentage de ces bugs couverts par la méthode testée (branch coverage, statement coverage, mutation score, etc.).

🪲 Pour les auteurs, il n’y a qu’une très faible corrélation avec les bugs réels. Ils ont préféré miner les sources de logiciels Open Source et vérifier, pour chaque bug résolu, si le code fautif était couvert par la méthode testée.

🏆 Le résultat renvoie le score de mutation au niveau des autres méthodes : utile pour repérer les parties sous-testées, pas plus. Le champion tombe de son piédestal.

📝 Évidemment, une étude ne changera pas le consensus, elle devra être répliquée, mais il s’agit d’une belle avancée de la recherche.

SOURCES

Ahmed, Iftekhar, Rahul Gopinath, Caius Brindescu, Alex Groce and Carlos Jensen. “Can testedness be effectively measured?” Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering (2016): n. pag.


DOIs: 10.1145/2950290.2950324

On the relation of refactorings and software defect prediction 🔗

♻️ Refactoring

🔄 Le refactoring est craint par les managers, qui pensent que les développeurs le pratiquent par pur perfectionnisme, sans preuve de son efficacité. Et pourtant, cela fait plus de 10 ans que la recherche a tranché : après un refactoring, plus de bugs sont corrigés et le temps moyen pour les résoudre diminue !

⚠️ Attention cependant aux faux-refactorings. Le refactoring modifie la structure du code, sans modifier son comportement. C’est cette technique qui a été validée par la recherche. Pas le remaniement à la fourche de larges morceaux de code. Deux moyens sont possibles :
-Refactoring assisté, où l’IDE sécurise les changements, le développeur ne touche pas au code à la main.
-Refactoring libre, sur un code piloté par les tests. Les tests garantissent que le code n’a pas été altéré dans le service rendu.

🪲 Tout autre style de remaniement n’est pas du refactoring, juste du rework. Ce dernier ne bénéficie d’aucune validation par la recherche et pourrait même engendrer plus de bugs que ceux qu’il corrige !

SOURCES :

Jacek Ratzinger, Thomas Sigmund, and Harald C. Gall. 2008. On the relation of refactorings and software defect prediction. In Proceedings of the 2008 international working conference on Mining software repositories (MSR ’08). Association for Computing Machinery, New York, NY, USA, 35–38. DOI:10.1145/1370750.1370759

Miryung Kim, Dongxiang Cai, and Sunghun Kim. 2011. An empirical investigation into the role of API-level refactorings during software evolution. In Proceedings of the 33rd International Conference on Software Engineering (ICSE ’11). Association for Computing Machinery, New York, NY, USA, 151–160. DOI:10.1145/1985793.1985815

1999. Refactoring: improving the design of existing code. Addison-Wesley Longman Publishing Co., Inc., USA.


DOIs: 10.1145/1370750.1370759 · 10.1145/1985793.1985815

Realizing quality improvement through test driven development 🔗

🧪 Tests

🧪 Le papier du jour est peu original : encore un étude sur TDD ! Celle-ci vient confirmer des résultats précédents, tout en démontrant que TDD réduit aussi les défauts des commits suivants, même s’ils ne sont pas réalisés avec TDD.

🐂 Les chercheurs nous avertissent toutefois : TDD cesse d’être efficace quand l’arrêt de cette démarche pousse à ne plus maintenir ou à supprimer des tests. Pour que le cercle vertueux se poursuive tout le long d’un projet, il faut de la persévérance.

⏱️ L’effort n’est pas immense : environ 15% de temps de développement en plus par rapport au même code sans tests. Entre 40% et 80% de défauts en moins selon les projets étudiés. Aucun discipline d’ingénierie ne possède de levier aussi important d’amélioration.

SOURCE

Nagappan, N., Maximilien, E.M., Bhat, T. et al. Realizing quality improvement through test driven development: results and experiences of four industrial teams. Empir Software Eng13, 289–302 (2008). DOI:10.1007/s10664-008-9062-z


DOIs: 10.1007/s10664-008-9062-z

Cohesion and reuse in an object-oriented system 🔗

#️⃣ Façonnage de code

💥Les classes les plus réutilisées dans un même système sont celles ayant le moins de cohésion. C’est la trouvaille de deux chercheurs du Colorado. Corrélation n’est pas causalité, mais ce résultat pourrait signifier :

Hypothèse 🅰️ : Qu’il existe une causalité encore à démontrer entre faible cohésion et réutilisation. Cela paraît assez peu probable.

Hypothèse 🅱️ : que les classes réutilisées partout sont souvent aussi atteintes d’une faible cohésion et inversement. Les God Classes qui polluent la plupart des codebases correspondent à ces deux définitions.

🥼 D’autres expériences seront nécessaires pour valider ou invalider ces hypothèses. Mon instinct penche vers la seconde, mais sait-on jamais.

SOURCE

James M. Bieman and Byung-Kyoo Kang. 1995. Cohesion and reuse in an object-oriented system. SIGSOFT Softw. Eng. Notes 20, SI (Aug. 1995), 259–262. DOI:10.1145/223427.211856


DOIs: 10.1145/223427.211856

J. B. Rainsberger : florilège 🔗

🧪 Tests · 🧑‍💼 Management · ♻️ Refactoring

🏅J’ai parcouru l’ensemble des articles de l’excellent J. B. Rainsberger depuis 2006. J’en ai sélectionné trois que je vous livre comme un florilège et que j’archive pour leur grande valeur.

https://blog.jbrains.ca/permalink/how-test-driven-development-works-and-more

https://blog.jbrains.ca/permalink/refactoring-where-do-i-start

https://blog.jbrains.ca/permalink/the-importance-of-aligning-authority-with-responsibility

Test-driven development with mutation testing – an experimental study 🔗

🧪 Tests

🇵🇱 TDD n’a plus rien à prouver. Une fois les développeurs formés, son usage ne présente presque que des avantages. Bien que moins connus, le mutation testing est tout aussi robuste. Deux chercheurs polonais ont monté une expérience démontrant l’efficacité de l’alliance TDD+Mutation et les synergies entre les 2 méthodes.

🕸️ Ce n’est qu’une première expérience, mais les résultats sont concluants. La mutation permet au développeur de combler les trous laissés par le développeur, pour un coût minime en temps, donc en moyens.

🧑‍🎓 Un premier papier intéressant qui mériterait d’être reproduit chez des développeurs confirmés, l’étude ne portait que sur des étudiants, qui sont un public posant de nombreux problèmes quand il est recruté pour des études sur TDD.

SOURCES

Roman, Adam & Mnich, Michał. (2021). Test-driven development with mutation testing – an experimental study. Software Quality Journal. 29. 1-38. DOI:10.1007/s11219-020-09534-x.


DOIs: 10.1007/s11219-020-09534-x

Influence of Human Factors in Software Quality and Productivity 🔗

🧑‍💼 Management · 🧪 Tests

🧪 Les tests automatisés sont le seule manière abordable de contrôler la qualité d’un logiciel. Le manque de sérieux des managers et des développeurs à ce sujet sont la principale source de sous-performance des équipes de développement.

🧟 Cette conclusion audacieuse nous vient de deux chercheurs qui ont analysé les facteurs humains régissant la productivité et la qualité dans une équipe de développement.

⏰ Du côté des managers, le manque de sérieux est le principal frein à la mise en place de stratégies de test solides. La plupart ont bien été sensibilisés à l’intérêt théorique des tests, mais les passent au second plan lorsqu’une deadline est en vue.

🏫 Les développeurs, eux, manquent de formation. L’école ne leur apprend pas à tester efficacement et aucun employeur n’investit dans ces compétences qui sont chères sur le marché des formations. Ils testent sans méthodes reconnues, s’épuisent à la tâche et finissent par détester les tests.

SOURCE

Sanz, Luis Fernández and Sanjay Misra. “ Influence of Human Factors in Software Quality and Productivity. ” ICCSA (2011). DOI: 10.1007/978-3-642-21934-4_22


DOIs: 10.1007/978-3-642-21934-4_22

Subjective Evaluation of Software Evolvability Using Code Smells 🔗

🦨 Code Smells

🇫🇮 Les odeurs du code sont très peu connues des développeurs, bien moins que les patterns. Pour y remédier, le finlandais Mika Mäntylä propose en 2006 une classification des odeurs du code qui est passée à la postérité. Son but : simplifier pour mieux enseigner.

🗜️De 22 odeurs « classiques » chez Fowler, Mäntylä passe à 7 familles, plus faciles à retenir et à comprendre. L’auteur a résumé sa taxonomie sur GitHub : https://mmantyla.github.io/BadCodeSmellsTaxonomy

👨‍🏫 C’est un outil précieux pour les formateurs, qui n’ont pas besoin d’entrer dans le détail des odeurs du code pour enseigner la notion.

SOURCES

Mäntylä, M. V. and Lassenius, C. « Subjective Evaluation of Software Evolvability Using Code Smells: An Empirical Study ». Journal of Empirical Software Engineering, vol. 11, no. 3, 2006, pp. 395-431.

M. Fowler and K. Beck, « Bad Smells in Code, » in Refactoring: Improving the Design of Existing Code, Addison-Wesley, 2000, pp. 75-88. DOI: 10.1007/s10664-006-9002-8


DOIs: 10.1007/s10664-006-9002-8

Do Crosscutting Concerns Cause Defects ? 🔗

#️⃣ Façonnage de code · 👌 Qualité logicielle

💥 Plus une fonctionnalité est éparpillée dans le code, plus elle a de chances d’être défectueuse. Cela vaut aussi pour les Crosscutting Concerns (logs, sécurité, exceptions, etc.). Plus ils sont nombreux et moins ils sont modularisés, plus le code spaghetti guette !

💣 Ce résultat, indépendant du nombre de lignes de code, a été obtenu en 2008 par plusieurs membres de l’organisation IEEE. Ils répondaient à la question « Les Crosscutting Concerns sont-ils source de défauts ? ». La réponse est bien oui, car ils sont difficiles à modulariser, difficiles à tester et sont donc très souvent implémentés avec insouciance par les développeurs, au motif que « ça n’est pas du code métier ».

⚠️ Les Crosscutting Concerns sont partout et ne doivent pas être pris à la légère. Contrairement à la croyance courante, ils sont à confier aux plus expérimentés, pas aux juniors que l’on refuse de mettre sur le code métier.

SOURCE

Marc Eaddy, Thomas Zimmermann, Kaitlin D. Sherwood, Vibhav Garg, Gail C. Murphy, Nachiappan Nagappan, and Alfred V. Aho. 2008. Do Crosscutting Concerns Cause Defects? IEEE Trans. Softw. Eng. 34, 4 (July 2008), 497–515.


DOIs: 10.1109/TSE.2008.36

Deux classifications d'intérêt général 🔗

♻️ Refactoring · 🦨 Code Smells

🇳🇱 Dans la tradition aristotélicienne, on dit que le propre de l’intelligence et de mettre de l’ordre. C’est bien ce que font Arie van Deursen et Leon Moonen, deux chercheurs néerlandais. Ils nous livrent deux classifications, une sur les odeurs de test, l’autre sur les types de refactorings.

📝 Je vous les livre en l’état, les deux papiers sont courts et clairs.

🦨 Le premier liste 11 odeurs du code courantes et 6 refactorings permettant de les éliminer.

🔙 Le second classe les refactorings de Fowler en 5 groupes selon la rétrocompatibilité entre le code après et avant refactoring.

🗣️ Ces classifications s’ajoutent à notre jargon professionnel, c’est là leur principal intérêt. Un langage commun permet à une profession une plus grande efficience, par l’économie de périphrases hésitantes.

SOURCES

Deursen, Arie & Moonen, Leon & Bergh, Alex & Kok, Gerard. (2001). Refactoring Test Code. DOI:10.5555/869201

Deursen, Arie & Moonen, Leon. (2002). The Video Store Revisited – Thoughts on Refactoring and Testing.


DOIs: 10.5555/869201

Evaluating software degradation through entropy 🔗

📜 Lois du développement · 👌 Qualité logicielle

🚮 L’entropie est aujourd’hui devenu un terme poli pour désigner la pourriture logicielle. Comme l’entropie thermodynamique, l’entropie du logiciel est une notion ayant une base théorique solide, négligée lors de son passage dans le langage courant. Aujourd’hui, un papier italien de 2001, offrant la première définition rigoureuse connue de ce phénomène.

🕸️ Les 4 chercheurs définissent l’entropie d’un logiciel comme la somme des couplages entre les modules. Ces couplages peuvent être directs ou indirects, structurels (dépendances de compilation) ou cognitifs (charge mentale de devoir penser à A en éditant B).

💣 Plus un code possède d’entropie, plus la portée d’une modification est grande. Nous en avons tous fait l’expérience : modifiez un détail sur un code endetté, vous obtenez des effets de bord imprévus et tout est à revoir.

🏚️ Dans la seconde partie du papier, les chercheurs apportent les premières preuves permettant d’affirmer qu’il s’agit d’une mesure pertinente pour évaluer le vieillissement d’un logiciel, donc la nécessité d’un rajeunissement par le refactoring.

SOURCE

A. Bianchi, D. Caivano, F. Lanubile and G. Visaggio, « Evaluating software degradation through entropy, » Proceedings Seventh International Software Metrics Symposium, 2001, pp. 210-219, doi: 10.1109/METRIC.2001.915530.


DOIs: 10.1109/METRIC.2001.915530

Des limites à l'usage des design patterns 🔗

🧩 Design (Anti-)Patterns

🪄 Après l’enthousiasme des années 1990, les années 2000 furent une période d’intense remise en question des design patterns. Loin d’être la panacée ils se révélaient un boulet pour certains usages et la plupart des bénéfices que l’on en espérait étaient absents. Quoi de plus normal, dans une discipline ayant « No Silver Bullet » pour première loi.

🇳🇴 En 2004, le norvégien Marek Vokac énonce que les patterns seuls n’ont aucun pouvoir face à la complexité intrinsèque de certaines parties du code.

🇮🇹 En 2009, 3 italiens découvrent que la combinaison de certains patterns avec la présence de crosscutting concerns (logs, sécurité, cache, etc.) augmente le nombre de défauts, car ces patterns ont tendance à éparpiller la responsabilité.

➕ Aucun de ces chercheurs n’a remis en question le bénéfice net de l’usage de patterns. Tous appellent en revanche à la prudence : ils ne conviennent simplement pas à toutes les situations. Ce serait trop facile, sinon. Notre métier est immensément complexe. C’est une bonne nouvelle pour son avenir.

SOURCES

M. Vokac, « Defect frequency and design patterns: an empirical study of industrial code, » in IEEE Transactions on Software Engineering, vol. 30, no. 12, pp. 904-917, Dec. 2004, doi: 10.1109/TSE.2004.99.

Aversano, L. & Cerulo, Luigi & Di Penta, Massimiliano. (2009). Relationship between design patterns defects and crosscutting concern scattering degree: An empirical study. Software, IET. 3. 395 – 409. 10.1049/iet-sen.2008.0105.

Brooks, Frederick P. (1986). « No Silver Bullet—Essence and Accident in Software Engineering ». Proceedings of the IFIP Tenth World Computing Conference: 1069–1076.


DOIs: 10.1109/TSE.2004.99 · 10.1049/iet-sen.2008.0105

Sustainable Software Development through Overlapping Pair Rotation 🔗

🧑‍💼 Management · 🤝 Pair Programming

👥 Aujourd’hui, deux papiers, dont l’un est devenu un classique, qui listent les bénéfices, attendus ou plus surprenants, du pair programming. Certains sont peu connus et justifient largement les 15% de surcoût observé par rapport à une équipe classique (et non 100%, comme le pense la croyance managériale).

  • Le taux de défauts en production est bien plus bas.
  • Le pair programming coût moins cher que les code review à résultat égal.
  • Les solutions trouvées sont meilleures et plus simples, donc plus maintenables.
  • La vélocité d’une paire est plus élevée que celle d’un développeur seul.
  • Les développeurs se sentent mieux à leur poste.
  • L’apprentissage est plus rapide, même un expert apprendra au contact d’un novice (et inversement, bien entendu)

📚 Enfin, bien moins connu, le pair programming augmente la résilience de l’équipe sans nécessiter des camions entiers de documentation, très coûteuse à maintenir et empiriquement jamais à jour.

♻️ Sedano, Ralph et Péraire appellent cette propriété « Développement durable du logiciel ». En travaillant par paires a minima tournantes, les développeurs partagent la connaissance du code « naturellement » et l’ensemble de l’équipe finit par obtenir la responsabilité collective de l’ensemble du code au bout de quelques mois.

Pour obtenir cette propriété, la rotation des paires doit être fréquente ! Des paires fixes et affinitaires ne fonctionnent pas et créent des silos. A minima, les paires doivent se chevaucher, mais la meilleure technique consiste à « polliniser » le savoir en s’assurant que toutes les paires possibles ont été pratiquées sur une itération par exemple.

SOURCES

Todd Sedano, Paul Ralph, and Cécile Péraire. 2016. Sustainable Software Development through Overlapping Pair Rotation. In Proceedings of the 10th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM ’16). Association for Computing Machinery, New York, NY, USA, Article 19, 1–10. DOI: 10.1145/2961111.2962590

Alistair Cockburn and Laurie Williams. 2001. The costs and benefits of pair programming. Extreme programming examined. Addison-Wesley Longman Publishing Co., Inc., USA, 223–243. DOI: 10.5555/377517.377531


DOIs: 10.1145/2961111.2962590 · 10.5555/377517.377531

A design methodology for reliable software systems 🔗

📐 Architecture · #️⃣ Façonnage de code

👵 Encore un papier de Barbara Liskov. J’ai déjà parlé d’elle dans un post précédent (lien à la fin). Dans ce papier de 1972 extrêmement actuel, elle nous explique comment produire des logiciels fiables, car testés, donc testables. Le raisonnement est long, mais rémunérateur pour qui le suit jusqu’au bout.

🐛 Elle constate d’abord que le débogage intensif n’a jamais rien résolu. Il faut des tests automatisés couvrant l’ensemble des cas utiles.

🧮 Elle ajoute qu’il serait trop complexe d’obtenir des preuves formelles qu’un logiciel complexe fonctionne, à cause du nombre trop grand d’états. Des preuves informelles peuvent suffire à condition de structurer le programmes correctement, afin qu’ils soient le plus testables et prévisibles possibles.

✔️ La testabilité est donc, pour Barbara Liskov, une question de design.

✂️ L’idée de découper le programme en modules est bonne, mais insuffisante. Un découpage bancal ajoute plus de complexité qu’il n’en masque.

2️⃣ Elle donne deux règles, tirées des travaux de Dijkstra et Parnas, déjà évoqués ici :

👉 S’appuyer sur le principes des machines virtuelles de Parnas, où chaque niveau d’abstraction s’appuie sur celui immédiatement en dessous pour réaliser des oéprations plus complexes et proches du métier.

👉 Faire de la programmation structurée, sans goto donc. L’abolition du goto qui est évidente pour nous en 2021 était encore une bataille rangée en 1972.

🔪 La combinaison de ces deux règles permet une indépendance des modules par le découplage.

✨ On obtient ainsi un programme qu’il est possible de tester comme suit :

👉 Chaque module est individuellement testé par un ensemble de tests X.

👉 Chaque assemblage de modules complet est testé par un ensemble de tests Y.

➕ Grâce au design qu’elle recommande, le nombre de cas de tests nécessaires n’est pas X*Y, mais bien X+Y pour atteindre une couverture satisfaisante, ce qui est à la portée des développeurs.

SOURCE

Liskov, Barbara. “A design methodology for reliable software systems.” AFIPS ’72 (Fall, part I) (1972). DOI: 10.1145/1479992.1480018


DOIs: 10.1145/1479992.1480018

Les standards de code spécifiques sont bénéfiques aux projets 🔗

🧮 Méthodes de développement

🍟 Cathal Boogerd et Leon Moonen nous ont déjà montré que les standards de code ne sont pas efficaces pour diminuer le nombre de bugs et peuvent même l’augmenter. Une équipe de l’INRIA Lille prolonge la réflexion en montrant que les standards du code spécifiques au projet, écrits par les développeurs, sont bien plus efficaces que les règles génériques.

⚠️C’est un outil largement sous-utilisé et même inconnu. Pour la majorité des développeurs, les alertes de leur compilateur ou de leur IDE sont presque une fatalité, ils ignorent qu’il est possible sur la plupart des langages de les augmenter de règles faites maison.

SOURCES

Andre Hora, Nicolas Anquetil, Stéphane Ducasse, Simon Allier. Domain Specific Warnings: Are They Any Better?. IEEE International Conference on Software Maintenance, Sep 2012, Riva del Garda, Italy. pp.441-450. DOI: 10.1109/ICSM.2012.6405305

Boogerd, Cathal & Moonen, Leon. (2008). Assessing the Value of Coding Standards: An Empirical Study. IEEE International Conference on Software Maintenance, ICSM. 277 – 286. 10.1109/ICSM.2008.4658076.


DOIs: 10.1109/ICSM.2008.4658076 · 10.1109/ICSM.2012.6405305

Assessing the Value of Coding Standards: An Empirical Study 🔗

🧮 Méthodes de développement

📜 Quelle équipe n’a pas défini de standards de code ? C’est un lieu commun qu’ils permettent l’harmonie dans l’équipe et la protection contre les bugs. Mais en sommes nous sûrs ? Cathal Boogerd et Leon Moonen mettent un coup de pied dans la fourmilière : ces standards n’empêcheraient pas les bugs et pourraient même en créer !

🪲 Le raisonnement est le suivant : toute modification risque statistiquement d’introduire un bug. Une modification qui n’apporte aucun bénéfice obéit aussi à cette règle, elle est donc contre-productive. Or la majorité des standards de code est inutile (60/72 parmi les règles étudiées par l’équipe) car ne correspondant à rien de plus qu’une vague coutume d’équipe.

🔎 Pour les chercheurs, toute règle qui ne naît pas d’un problème identifié cause plus de bugs qu’elle n’en résout. Ils recommandent donc la plus grande prudence lors de l’adoption de celle-ci.

La révision régulière de ces règles afin de supprimer celles qui sont obsolètes pourrait également présenter un intérêt.

SOURCE

Boogerd, Cathal & Moonen, Leon. (2008). Assessing the Value of Coding Standards: An Empirical Study. IEEE International Conference on Software Maintenance, ICSM. 277 – 286. 10.1109/ICSM.2008.4658076.


DOIs: 10.1109/ICSM.2008.4658076

Test-driven development as a defect-reduction practice 🔗

🧪 Tests

🏁 Il y a des quantités de papiers expérimentaux sur TDD. Ils mériteraient une synthèse, mais en attendant je vous en livre un de plus : chez IBM, une équipe expérimentée travaillant en mode Test-Last a été comparée à une équipe de novices pratiquant TDD. Les résultats sont bluffants.

🐛 40% de nouveaux bugs en moins sur le même projet pour l’équipe TDD. Un impact minimal sur la productivité. Des tests jugés plus maintenables, qualitatifs et réutilisables.

☑️ Contrairement à beaucoup d’études qui comparent assez fallacieusement TDD à l’absence de tests, celle-ci a le mérite de comparer TDD à Test-Last. L’étude ne dit pas comment les développeurs de l’équipe TDD ont été formés, ni leur niveau précédant la formation.

✔️ Sous réserve que l’investissement, que l’on sait conséquent, soit fait, TDD semble apporter des bénéfices démontrés.

SOURCE

L. Williams, E. M. Maximilien and M. Vouk, « Test-driven development as a defect-reduction practice, » 14th International Symposium on Software Reliability Engineering, 2003. ISSRE 2003., 2003, pp. 34-45, doi: 10.1109/ISSRE.2003.1251029.


DOIs: 10.1109/ISSRE.2003.1251029

Effet tiroir et science du logiciel 🔗

🧩 Design (Anti-)Patterns · 🥼 Épistémologie

🕳️ Aujourd’hui trois papiers sur le même sujet : est-ce que la participation à un design pattern rend une classe plus susceptible de changer ? Aucune réponse claire ne sera donnée, mais je vais rebondir en parlant d’effet tiroir, la plaie de la recherche.

👌 Aucun de ces trois papiers n’a de résultats significatifs dans un sens ou dans l’autre. Bref, on ne sait pas et les facteurs de confusion sont sans doute trop grands pour conclure. Pourtant les chercheurs à l’origine de ces papiers ont décidé de les publier et nous devons les y encourager.

🚮 On désigne sous le nom d’effet tiroir un biais connu dans la recherche : il est plus gratifiant de publier des résultats que de publier une absence de résultats. Les papiers présentant peu ou pas de résultats ont donc plus tendance à rester au fond d’un tiroir, alors qu’ils sont nécessaires à l’avancée de la recherche.

✔️ Ils indiquent aux autres chercheurs ce qui a déjà été tenté, afin qu’ils essaient différemment de trouver la réponse.

✔️ Ils indiquent aux praticiens que sur une question donnée, rien n’est tranché et qu’il vaut mieux adopter une posture prudente.

✔️ Ils permettent aux auteurs de méta-analyses de tempérer les résultats positifs et négatifs éventuels avec la part de papiers n’ayant rien trouvé, fiabilisant largement les résultats.

🏅 L’effet tiroir est une vrai problème en recherche, surtout par le manque de chiffres pour le caractériser. Nous avons déjà les IgNobel, il manquerait un prix pour récompenser les chercheurs qui ont déployé le plus d’efforts pour ne rien trouver.

SOURCES

Aversano, L. & Canfora, Gerardo & Cerulo, Luigi & Grosso, Concettina & Di Penta, Massimiliano. (2007). An empirical study on the evolution of design patterns. 385-394. 10.1145/1287624.1287680.

Bieman, James & Straw, Greg & Wang, Huxia & Munger, P. & Alexander, Roger. (2003). Design Patterns and Change Proneness: An Examination of Five Evolving Systems.. IEEE METRICS. 40-49. 10.1109/METRIC.2003.1232454.

M. Di Penta, L. Cerulo, Y. -G. Gueheneuc and G. Antoniol, « An empirical study of the relationships between design pattern roles and class change proneness, » 2008 IEEE International Conference on Software Maintenance, 2008, pp. 217-226, doi: 10.1109/ICSM.2008.4658070.


DOIs: 10.1145/1287624.1287680 · 10.1109/METRIC.2003.1232454 · 10.1109/ICSM.2008.4658070

Why Don't They Practice What We Preach ? 🔗

🧠 Psychologie · 🧑‍💼 Management

🦥 Pourquoi les développeurs n’adoptent pas les bonnes pratiques ? Je crois la question elle est vite répondue, parce qu’ils sont réfractaires au changement ! Justement non, et Watts Humphrey, « le père de la qualité », qui a dédié sa vie à améliorer nos pratiques, nous livre son ressenti sur la question.

🐂 Sans dédouaner ces rares professionnels butés qui ne veulent absolument pas changer de pratiques, il désigne plusieurs mécanismes qui empêchent la majorité des développeurs de s’améliorer en continu.

🏫 En haut de la liste, le système éducatif (facs et écoles) qui ne donne pas aux étudiants les bonnes clés. Les développeurs n’apprennent pas à mesurer la qualité de leur code, étant notés sur les résultats de leurs projets, non sur la qualité de leur design.

🔥Ensuite, l’entreprise, trop focalisée sur les urgence quotidiennes pour investir dans des formations longues qui cassent le rythme de production. Humphrey note qu’un développeur sous pression tend à privilégier ce qu’il sait faire au détriment des urgences. Pour la majorité peu formée, cela signifie la production en masse de code médiocre. Il faut les épaules d’un maître pour garder un cap sous pression. C’est donc un investissement payant, mais coûteux.

⏳ Enfin, la résistance au changement n’est pas négligeable. Plus un développeur a d’expérience avec une pratique donnée, fut elle mauvaise, plus le niveau de preuve nécessaire pour le convaincre de changer est grand, surtout s’il ne possède aucun exemple autour de lui. L’atteindre nécessite un accompagnement pratique, donc de le retirer de la production. C’est sans issue.

✔️ Humphrey propose 2 leviers de changement.

👉 Former dès le berceau est le plus facile. Les étudiants sont des tabula rasa qu’il suffit de former correctement. Encore faut-il vaincre les résistances au changement de leurs professeurs.

👉 Adopter une stratégie du temps long en entreprise. La qualité d’aujourd’hui est la maintenabilité, donc la rentabilité de demain. Former ses développeurs réduit le turnover et augmente la qualité du code. Hélas c’est un gros investissement qu’une entreprise déjà sous l’eau ne peut se permettre. Le recrutement d’un lead dev charismatique, au moins le temps d’insuffler les bonnes pratiques aux autres développeurs, est une option sans doute intéressante.

SOURCES

Watts S. Humphrey, Why Don’t They Practice What We Preach? 2009, Software Engineering Institute. DOI: 10.1023/A:1018997029222


DOIs: 10.1023/A:1018997029222

When Does a Refactoring Induce Bugs ? An Empirical Study 🔗

♻️ Refactoring

🛠️ Contrairement à un mythe tenace, le refactoring, même automatisé par l’IDE, présente des risques d’introduire des bugs ! La seule parade est un jeu de tests de qualité.

🤌 6 chercheurs italiens ont sorti en 2012 un papier à ce sujet. Tous les refactoring ne sont pas égaux. Renommer est souvent anodin. Manipuler les hiérarchie est le plus glissant, jusqu’à 40% des actions de type Pull Up Method et Extract Subclass introduisent des bugs, contre 15% pour le refactoring en général.

✔️ On ne répétera jamais assez l’importance des tests en logiciel, il sont le filet de sécurité qui permet au développeur de remanier son travail jusqu’à le rendre satisfaisant.

SOURCE :

M. Fowler, K. Beck, J. Brant, W. Opdyke, D. Roberts, Refactoring : Improving the Design of Existing Code. Addison Wesley, 1999

G. Bavota, B. De Carluccio, A. De Lucia, M. Di Penta, R. Oliveto and O. Strollo, « When Does a Refactoring Induce Bugs? An Empirical Study, » 2012 IEEE 12th International Working Conference on Source Code Analysis and Manipulation, 2012, pp. 104-113, doi: 10.1109/SCAM.2012.20.


DOIs: 10.1109/SCAM.2012.20

When and Why Your Code Starts to Smell Bad (and Whether the Smells Go Away) 🔗

🧮 Méthodes de développement · ♻️ Refactoring · 🦨 Code Smells

🦨 En 2017, plusieurs chercheurs emmenés par Michele Tufano ont fait une découverte : les odeurs du code (code smells) ne sont pas majoritairement introduits lors du refactoring, mais bien présents dès le départ dans un code. La pression mise sur les développeurs en est la cause principale.

📙 Cela va contre l’affirmation de Fowler dans son célèbre Refactoring, qui pensait que la majorité des odeurs apparaissent lors de l’évolution du code.

🔍 Les chercheurs notent toutefois que l’analyse statique du code élimine une grande partie des odeurs. Elle devrait donc être lancée avant chaque commit.

SOURCES

Tufano, Michele et al. “When and Why Your Code Starts to Smell Bad (and Whether the Smells Go Away).” IEEE Transactions on Software Engineering 43 (2017): 1063-1088. DOI: 10.1109/TSE.2017.2653105


DOIs: 10.1109/TSE.2017.2653105

What is DevOps ? A Systematic Mapping Study on Definitions and Practices 🔗

🧮 Méthodes de développement

Qu’est-ce qu’un DevOps et en suis-je ? C’est la question que je me posais régulièrement avant de tomber sur la revue de littérature de Jabbari, bin Ali, Petersen et Tanveer. Ils ont analysé une cinquantaine de papiers pour donner une définition précise du sujet, que je traduis ici.

« DevOps est une méthodologie de développement visant à combler le fossé entre développement et opérations, mettant l’emphase sur la communication et la collaboration, l’intégration continue, l’assurance qualité et la livraison avec déploiement automatisé utilisant un jeu de pratiques de développement »

Si cette phrase définit DevOps, alors j’en suis ! Un bon développeur sait livrer, avec ou sans DevOps.

En revanche, si pour vous DevOps est un moyen d’économiser un administrateur en chargeant le développeur de missions qui ne sont pas les siennes, ce n’est pas DevOps et je ne m’inscris pas dans cette démarche.

SOURCE :

Ramtin Jabbari, Nauman bin Ali, Kai Petersen, and Binish Tanveer. 2016. What is DevOps? A Systematic Mapping Study on Definitions and Practices. In Proceedings of the Scientific Workshop Proceedings of XP2016 (XP ’16 Workshops). Association for Computing Machinery, New York, NY, USA, Article 12, 1–11. DOI: 10.1145/2962695.2962707


DOIs: 10.1145/2962695.2962707

Towards an Anatomy of Software Craftsmanship 🔗

🏺 Artisanat · 🧑‍💼 Management · 🧮 Méthodes de développement · ✊ Corporatisme

🛠️ Je suis un artisan du logiciel. Mais qu’est-ce que cela signifie ? 4 chercheurs, emmenés par Anders Sundelin, ont publié en septembre dernier un papier tentant de cerner le concept. Le triptyque de Sandro Mancuso pourrait résumer leurs recherches : Professionalisme, pragmatisme, fierté.

3️⃣ Les conclusions du papier peuvent être organisées en 3 parties : les valeurs, les pratiques et les organisations.

🧭 Les valeurs sont le cœur de l’identité des développeurs qui se rattachent à cette école. La responsabilité et le professionnalisme ressortent en premier : pour les artisans eux-mêmes, faire correctement leur métier n’est pas négociable. Chaque développeur doit se sentir responsable de l’état de l’ensemble du code et en tirer une certaine fierté. L’artisan doit transparence et honnêteté à son client quant à l’état du code, via la mise en évidence de la dette technique, par exemple. C’est aussi un refus du découpage industriel des tâches dans le développement. Pour les plus radicaux, l’architecte doit disparaître au profit d’une réflexion collégiale entre équipes, mais la plupart s’accordent sur son implication forte au sein des équipes de développement « les mains dans le cambouis ».

🎛️ Les pratiques forment des règles de l’art. Elles sont composées d’un cœur de techniques anciennes et éprouvées, issues en majorité d’Extreme Programming (XP), auxquelles s’ajoutent des bonnes pratiques tenant lieu de lois du logiciel, comme les principes SOLID. On y retrouve la valorisation de la simplicité, ATDD, la méfiance envers toute documentation qui ne serait pas engendrée par du code et l’accent mis sur la livraison et le feedback.

🕸️ Les organisations procèdent des valeurs et des pratiques. On y retrouve des conférences comme Socrates, SCNA ou NewCrafts, bâties en réaction à ce qu’est devenue l’agilité, buzzword pour managers ayant ses coachs et ses certifications hors de prix, bien éloignées des préoccupations des développeurs. Les coding dojo et les katas sont un marqueur fort, tant en entreprise que dans des tiers-lieux servant de rassemblement à de véritables communautés néo-corporatives*, unies par une culture de l’apprentissage permanent. Les auteurs rejoignent les conclusions de Benjamin Tainturier et Emanuelle Duez, qui ont clairement réalisé leur enquête, à dessein ou non, auprès d’artisans.

* le terme n’est pas dans le papier.

SOURCES

Anders Sundelin, Javier Gonzalez-huerta, Krzysztof Wnuk, and Tony Gorschek. 2021. Towards an Anatomy of Software Craftsmanship. ACM Trans. Softw. Eng. Methodol. 31, 1, Article 6 (January 2022), 49 pages. DOI:10.1145/3468504

Sandro Mancuso, The Software Craftsman : Professionalism, Pragmatism, Pride. 2014. Pearson. ISBN:978-0134052502

Benjamin Tainturier, Emmanuelle Duez, The Boson Project. Décoder les développeurs. Enquête sur une profession à l’avant-garde. 2017. Eyrolles.


DOIs: 10.1145/3468504

Towards a Mapping of Software Technical Debt onto Testware 🔗

🦨 Code Smells · 🧪 Tests

🦨 Vous pensiez vos tests exempts d’odeurs du code ? Deux chercheurs suédois piétinent vos douces illusions.
Non seulement les tests sont du code, donc sujets à des variantes des odeurs et antipatterns qui affaiblissent les logiciels, mais ils ont en plus leurs odeurs spécifiques.

⛓️ Tout code est une responsabilité (liability). Pas seulement le code de production. Le code le plus robuste est celui qui n’existe pas, ce qui vaut aussi pour les tests. Le meilleur code est toujours celui qui offre le plus grand résultat avec le moins de lignes de codes, tests inclus.

📚 Dijkstra disait qu’un logiciel n’est utile que si la masse de documentation nécessaire à l’opérer est inférieure à la taille de ses sources. Il n’est pas aberrant de penser la même chose pour les tests.

SOURCES

E. Alégroth and J. Gonzalez-Huerta, « Towards a Mapping of Software Technical Debt onto Testware, » 2017 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA), 2017, pp. 404-411, doi: 10.1109/SEAA.2017.65.

Edsger Dijkstra, On the Reliability of Programs

https://wiki.c2.com/?SoftwareAsLiability


DOIs: 10.1109/SEAA.2017.65

The role of knowledge in software development 🔗

🧠 Psychologie

🧠 Comment la psychologie voit le savoir et quel est son rôle dans le développement de logiciels ? Le professeur Robillard le vulgarise avec brio dans un papier qui a plus de 20 ans, mais qui reste une merveille.

Pierre N. Robillard. 1999. The role of knowledge in software development. Commun. ACM 42, 1 (Jan. 1999), 87–92. DOI:10.1145/291469.291476


DOIs: 10.1145/291469.291476

The chaos of software development 🔗

🧮 Méthodes de développement · 📜 Lois du développement · ♻️ Refactoring

⚛️ La complexité d’un programme est-elle liée à celle de la méthode utilisée pour le développer ? Oui d’après un papier de deux chercheurs canadiens en 2003. Ils ont utilisé une application de l’entropie de Shannon afin d’évaluer la corrélation entre ces deux variables.

🔊 Plus la méthode de gestion de projet utilisée complique la tâche des développeurs, moins le code sera simple (donc maintenable) à la fin du processus. Cela peut s’expliquer de différentes manières :

❌ Le bruit, à savoir toutes les information confuses ou non-pertinentes que les développeurs doivent trier pour faire leur métier
❌ L’incertitude, qui provoque des redéveloppements évitables.

✔️ Le papier valide deux éléments des Software Wastes de Todd Sedano, qui est ultérieur.

⛏️ Comment inverser la vapeur si c’est déjà trop tard pour votre projet ? Les auteurs donnent toujours la même réponse : le refactoring. C’est un consensus souvent exprimé dans l’ensemble des papiers que j’ai pu lire, décidément.

SOURCES

Hassan, A. and Richard C. Holt. “The chaos of software development.” Sixth International Workshop on Principles of Software Evolution, 2003. Proceedings. (2003): 84-94. DOI: 10.5555/942803.943729

Sedano, Todd & Ralph, Paul & Péraire, Cécile. (2017). Software Development Waste. DOI: 10.1109/ICSE.2017.20


DOIs: 10.5555/942803.943729

Technical decision-making in startups and its impact on growth and technical debt 🔗

🧑‍💼 Management · 🧮 Méthodes de développement

On sait peu de choses des facteurs de réussite des startups sur le champ du logiciel, car le domaine est peu étudié. Cependant, Carl Hultberg, étudiant en management industriel nous livre une excellente synthèse du peu que nous savons.

Les généralités sont simples et intuitives : 📈 satisfaire ses utilisateurs et 📉 juguler la dette technique.

Pour cela, deux pratiques sont recommandées.

👉 Créer une équipe produit au profil technico-fonctionnel, très proche des développeurs. La plupart des méthodes agiles recommandent même un Product Owner faisant partie de l’équipe de développement.

👉Toujours ramener les features à l’essentiel. Pas de superflu, moins de code. Moins de code, moins de dette.

Ces conclusions sont à augmenter avec ce que nous savons de la dette technique, que l’auteur n’a pas la formation pour repérer : tester son code pour permettre un refactoring fréquent, seul remède efficace contre la dette.

Source : Hultberg C., Technical decision-making in startups and its impact on growth and technical debt

Rule-based Assessment of Test Quality 🔗

🦨 Code Smells · 🧪 Tests · 🧩 Design (Anti-)Patterns

🇫🇷🇨🇭 Comment évaluer la qualité d’un jeu de tests ? Le coverage ne suffit pas. Les tests de mutation n’attrapent que les erreurs triviales. Dans un papier de 2007, une équipe Franco-Suisse démontre que les odeurs des tests (Test Smells) sont un outil pertinent pour repérer les mauvais tests.

🦨 Les Test Smells sont les cousins des Code Smells, qui matérialisent des problèmes de qualité potentiels dans un code. Moins connus, ils n’en ont pas moins été jugés efficaces par la recherche et ce papier l’appuie. La plupart des Test Smells sont attachés à un Antipattern de test. Ainsi les odeurs peuvent aider à découvrir qu’un test est trop long, obscur ou erratique. Les chercheurs ont ainsi identifié 27 odeurs reliés à un ou plusieurs antipatterns.

✔️ Leur recherche visait à créer un outil automatisé de détection des tests. Ce faisant ils nous livrent des conclusions intéressantes en tant que praticiens :
👉 Les Test Smells sont fréquents et nettement reliés aux antipatterns.
👉 Plus un développeur écrit de tests, meilleurs ils sont.

Leur outil mériterait d’être adapté dans nos langages, mais rien ne remplacera jamais l’oeil du praticien entraîné !

SOURCE

Reichhart, Stefan, Tudor Gîrba and Stéphane Ducasse. “Rule-based Assessment of Test Quality.” J. Object Technol. 6 (2007): 231-251. DOI:10.5381/jot.2007.6.9.a12


DOIs: 10.5381/jot.2007.6.9.a12

Recovery, redemption, and extreme programming 🔗

🧮 Méthodes de développement

Extreme Programming peut (aussi) redresser des projets en perdition à condition de ne pas avoir une approche dogmatique et d’accepter des sacrifices. C’est l’essence du témoignage déjà ancien de Peter Schuh.

Le paysage a peu changé, d’après mon expérience en ESN ou en tant que freelance. Ce papier est toujours actuel.

P. Schuh, “Recovery, redemption, and extreme programming,” in IEEE Software, vol. 18, no. 6, pp. 34-41, Nov.-Dec. 2001, doi: 10.1109/52.965800.


DOIs: 10.1109/52.965800

Programming with abstract data types 🔗

💾 Histoire de l'informatique · 🔣 Science des Langages · #️⃣ Façonnage de code

👵 Tout développeur connaît les principes SOLID. Peu connaissent l’auteur du troisième : le Principe de Substitution de Barbara Liskov. Cette grande dame inventa le premier langage de programmation supportant l’abstraction. Autant dire qu’elle a pavé la voie aux langages de haut-niveau modernes.

📦 Son article de 1974 « Programming with abstract data types » est devenu un classique. Elle y détaille un paradigme de programmation, héritier de la programmation structurée de Dijkstra, dans lequel le développeur n’utilise pas directement les types fournis par le système. Ceux-ci sont encapsulés dans des types de plus haut-niveau, ne laissant filtrer que les détails pertinents du niveau précédent.

🎰 Ces types sont définis par les opérations que l’on peut réaliser sur eux (et non pas sur les données qu’ils contiennent !). Elle ne parle pas d’objet ou d’interface, concepts encore balbutiants à l’époque (Alan Kay travaille encore sur Smalltalk), mais l’idée est décidément dans l’air du temps.

3️⃣ Son paradigme présente trois énormes avantages, déjà identifiés dans le papier :
✔️ Protéger le développeur contre les erreurs d’inattention (additionner un int et un char par exemple).
✔️ Réduire la charge mentale* du développeur, qui peut se concentrer sur l’espace du problème sans se soucier des détails d’implémentation. Les types sont semblables aux oeillères des animaux de trait.
✔️ Rendre le programme plus facile à tester* : le jeu de tests* est divisé en deux parties indépendantes, l’une vérifiant l’implémentation, l’autre que l’abstraction est appelée correctement. Cette seconde partie doit ignorer tout de l’implémentation.

📝 Si la manière de concevoir des langages a vieilli (et donc la seconde partie du papier de Liskov), les principes fondamentaux sont toujours d’actualité, je ne peux qu’en conseiller la lecture.

* Ces termes n’existaient pas à l’époque

SOURCE

Liskov, Barbara and Stephen N. Zilles. “Programming with abstract data types.” SIGPLAN Notices 9 (1974): 50-59. DOI: 10.1145/800233.807045


DOIs: 10.1145/800233.807045

Organizing Programs Without Classes 🔗

🔣 Science des Langages · 💾 Histoire de l'informatique

😱 En 1986 naît la programmation orientée prototype, célèbre grâce à JavaScript. Paradoxalement, ce paradigme est relativement inconnu, voire fui par les développeurs JS qui préfèrent oublier son existence ! Quel échec pour celui qui était vu comme révolutionnaire en 1991, au sens littéral du terme : il visait l’abolition des classes.

🤳 Aujourd’hui un papier historique de 4 chercheurs de Stanford, dont David Ungar, le créateur de Self, premier langage orienté prototype.

🗑️ Les auteurs y défendent une thèse osée : les classes sont inutiles à la programmation orientée objet, voire même gênantes. Tout ce que font les classes peut être fait plus simplement par la copie de prototypes : héritage, composition, encapsulation, polymorphisme. Mieux, les prototypes apportent l’héritage dynamique et la modification du comportement hérité par les enfants.

🕵️ L’intérêt de ce papier est surtout historique, 30 ans après, un bilan s’impose :
❌ Les classes sont bien vivantes et les pratiques actuelles tendent vers des systèmes de typage de plus en plus forts.
❌ JavaScript vit sans assumer son paradigme historique (cocasse pour quelque chose de révolutionnaire), en témoigne le succès des diverses surcouches et frameworks (NodeJS, TypeScript, etc.).
❌ L’héritage dynamique n’a pas trouvé d’usage.
❌ La modification du comportement hérité est vue comme un antipattern en Orienté Objet car il brouille la compréhension.
❌ En dehors de LUA, tous les autres langages orienté prototype sont tombés dans l’oubli.
✔️ Le principal héritage de l’orienté prototype est l’idée de traits, présents dans la plupart des langages OO de nos jours, sous diverses formes.
✔️ La notion de délégué pourrait venir de l’orienté prototype mais son origine est plus floue.

🛑 Bien qu’élégante sur le papier, l’idée des langages a prototypes a souffert de sa courbe d’apprentissage exécrable, totalement incompatible avec la cible de son principal porte-drapeau : JS, le langage des débutants par excellence. Peu sont même au courant du paradigme auquel obéit ce langage. La plupart ont adopté les codes de la programmation fonctionnelle ou impérative lorsqu’ils programment en JS.

SOURCE

Chambers, Craig & Ungar, David & Chang, Bay-Wei & Hölzle, Urs. (1991). Organizing Programs Without Classes.. Lisp and Symbolic Computation. 4. 223-242. 10.1007/BF01806107.


DOIs: 10.1007/BF01806107

On the reliability of programs 🔗

💾 Histoire de l'informatique · 👌 Qualité logicielle

Notre profession a peu de mémoire, nous avons oublié Lehman, Royce ou Wirth et de Dijkstra, il ne reste que des citations.

« Les tests peuvent être utilisés pour démontrer la présence de bugs, jamais leur absence. »

« Tout morceau de code ou programme complet n’est un outil utile que si la documentation nécessaire à l’utilisateur est plus courte que le code. »

« Notre culture a déjà pour tradition séculaire une discipline intellectuelle dont le but premier est de structurer efficacement une complexité autrement ingérable. Les Mathématiques. »

Ces trois éclairs de génie sont tous issus du même papier (en anglais), que je vous invite à lire : On The Reliability Of Programs.

SOURCE

Dijkstra E., On the Reliability of Programs (EWD303)

On the effects of programming and testing skills on external quality and productivity in a test-driven development context 🔗

🧮 Méthodes de développement · 🧪 Tests · 🧑‍💼 Management

👶 « TDD c’est pour les devs chevronnés, j’ai une plâtrée de juniors, je préfère oublier. »
💪 « Le seul moyen de faire de la qualité c’est d’avoir des vieux devs barbus. »
Si avec une seule étude on débunkait tout ça ?

📐L’introduction est peut-être un peu putaclic, mais d’après les résultats qu’ont obtenu 3 chercheurs finlandais, les compétences seules d’un développeur n’ont pas de lien avec la qualité des logiciels qu’il produit. J’émets l’hypothèse que le contexte et les pratiques sont le facteur principal.

❓ Un junior peut donc produire un code de meilleure qualité qu’un senior, s’il est dans un bon environnement et respecte des pratiques reconnues. Où est le piège ?

👴 L’étude montre également que les compétences sont fortement corrélées avec la productivité d’un développeur. A qualité égale, le senior est plus performant.

📈 Et TDD dans tout ça ? Les chercheurs montrent une hausse de productivité chez tous les développeurs (ce qui vient ajouter un papier à ce débat très vif qui ne sera clos que par une méta-étude solide). Cette hausse est plus importante chez les développeurs ayant déjà de la pratique.

✔️ Cela colle avec mon expérience comme enseignant, TDD est compatible avec des étudiants. Cela ne signifie pas que ce soit simple à apprendre, mais que la hausse de productivité pourrait intervenir plus tôt que l’on ne croît.

Note de fin : l’étude comporte des biais, comme tout ce que je présente. Lisez pour vous faire votre propre idée.

SOURCE

Davide Fucci, Burak Turhan, and Markku Oivo. 2015. On the effects of programming and testing skills on external quality and productivity in a test-driven development context. In Proceedings of the 19th International Conference on Evaluation and Assessment in Software Engineering (EASE ’15). Association for Computing Machinery, New York, NY, USA, Article 25, 1–6. DOI:10.1145/2745802.2745826


DOIs: 10.1145/2745802.2745826

On the Criteria To Be Used in Decomposing Systems into Modules 🔗

📐 Architecture · #️⃣ Façonnage de code

🎺 « Si les développeurs chantaient des hymnes, le plus populaire serait l’hymne de la modularité » c’est ainsi que David Parnas commence son article « On the Criteria to be used in Decomposing Systems into Modules » en 1971. Un article que toute personne tentée par les microservices doit lire.

✂️ Après une démonstration, il conclut en priant les développeurs d’arrêter de découper leurs programmes à l’avance sur la base d’un organigramme. Cela ne fonctionne pas mieux en 2021 qu’en 1971. Il encourage plutôt à commencer par un monolithe, qui sera découpé au besoin lorsqu’une décision de design importante sera prise.

🔀 Cette décision sera masquée au programme principal, ce qui permet de n’avoir qu’un module à changer si cette décision s’avérait mauvaise et qu’il fallait prendre une autre voie.

SOURCE :

Parnas, David. (1972). On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM. 15. 1053-. 10.1145/361598.361623.


DOIs: 10.1145/361598.361623

La cybernétique à l’aune des sciences cognitives : une erreur scientifique ? 🔗

🥼 Épistémologie · 💾 Histoire de l'informatique

🏛️ C’est devenu un lieu commun au sein des sciences cognitives, de critiquer la cybernétique, dont la discipline est pourtant issue.
Marvin Minsky, un des fondateurs de l’IA, comme Hubert Dreyfus, son vieil adversaire s’accordent sur les fruits anecdotiques de la « science des systèmes auto-organisés » et sur son absence totale de résultats.

Pourtant, peut-on parler d’erreur scientifique ?

🇫🇷 Pour Mathieu Triclot, philosophe à l’université Lyon 3, oui et son papier utilise la cybernétique pour illustrer le concept d’erreur scientifique.

❌ La cybernétique n’est pas critiquée pour ses mauvais résultats, un scientifique qui se trompe n’est pas dans l’erreur, il participe à la science ! C’est bien l’absence de résultats malgré l’entêtement des cybernéticiens qui est en cause.

❌ Seconde accusation, que les cybernéticiens en soient conscients ou non, leur discipline s’est largement éloignée de la discipline scientifique jusqu’à se mettre en porte-à-faux avec plusieurs de ses règles.

❌ Dernière accusation : A force d’analogies mal cadrés entre des disciplines dissemblables, la cybernétique a fini par ressembler à une idéologie scientifique (Canguilhem). Elle n’a produit que des visions du monde, pas des des preuves scientifiques quelconques. Le propos ressemble à celui de Sokal et Bricmont dans leur célèbre livre.

✔️ Le papier a un intérêt pour nous : ne créons pas d’autres cybernétiques en montant en épingle un sujet de recherche par la seule force de la « hype ». L’interface homme-machine, l’homme augmenté, l’IA forte, la blockchain sont des sujets à risque.

SOURCES

Mathieu Triclot. La cybernétique à l’aune des sciences cognitives : une erreur scientifique ? . Journée d’études ”qu’est-ce qu’une erreur scientifique ?”, Université Lyon 3 Jean Moulin, May 2004, Lyon, France.

Sokal A., Bricmont J., Impostures Intellectuelles, 1997, Odile Jacob, Paris ISBN 978-2-7381-0503-5

Iterative and Incremental Development: A Brief History 🔗

💾 Histoire de l'informatique · 🧮 Méthodes de développement

Je pensais avant cet article que la maturité de notre profession avait été atteinte dans les années 70. Il n’en est rien. En 1958, on savait faire de bons logiciels, avec une méthode proche d’eXtrem Programming.
Le programme Mercury en témoigne.

63 ans de perdus, on continue ou on change nos pratiques ?

SOURCE

Craig Larman and Victor R. Basili. 2003. Iterative and Incremental Development: A Brief History. Computer 36, 6 (June 2003), 47–56. DOI:10.1109/MC.2003.1204375


DOIs: 10.1109/MC.2003.1204375

How soon will we learn these software engineering lessons ? 🔗

💩 Cas d'échecs · 💾 Histoire de l'informatique

Ce papier de 1979 constate que depuis 1961, le secteur du logiciel est incapable de réussir ses produits. En cause : délais déraisonnables, violation de la loi de Brooks, empilement de spécifications, management toxique, gestion de projet monobloc. En 2021 ? Rien n’a changé.

SOURCE

Barry W. Boehm, Software Engineering - As It Is (1979)

How do fixes become bugs ? 🔗

👌 Qualité logicielle

🐞 Certains bugs ne doivent surtout pas être résolus dans la précipitation, même s’ils bloquent une fonction vitale en production. Le risque que le hotfix soit un bug encore plus gros est bien trop grand.

C’est l’alerte levée par le papier, déjà ancien (2011) de Yin et al.

3️⃣ Ces familles de bugs tiennent en 3 lettres : CMS.
-Concurrency (Locks, Tasks, Sync, etc.)
-Memory (Allocation, Overflow, Pointers, etc.)
-Semantic (Application-specific)
Respectivement 40%, 14% et 17% des patchs devant résoudre ces bugs sont eux-mêmes buggés !

🔒 Pire, sur les verrous, sujet très dangereux en développement, les chercheurs ont noté que 14% des patchs venant corriger un bug introduit par un autre patch sont eux-mêmes buggés !

🧠 Testez vos bugs, Defect Testing évite énormément de problèmes sur ces sujets où nos cerveaux sont dépassés par la complexité du code.
SOURCE :

Zuoning Yin, Ding Yuan, Yuanyuan Zhou, Shankar Pasupathy, and Lakshmi Bairavasundaram. 2011. How do fixes become bugs? In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering (ESEC/FSE ’11). Association for Computing Machinery, New York, NY, USA, 26–36. DOI: 10.1145/2025113.2025121


DOIs: 10.1145/2025113.2025121

Exploring the Influence of Identifier Names on Code Quality: An Empirical Study 🔗

🗣️ Nommage

Un nommage inadapté obscurcit le code, c’est entendu. Mais plus surprenant, un nommage inadapté est également un bon moyen de détecter les morceaux de code les plus buggés. Une équipe anglaise a établi une forte corrélation entre code mal fichu et nommage aux fraises.

🔙 Les chercheurs ne nous disent pas si un lien de cause à effet existe. J’émets pour ma part deux hypothèses :

🕸️ Hypothèse 1 : Dans un code mal nommé, les bugs ont plus d’endroits où se cacher.

🐖 Hypothèse 2 : Il faut chercher une cause commune en la personne du développeur incompétent. Celui qui nomme mal est aussi celui qui teste peu et laisse derrière lui beaucoup de bugs.

🧪 Si des chercheurs avancent sur le sujet, je vous ferai part des résultats !

SOURCE

Butler, Simon & Wermelinger, Michel & Yu, Yijun & Sharp, Helen. (2010). Exploring the Influence of Identifier Names on Code Quality: An Empirical Study. Proceedings of the Euromicro Conference on Software Maintenance and Reengineering, CSMR. 10.1109/CSMR.2010.27.


DOIs: 10.1109/CSMR.2010.27

Effective identifier names for comprehension and memory 🔗

🗣️ Nommage · 🧠 Psychologie

🔤 On ne répétera jamais assez l’importance du nommage en développement. 70% du code est constitué d’identifiants qui, s’ils sont ésotériques, grèvent la vélocité des développements. Comment ? Deux papiers nous l’expliquent.

🧠 Le premier, rédigé en 2011 par un Italien et un Américain, met en évidence l’effet négatif des odeurs lexicales sur la localisation des concepts. Ce terme désigne le processus par lequel notre cerveau tente de mapper un artefact du code avec un concept (métier ou technique qu’il connaît), afin de comprendre sa place dans la logique globale.

❌ Des odeurs comme les abréviations excessives, les termes vagues, inconsistants, mal orthographiés ou employés brouillent les capacités de localisation des concepts.

📏 Le second, rédigé en 2007 par une équipe Britannique, fait le lien entre longueur des identifiants et mémoire. Il indique que les identifiants trop longs sont aussi néfastes que ceux trop courts. Des abréviations raisonnables sont meilleures que des identifiants complets si ces derniers sont trop longs.

♀️ Un élément surprenant est la plus grande capacité des femmes à retenir des abréviations.

🔎 Ni trop court, ni trop long, mais toujours d’une clarté irréprochable semble une bonne règle pour les identifiants.

SOURCES

Abebe, Surafel Lemma, Sonia Haiduc, Paolo Tonella and Andrian Marcus. “Lexicon Bad Smells in Software.” 2009 16th Working Conference on Reverse Engineering (2009): 95-99. DOI:10.1109/WCRE.2009.26

Lawrie, D., Morrell, C., Feild, H. et al. Effective identifier names for comprehension and memory. Innovations Syst Softw Eng3, 303–318 (2007). DOI:10.1007/s11334-007-0031-2


DOIs: 10.1109/WCRE.2009.26 · 10.1007/s11334-007-0031-2

Don't touch my code ! Examining the effects of ownership on software quality 🔗

🧠 Psychologie · 🧮 Méthodes de développement

✅ La propriété collective du code (Collective Code Ownership, CCO) est une pratique voulant que chaque développeur se sente légitime pour modifier n’importe quelle partie du projet. C’est un modèle à forte appartenance de groupe. Établir une règle ne suffit pas, il faut lever des barrières psychologiques soulignées par la recherche.

CCO a un effet bénéfique direct sur plusieurs indicateurs :

1️⃣ La résilience, ça n’est pas pour rien que CCO fait partie du Sustainable Software Development. J’en parle ici : Sustainable Software Development through Overlapping Pair Rotation

2️⃣ La simplicité du code. Quand l’équipe n’arrive plus à connaître tout le code collectivement, CCO provoque un malaise facile à ressentir par les développeurs. Il est peut-être temps de faire le tri ou de diviser le projet en morceaux.

3️⃣ La taille de l’équipe. Quand l’équipe devient trop grande, la rotation des paires est mathématiquement impossible. Tant mieux, une équipe de développement semble psychologiquement limitée à 7 personnes.

4️⃣ L’intégration. CCO intègre mieux et plus vite les nouveaux développeurs. Pas besoin de phase d’intégration longue et improductive, le développeur fait son travail dès le premier jour, guidé par un collègue.

5️⃣ Les vitres brisées. C’est un cycle vertueux. Si tout le monde se sent impliqué, personne ne laissera de problèmes non résolus « à d’autres ». La dette technique s’accumulera moins. Le produit sera de meilleure qualité. Les développeurs s’y identifieront plus et en seront fiers. Donc ils seront plus impliqués. Etc.

📅 Je termine la série demain avec la mise en place du CCO et les barrières à lever.

SOURCES

Christian Bird, Nachiappan Nagappan, Brendan Murphy, Harald Gall, and Premkumar Devanbu. 2011. Don’t touch my code! examining the effects of ownership on software quality. In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering (ESEC/FSE ’11). Association for Computing Machinery, New York, NY, USA, 4–14. DOI:10.1145/2025113.2025119


DOIs: 10.1145/2025113.2025119

Designing Software for Ease of Extension and Contraction 🔗

📜 Lois du développement · #️⃣ Façonnage de code · 📐 Architecture

👴 Je continue de découvrir l’immense David Parnas, au travers d’un second article, sur la manière de concevoir des logiciels afin qu’ils soient facile à étendre et à réduire selon les impératifs client. Il date de 1979, c’est l’information la plus dingue vu l’actualité du papier.

Règles de design

📜 Parnas donne 4 règles permettant de garder une grande souplesse dans le design des logiciels :

1️⃣ Commencer par un monolithe. Créer un module à chaque décision de design importante afin d’encapsuler cette décision et de rendre facile le changement si elle s’avérait peu judicieuse.

2️⃣ Lister les éléments qui sont susceptibles de changer. S’assurer qu’ils sont absents des interfaces des modules que l’on conçoit.

3️⃣ Ne pas subdiviser son programmes en étapes d’un traitement. Privilégier la conception par « machines virtuelles », où chaque module masque la complexité de la couche inférieure en ne laissant filtrer que ce qui est utile à des tâches plus élevées.

4️⃣ Ne créer de dépendances que si elles sont utiles. Parnas entend par là que :
1) A est plus simple parce qu’il utilise B.
2) B n’est pas plus complexe si A l’utilise.
3) Il existe un programme utile incluant B, mais pas A
4) Il n’y a aucun programme utile contenant A, mais pas B.

Coûts de fonctionnement et de changement

💻 Nous connaissons tous la dynamique qui lie mémoire et CPU, de sorte que toute optimisation de l’un coûte de l’autre.
Le même type de relation existe entre coût de fonctionnement et coût du changement. Je reviens sur le papier de Parnas posté il y a une semaine, car il révèle des trésors nouveaux à chaque lecture.

📏 Un logiciel générique diffère d’un logiciel flexible. Le premier répond à plusieurs cas d’usage sans changement, alors que le second ne répond qu’à un cas d’usage mais peut être facilement adapté pour en couvrir d’autres.

👉 La généricité a un surcoût de fonctionnement (le logiciel est forcément plus gros), mais un coût de changement nul.

👉 La flexibilité a n’a aucun surcoût de fonctionnement, mais possède un coût de changement dépendant de la qualité de l’implémentation.
💰 Le choix entre généricité et flexibilité est (normalement) purement stratégique et économique. Ce qu’un logiciel gagne d’un côté il le perd de l’autre. C’est une conséquence probablement indépassable de la VIIIème loi de Lehman : dans ce complexe d’interactions homme-machine, tout est gouverné par des boucles de rétroaction.

SOURCE

Parnas, David. (1979). Designing Software for Ease of Extension and Contraction. Software Engineering, IEEE Transactions on. SE-5. 128- 138. 10.1109/TSE.1979.234169.


DOIs: 10.1109/TSE.1979.234169

Coverage is not strongly correlated with test suite effectiveness 🔗

🧪 Tests

🔬Arrêtez de scruter la couverture de vos tests ! C’est une perte de temps. Laura Inozemtseva et Reid Holmes ont sorti en 2014 un papier qui l’affirme, mais confirme aussi les résultats de nombreux autres chercheurs : une faible couverture prouve que les tests sont mauvais. Une forte couverture ne prouve pas qu’ils sont bons.

🎯 On retrouve ici une situation où la Loi de Goodhart s’applique : plus vous prenez le coverage comme un objectif, plus vous vous plantez.

Comment s’assurer d’avoir de bons tests ? En remettant le coverage à sa place.
✔️ Comparer le coverage actuel et le coverage précédent avant chaque commit permet de voir si le développeur n’a pas oublié de tester son code.
✔️ Sous les 80%, le coverage indique une forte dette de tests.
❌ Au-dessus de 80% la coverage ne signifie rien d’utile et le suivre peut même coûter cher, en augmentant artificiellement la taille du jeu de tests, qu’il faudra ensuite maintenir.
❌ Les méthodes de calcul du coverage longues ou élaborées n’ont pas démontré leur utilité. Allez au plus simple, si vous utilisez correctement le coverage, ça suffira.

SOURCES

Laura Inozemtseva and Reid Holmes. 2014. Coverage is not strongly correlated with test suite effectiveness. In Proceedings of the 36th International Conference on Software Engineering (ICSE 2014). Association for Computing Machinery, New York, NY, USA, 435–445. DOI:10.1145/2568225.2568271


DOIs: 10.1145/2568225.2568271

Concise and consistent naming 🔗

🗣️ Nommage

🇩🇪 Hier, j’ai parlé de nommage, sans définir comment obtenir des noms clairs. Ça tombe bien, j’ai déniché un papier de 2006 écrit par deux Allemands. Fidèles à leur tradition, ils donnent deux lignes de conduite : concision et consistance.

⚠️ Le papier est très dense, je vous en recommande la lecture, ce post ne fera que de le survoler.

⭐ La règle d’or : il doit exister une relation bijective entre les concepts manipulés et les noms utilisés. Pas de polysèmes, pas d’homonymes. Dédicace à mon vieux prof de MERISE Patrice LECUONA.

🥈 Règle n°2 : la consistence. Il faut éviter les homonymes et les synonymes, ainsi que toutes les figures de style qui font un bon poème. Lorsque l’on compose un identifiant en mêlant plusieurs concepts, ces derniers doivent exister dans le vocabulaire du projet et la relation parent-enfant doit être légitime.

🥉 Règle n°3 : la concision. Pas d’ajouts. Un identifiant doit reprendre le nom du concept qu’il contient, sans préfixes et autres rajouts dont les développeurs sont friands. Si l’identifiant désigne un type particulier d’un concept, le nom doit en être le reflet clair.

Le papier ne s’arrête pas à cela, il donne d’autres recommandations et conseils très utiles, ainsi que les ressorts psychologiques à l’oeuvre. Par souci de concision, je ne détaille pas plus et vous invite à le lire.

SOURCE

Deissenboeck, F., Pizka, M. Concise and consistent naming. Software Qual J14, 261–282 (2006). DOI: 10.1007/s11219-006-9219-1


DOIs: 10.1007/s11219-006-9219-1

Characterizing the Relative Significance of a Test Smell 🔗

🧪 Tests

🇧🇪 En travaillant sur un outil de détection des odeurs de test (Test Smells), 3 chercheurs belges ont produit une synthèse rigoureuse et claire de ce qu’est un bon test.

✅ Premier apport : ils ont synthétisé 9 critères depuis la littérature académique : Consistance, Nécessité, Maintenabilité, Répétabilité, Auto-validation, Isolation, Concision, Robustesse, Rapidité, Automatisation et Persistance.

✅ Second apport, ils proposent un méta-modèle décrivant la place des tests dans un système logiciel. Ce méta-modèle compte 8 concepts contraints par 9 définitions, exprimées informellement en langage naturel et formellement en notation mathématique.

🧭 C’est un excellent support de formation, mais également une lecture intéressante pour toute personne cherchant à raffiner ses tests.

SOURCE

Van Rompaey, Bart & Du Bois, Bart & Demeyer, Serge. (2006). Characterizing the Relative Significance of a Test Smell. 391-400. 10.1109/ICSM.2006.18.


DOIs: 10.1109/ICSM.2006.18

Analyses of Regular Expression Usage in Software Development 🔗

🎓 Thèse · #️⃣ Façonnage de code

Les expressions régulières (Regex) sont massivement utilisées, mais très peu testées car difficilement testables, donc d’une fiabilité douteuse.

Cette conclusion est celle de la thèse (2021) de Peipei Wang, une doctorante en informatique de Caroline du Nord.

Je conseille aux non-chercheurs la lecture des chapitres 1, 3, 4, 5.

Vous y apprendrez que :
-Dans la réalité, personne ne teste ces $*x% de regex (17% sur les projets open-source étudiés).
-Elles sont une importante source de bugs vicieux.
-Elles sont encore imparfaitement portables à travers les langages.
-Les outils pour correctement les tester sont encore peu diffusés (Rex pour ne citer que lui). Elles sont encore trop testées simplement par branch coverage ou statement coverage, ce qui est erroné.
-Les développeurs en ont peur et y touchent très rarement dans leur code. Lorsqu’ils y sont contraints (bug ou évolution), ile préfèrent les supprimer et les remplacer par un parser (ce qui n’est pas toujours une mauvaise solution d’ailleurs).

https://repository.lib.ncsu.edu/handle/1840.20/39015

Adoption challenges of CI/CD methodology in software development teams 🔗

🧮 Méthodes de développement

🔃L’intégration et le déploiement continus (CI/CD) ont du mal à entrer efficacement dans les pratiques des entreprises. Un professeur Sri Lankais analyse pourquoi et donne des pistes d’amélioration.

👉 En premier, l’équipe. Elle doit maîtriser un ensemble de pratiques comme les tests automatisés ou DevOps. Elle doit communiquer correctement et être capable de livrer régulièrement. Ce n’est souvent pas le cas, surtout si l’équipe est sous pression.

👉En second, de peu, le soutien des parties-prenantes. Un pipeline de CI/CD n’a aucun impact sur la productivité à court-terme et peut même ralentir les développements. C’est donc un investissement, qui doit être compris et accepté comme tel par tout le monde.

👉Sur la dernière marche du podium, le poids de l’existant. Un existant intestable ou compliqué à build changera le parcours d’adoption des outils de CI/CD en véritable enfer.

❗ Le premier comme le troisième point sont très dépendants du second. Si les parties prenantes acceptent d’investir sérieusement dans un démarche de CI/CD, alors elles mettront les moyens pour désendetter le code et former les équipes.

La balle n’est pas dans le camp des développeurs, même avec la meilleure volonté du monde.

SOURCE

Rajasinghe, Maneka (2021): Adoption challenges of CI/CD methodology in software development teams. TechRxiv. Preprint. DOI:10.36227/techrxiv.16681957.v1


DOIs: 10.36227/techrxiv.16681957.v1

A New Family of Software Anti-Patterns: Linguistic Anti-Patterns 🔗

🧩 Design (Anti-)Patterns · #️⃣ Façonnage de code · 🗣️ Nommage

👅Le code n’est pas écrit pour les machines, qui se contentent de signaux électriques, mais pour les humains ! Il est donc normal de retrouver des antipatterns linguistiques et autres dettes de langage dans un code.

4 chercheurs ont tenté de classifier les antipatterns linguistiques dans le code. Ils ont trouvé 6 familles, 3 pour les attributs, 3 pour les méthodes.
1) Les méthodes qui font plus qu’elles ne disent (effets de bord).
2) Les méthodes qui disent plus qu’elles ne font.
3) Les méthodes qui font l’opposé de ce qu’elles disent.
4) Les attributs dont le nom promet plus qu’ils ne contiennent
5) Les attributs qui contiennent plus que ce que promet leur nom
6) Les attributs qui contiennent l’opposé de ce qu’indique leur nom

Ces familles contiennent des antipatterns, comme ces Get impurs qui sont bien plus que des accesseurs, ces ‘IsX’ qui renvoient autre chose qu’un booléen, ces commentaires qui contredisent ce qu’ils illustrent ou encore ces méthodes de transformation qui ne retournent rien.

Bien entendu leur travail n’est qu’un premier pas, il existe de nombreux autres antipatterns, sur les noms des classes par exemple. Mais il a le mérite de lancer le sujet, inexploré avant eux.

SOURCE

Arnaoudova, Venera & Di Penta, Massimiliano & Antoniol, Giuliano & Guéhéneuc, Yann-Gaël. (2013). A New Family of Software Anti-Patterns: Linguistic Anti-Patterns. Proceedings of the European Conference on Software Maintenance and Reengineering, CSMR. 10.1109/CSMR.2013.28.


DOIs: 10.1109/CSMR.2013.28

A Brief History of Software Engineering 🔗

💾 Histoire de l'informatique

👴 Mes lectures de la semaine ont été bien plus historiques et sapientiales que scientifiques. Aujourd’hui, un brève histoire du logiciel de Niklaus Wirth.

🧪 Dans ce papier désabusé et volontiers sarcastique, l’auteur retrace son expérience du développement depuis les années 60. C’est décapant, mais non moins juste.

N. Wirth, “A Brief History of Software Engineering,” in IEEE Annals of the History of Computing, vol. 30, no. 3, pp. 32-39, July-Sept. 2008, doi: 10.1109/MAHC.2008.33.


DOIs: 10.1109/MAHC.2008.33

Factors Limiting Industrial Adoption of Test Driven Development: A Systematic Review 🔗

🧪 Tests · 🧑‍💼 Management

🇸🇪 TDD est bénéfique pour la qualité, j’en ai déjà parlé ici. Quels sont donc les facteurs qui limitent son adoption en entreprise ? Il y en a 7 selon 3 chercheurs suédois.

🐌 Sa lenteur en temps de développement initial. A nuancer, car TDD est plus rapide si l’on prend en compte le temps de maintenance dans le calcul.

🧠 Le manque de connaissances sur TDD, renforcé par sa contre-productivité entre les mains de novices.

📐 La légende voulant que TDD ne permette pas de design. Elle n’a jamais été étayée par la recherche ou par l’expérience des praticiens, pourtant elle reste ancrée dans la tête des managers.

🗜️ Le manque de compétences en tests. En effet, TDD requiert des développeurs qui savent déjà (bien) tester. Ce n’est pas souvent le cas en entreprise. La bonne nouvelle, c’est que l’on peut apprendre directement avec TDD.

🧲 De mauvaises implémentations de TDD, alors que l’on sait que TDD doit être correctement appliqué pour présenter des bénéfices clairs.
❌ Des limitations propres au domaine ou aux outils. Il est par exemple très difficile de tester des GUI en TDD.

🗑️ La présence de Code Legacy, que TDD ne sait pas traiter (il faut d’autres techniques pour ça).

💩 En conclusion : apprendre TDD n’améliore pas les performances à court terme et peut même les gréver. Il n’est pas possible de faire du « demi-TDD » sans en perdre tout l’intérêt. TDD est un investissement lourd qui ne paie qu’à long terme. Soit, selon Niklaus Wirth, l’inverse de la tendance de l’industrie depuis les années 70.

👉 Sans courage managérial, il ne faut attendre aucun bénéfice de TDD.

SOURCE

Causevic, Adnan & Sundmark, Daniel & Punnekkat, Sasikumar. (2011). Factors Limiting Industrial Adoption of Test Driven Development: A Systematic Review. Proceedings – 4th IEEE International Conference on Software Testing, Verification, and Validation, ICST 2011. 337-346. 10.1109/ICST.2011.19.


DOIs: 10.1109/ICST.2011.19

TDD est facile à enseigner 🔗

🧪 Tests · 🧑‍🏫 Pédagogie

🎓 Enseigner TDD au étudiants dès le premier cours sur les tests donne des résultats encourageants ! C’est même moins difficile que de l’enseigner à des développeurs habitués à une démarche Test-Last.

🇺🇸 L’étude vient des U.S.A et compare deux groupes d’étudiants, l’un suivant la logique TDD, l’autre une démarche Test-Last plus classique. Ces étudiants n’ont jamais testé avant et ont été formés à cela en début d’expérience.

👻 Les chercheurs montrent que chez des novices, pratiquer TDD lève les peurs au sujet de cette méthode. L’apprentissage n’est pas plus difficile que celui d’une démarche Test-Last et les étudiants sont plus productifs. Aucun changement concernant la qualité du code n’est perceptible.

🍼 Cela rejoint mon expérience en formation : il est plus difficile de former à la mentalité TDD des développeurs pratiquant en Test-Last que des cerveaux vierges. L’apprentissage de TDD étant la principale barrière empêchant la pratique de se répandre, former « dès le berceau » semble présenter des avantages nets.

SOURCES

D. S. Janzen and H. Saiedian, « On the Influence of Test-Driven Development on Software Design, » 19th Conference on Software Engineering Education & Training (CSEET’06), 2006, pp. 141-148, doi: 10.1109/CSEET.2006.25.

Causevic, Adnan & Sundmark, Daniel & Punnekkat, Sasikumar. (2011). Factors Limiting Industrial Adoption of Test Driven Development: A Systematic Review. Proceedings – 4th IEEE International Conference on Software Testing, Verification, and Validation, ICST 2011. 337-346. 10.1109/ICST.2011.19.


DOIs: 10.1109/ICST.2011.19 · 10.1109/CSEET.2006.25

Two Meta-Analysises 🔗

🤝 Pair Programming · 🧪 Tests

🔍 Les Méta-Analyses, plus haut niveau de preuves en science, sont assez rares en qualité logicielle. J’en ai une sur l’efficacité de TDD et l’autre sur le Pair Programming. Analysons-les ensemble.

⚠️ Ces deux analyses se rejoignent sur l’absence de standardisation des concepts étudiés et de la manière de les étudier, ce qui rend compliquée l’isolation des variables. Il est donc compliqué de conclure, sauf à avoir de très nombreuses études source.

❓ Rappel : « non concluant », « ne prouve rien » et autres formules de ce style signifient que rien ne peut être conclu. Ni l’efficacité, ni l’inefficacité.

🤝 Sur Pair Programming, des conclusions surprenantes : il est plus rapide d’être deux sur des tâches simples, mais la qualité va baisser. Sur des tâches complexes, être deux produira un meilleur code, au prix d’une baisse de productivité.
C’est contre-intuitif autant pour les partisans que pour les détracteurs de pair-programming. Cela signifierait que si la qualité compte, il est mieux de laisser les développeurs seuls sur les tâches simples. Si c’est la productivité qui compte, il faut pairer sur les plus triviales !

☑️ Sur TDD, il a un effet positif sur la qualité d’autant plus grand que la tâche est grande, en revanche, il n’a aucun résultat concluant sur la productivité. Ce résultat est plus appuyé dans l’industrie (probablement car les développeurs ont plus de bouteille qu’à l’université) et quand d’autres pratiques d’XP sont utilisées avec TDD.

🕰️ Sur ces deux sujets, les chercheurs déplorent l’absence de papiers sur les effets long-terme de ces deux techniques.

SOURCES
Y. Rafique and V. B. Mišić, « The Effects of Test-Driven Development on External Quality and Productivity: A Meta-Analysis, » in IEEE Transactions on Software Engineering, vol. 39, no. 6, pp. 835-856, June 2013, doi: 10.1109/TSE.2012.28.

Jo E. Hannay, Tore Dybå, Erik Arisholm, Dag I.K. Sjøberg, The effectiveness of pair programming: A meta-analysis, Information and Software Technology, Volume 51, Issue 7, 2009, Pages 1110-1122, ISSN 0950-5849, DOI:10.1016/j.infsof.2009.02.001


DOIs: 10.1109/TSE.2012.28 · 10.1016/j.infsof.2009.02.001

Are mutants a valid substitute for real faults in software testing 🔗

🧪 Tests

👾 Les indicateurs classiques de couverture du code ne sont pas corrélés à l’efficacité des tests*. En revanche, le score de mutation l’est significativement, pour un effort de tests moindre. Pourtant, malgré des outils efficaces, la mutation n’est pas une pratique courante en développement.

🔧 Ils se nomment Stryker en .NET, PIT ou Jumble en Java, mais tous les grands langages possèdent un outil de mutation simple d’utilisation. Les CPU modernes ainsi que les langages intermédiaires (MS IL, Bytecode) rendent ces outils suffisamment rapides pour les faire tourner avant chaque commit en mode partiel, et à chaque intégration en mode complet. Pourtant ils demeurent largement méconnus des développeurs.

🪄 Il ne s’agit pas d’une technique parfaite (No Silver Bullet, rappelez-vous). Ils ne détectent que les bugs issus du code, pas les problèmes d’algorithmique et les effets de bord complexes, mais c’est déjà énorme vu le très faible investissement qu’ils représentent.

💻 Intégrés dans un IDE ou dans une plateforme de CI, ils dévoilent tout leur potentiel et sont le complément parfait de TDD. Essayez, vous serez rapidement conquis !

* Voir le post d’il y a 6 jours : Coverage is not strongly correlated with test suite effectiveness

SOURCES

N. Li, U. Praphamontripong and J. Offutt, « An Experimental Comparison of Four Unit Test Criteria: Mutation, Edge-Pair, All-Uses and Prime Path Coverage, » 2009 International Conference on Software Testing, Verification, and Validation Workshops, 2009, pp. 220-229, doi: 10.1109/ICSTW.2009.30.

René Just, Darioush Jalali, Laura Inozemtseva, Michael D. Ernst, Reid Holmes, and Gordon Fraser. 2014. Are mutants a valid substitute for real faults in software testing? In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2014). Association for Computing Machinery, New York, NY, USA, 654–665. DOI:10.1145/2635868.2635929


DOIs: 10.1109/ICSTW.2009.30 · 10.1145/2635868.2635929

Une revue sur les odeurs du code 🔗

🦨 Code Smells · 🧩 Design (Anti-)Patterns

🦨 Odeur du code ! Antipattern ! Si le capitaine Haddock était développeur, il abuserait sans doute d’un tel vocabulaire. Mais qu’en est-il de la recherche ? Ces notions sont-elles pertinentes, ou juste des caprices de développeurs ?

📝 J’ai récupéré 5 papiers, écrits entre 2009 et 2013, qui en parlent. Pour être d’accord sur la définition, une odeur du code est une indication d’un potentiel problème plus profond, l’antipattern. Fowler, qui a inventé le terme, différencie bien les deux. L’antipattern est une mauvaise solution clairement identifiée. L’odeur est un indice, ne menant pas toujours à un antipattern. Et tous les antipatterns ne « sentent » pas, certains ne sont visibles que via une analyse poussée.

🐛 Dans la littérature, les classes porteuses d’odeurs sont en général plus défectueuses et moins compréhensibles que les autres.
Cependant, les études se contredisent sur leur résistance et leur exposition au changement, qui s’explique au moins partiellement par leur plus grande taille, une variable mieux corrélée que le nombre d’odeurs à ces indicateurs.

💣 Les antipatterns sont moins étudiés, mais semblent corrélés à un plus grand nombre d’erreurs et une plus grande exposition au changement. En d’autres termes, ils changent plus souvent et leurs changements sont plus véreux que la moyenne.

🔄 La recherche montre également que toutes les odeurs ne se valent pas, certaines sont faiblement corrélées à des antipatterns, d’autres très fortement.

✔️ En résumé, les code smells indiquent bien quelque chose sur la qualité du code, mais ils ne peuvent pas se passer d’une analyse des développeurs ! Fowler a vu juste, comme souvent.

SOURCES

D. I. K. Sjøberg, A. Yamashita, B. C. D. Anda, A. Mockus and T. Dybå, “Quantifying the Effect of Code Smells on Maintenance Effort,” in IEEE Transactions on Software Engineering, vol. 39, no. 8, pp. 1144-1156, Aug. 2013, doi: 10.1109/TSE.2012.89.

Steffen M. Olbrich, Daniela S. Cruzes, and Dag I. K. Sjoberg. 2010. Are all code smells harmful? A study of God Classes and Brain Classes in the evolution of three open source systems. In Proceedings of the 2010 IEEE International Conference on Software Maintenance. DOI:10.1109/ICSM.2010.5609564

Bavota, Gabriele & Qusef, Abdallah & Oliveto, Rocco & Lucia, Andrea & Binkley, David. (2012). An empirical analysis of the distribution of unit test smells and their impact on software maintenance. IEEE International Conference on Software Maintenance, ICSM. 56-65. 10.1109/ICSM.2012.6405253

F. Khomh, M. Di Penta and Y. Gueheneuc, « An Exploratory Study of the Impact of Code Smells on Software Change-proneness, » 2009 16th Working Conference on Reverse Engineering, 2009, pp. 75-84, doi: 10.1109/WCRE.2009.28.

Li, Wei and Raed Shatnawi. “An empirical study of the bad smells and class error probability in the post-release object-oriented system evolution.” J. Syst. Softw. 80 (2007): 1120-1128. DOI:10.1016/j.jss.2006.10.018


DOIs: 10.1109/TSE.2012.89 · 10.1109/ICSM.2012.6405253 · 10.1109/WCRE.2009.28 · 10.1109/ICSM.2010.5609564 · 10.1016/j.jss.2006.10.018

Localisation des concepts et langage métier 🔗

🧠 Psychologie · 🗣️ Nommage

🧠 Connaissez-vous le principe de localisation des concepts (Concept Location) ? Il s’agit d’une notion à la frontière de la psychologie et de l’informatique, qui désigne l’acte de retrouver le code implémentant un concept donné dans un programme. Une localisation efficace augmente grandement la productivité des développeurs.

🗣️ La principale difficulté est l’écart entre le langage naturel utilisé pour exprimer le concept et la terminologie utilisée dans le code. Plus le code est rédigé dans un langage proche du métier, plus la localisation des concepts est aisée.

👓 La connaissance du code par le développeur facilite évidemment la localisation, plus la compréhension du code par les développeurs est étendue, plus la localisation est rapide.

🧪 Enfin, des tests placés au bon niveau d’abstraction aident évidemment à repérer les concepts facilement.

🔥 Je ne peux que recommander le combo DDD+ATDD+Architecture criante pour maximiser la productivité sur des projets où le nombre de concepts est important.

SOURCES

Evans E., Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, ISBN: 0-321-12521-5

Marcus, Andrian & Sergeyev, A. & Rajlich, Vaclav & Maletic, J.I.. (2004). An information retrieval approach to concept location in source code. Proceedings – Working Conference on Reverse Engineering, WCRE. 214 – 223. 10.1109/WCRE.2004.10.


DOIs: 10.1109/WCRE.2004.10

An Exploratory Study of Factors Influencing Change Entropy 🔗

📜 Lois du développement · 👌 Qualité logicielle

🔀 L’entropie de Shannon, désigne la quantité d’informations qu’une source émet, donc l’incertitude concernant ce qu’elle va émettre. De même, l’entropie d’un logiciel mesure le niveau de complexité d’un code, donc son incertitude.

🔬 L’idée d’appliquer l’entropie de Shannon comme mesure logicielle vient de Warren Harrison, dans un papier de 1992. L’idée a fait du chemin, jusqu’à devenir un Leprechaun, comme à l’accoutumée.

🤌 Aujourd’hui, un papier publié en 2010 par 4 Italiens, qui analyse les facteurs qui influencent l’entropie du logiciel.

➕Le refactoring semble être le seul moyen de juguler l’entropie, voire de la réduire.
➖Plus il y a de développeurs successifs sur un morceau de code, plus l’entropie augmente vite.
〰️L’usage de patterns n’a aucun effet sur la progression de l’entropie.

SOURCES

C. E. Shannon, A Mathematical Theory of Communication, Bell system Technical Journal, 1948, DOI:10.1002/j.1538-7305.1948.tb01338.x

Harrison, Warren. “An Entropy-Based Measure of Software Complexity.” IEEE Trans. Software Eng. 18 (1992): 1025-1034. DOI:10.1109/32.177371

G. Canfora, L. Cerulo, M. Di Penta and F. Pacilio, « An Exploratory Study of Factors Influencing Change Entropy, » 2010 IEEE 18th International Conference on Program Comprehension, 2010, pp. 134-143, doi: 10.1109/ICPC.2010.32.


DOIs: 10.1109/ICPC.2010.32 · 10.1109/32.177371 · 10.1002/j.1538-7305.1948.tb01338.x

Qu'est-ce que l'appartenance du code ? 🔗

🧠 Psychologie · 🧮 Méthodes de développement

🔏 L’appartenance du code désigne le sentiment de responsabilité d’un développeur ou d’une équipe sur un morceau de code. Une forte appartenance est corrélée avec un plus faible nombre de défauts.

⛓️ La forte appartenance désigne un modèle où un code est presque exclusivement édité par ses contributeurs majeurs, à savoir des développeurs s’identifiant comme experts sur cette partie précise du logiciel.
Elle s’oppose à la faible appartenance, où la part des modifications réalisées par des contributeurs mineurs est grande.
Il existe également un phénomène de non-appartenance, désignant l’abandon de parties entières du code, assimilable au code legacy.

🪲 Dans leur étude de 2011, Bird et al. démontrent qu’un modèle de faible appartenance provoque plus de défauts, principalement à cause du manque de connaissance métier des contributeurs mineurs. La littérature précédente appuie ce point : la productivité d’un développeur dépend bien plus de la connaissance du métier de de son expérience précédente.

🧠 Sedano et al. reprennent ces résultats en prenant en compte les critiques de Brendan Murphy : le lien entre qualité et appartenance n’est pas seulement causé par la connaissance du métier, mais également par la psychologie. Un développeur ayant le sentiment d’être responsable d’un code y prêtera plus d’attention car il s’y identifiera (Quality with a Name).

📐 Délimiter arbitrairement des « parties du code » et nommer des responsables n’a qu’un effet très marginal sur la qualité et augmente le Facteur Bus, donc le risque projet !

✔️ Combattre l’apathie logicielle suppose la compréhension des ressorts psychologiques derrière le sentiment d’appartenance. Ultimement, Sedano et al. défendent la propriété collective du code comme une pratique vertueuse, mais la démonstration est pour demain !

— SOURCES —

Todd Sedano, Paul Ralph, and Cécile Péraire. 2016. Practice and perception of team code ownership. In Proceedings of the 20th International Conference on Evaluation and Assessment in Software Engineering (EASE ’16). Association for Computing Machinery, New York, NY, USA, Article 36, 1–6. DOI:10.1145/2915970.2916002

Christian Bird, Nachiappan Nagappan, Brendan Murphy, Harald Gall, and Premkumar Devanbu. 2011. Don’t touch my code! examining the effects of ownership on software quality. In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering (ESEC/FSE ’11). Association for Computing Machinery, New York, NY, USA, 4–14. DOI:10.1145/2025113.2025119

B. Murphy Code ownership more complex to understand than research implies. Software, IEEE, 32(6):19, Nov 2015

J. Shore, Quality With a Name, 2006


DOIs: 10.1145/2025113.2025119 · 10.1145/2915970.2916002