Catégories
Revue académique

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

🍟 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.

#programmation #developpement #qualité #standards #science

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. ⟨hal-00848830⟩

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.

Catégories
Revue académique

Assessing the Value of Coding Standards: An Empirical Study

📜 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.

#coding #programmation #developpement #qualité #standard

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.

Catégories
Revue académique

Test-driven development as a defect-reduction practice

🏁 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.

#productivité #tdd #test #programmtion #qualité #quality #science #developpement #software #development

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.

Catégories
Revue académique

Effet tiroir et science du logiciel

🕳️ 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.

#science#recherche#patterns#qualité#programmation

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.

Catégories
Revue académique

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

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 !

#science #nommage #qualité #programming #programmation #developement #software #quality #maintenance

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.

Catégories
Revue académique

Characterizing the Relative Significance of a Test Smell

🇧🇪 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.

#quality #qualite #tests #programmation #developpement #smells #unittesting

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.

Catégories
Revue académique

Organizing Programs Without Classes

😱 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.

#javascript #nodejs #development #science #programmation #developpement #prototype #

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.

Catégories
Revue académique

The chaos of software development

⚛️ 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.

#software #entropy #projectmanagement #gestionprojet #programming #quality #agile #lean

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.

Sedano, Todd & Ralph, Paul & Péraire, Cécile. (2017). Software Development Waste.

Catégories
Revue académique

Rule-based Assessment of Test Quality

🇫🇷🇨🇭 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é !

#quality #tests #programming #programmation #qualité #development #développement

SOURCE

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

Catégories
Revue académique

Why Don’t They Practice What We Preach?

🦥 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.

#quality #qualité #programming #developpement #programmation #softwareengineering #bestpractices

SOURCES

Watts S. Humphrey, Why Don’t They Practice What We Preach? 2009, Software Engineering Institute.