Photo par Alfons Morales sur Unsplash

“Le problème avec le logiciel”

Je me suis toujours intéressé à la recherche de nouveaux ouvrages de génie logiciel précieux. Dans mon article intitulé «Les 5 meilleurs ouvrages d’ingénierie logicielle contemporains», j’ai dressé la liste de mes favoris actuels. «Le problème des logiciels: pourquoi les ingénieurs intelligents écrivent-ils du code incorrect» de Adam Barr (2018) - si je l'avais lu plus tôt - l'aurait probablement fait figurer sur cette liste. Voici une critique et des récits de mon expérience personnelle liés au contenu du livre.

Causes profondes

Barr présente essentiellement une longue histoire de la science et de la technologie informatiques et discute de manière critique du fait qu’il ya peu d’accord sur les normes et les bonnes approches en matière de SE. Il déclare:

Avoir un diplôme en génie logiciel ne garantit pas, contrairement à d'autres disciplines d'ingénierie, que vous compreniez un corpus connu d'outils et de techniques de programmation, car une telle chose n'existe pas.

Le livre ne contient pas beaucoup de conseils concrets du type "Si vous structurez vos méthodes de la sorte, vous améliorerez la conception de vos logiciels et réduirez le code en moins". Au lieu de cela, l'auteur se concentre sur certaines des causes profondes et explique pourquoi la situation actuelle du secteur est la même. (Spoiler: Entre autres choses, l’instruction GOTO et le langage de programmation C sont responsables de beaucoup de mauvaises choses qui se sont produites dans les logiciels.)

Les deux premiers chapitres étaient un peu lents et la seconde partie me paraissait plus intéressante et stimulante. Ceci est probablement dû au fait que, malgré ma première exposition précoce au BASIC dans mon Commodore C64 et mon Amiga 500, je pourrais davantage me rapporter aux développements plus récents de mon expérience professionnelle. Cependant, même les premiers chapitres citent des extraits perspicaces d’études de recherche sur la SE:

"Il existe un aspect de maintenance unique appelé" récupération des connaissances "ou" compréhension du programme ". Il devient un élément de coût majeur à mesure que le logiciel vieillit (supposons que 50% des améliorations et de la correction des défauts sont utilisées)." La moitié de vos coûts de maintenance les détails de votre programme que vous aurez oubliés entre temps!

ou

"... Par conséquent, la plupart des programmeurs ne peuvent pas tester efficacement leurs propres programmes car ils ne peuvent pas se résoudre à former l'attitude mentale nécessaire: l'attitude de vouloir exposer les erreurs."

Défis

Dans l’ensemble, j’ai vraiment apprécié le style d’écriture équilibré et réfléchi et la vaste connaissance de Barr, tant du secteur que de la recherche. Il examine principalement la question fondamentale «Le développement de logiciels est-il vraiment difficile ou les développeurs de logiciels ne sont-ils pas bons en la matière?» Sous différents angles. De plus, ce que j’aime, c’est qu’il ne prétend pas connaître toutes les réponses, ce qui dans son cas est certainement une forme de sous-estimation et d’humilité. (J'y reviendrai à la fin de l'article.) L'auteur souligne certains de ses problèmes personnels, causés par le manque de connaissances standard sur la SE et reflétés dans des déclarations telles que:

Je pourrais conseiller les gens sur la façon de naviguer dans les eaux de la vie d’entreprise, mais c’était un conseil générique qu’ils pouvaient obtenir de n’importe qui. Comme d’autres, mes conseils étaient vagues: «Dans ce cas, je me souviens que ce genre de chose fonctionnait bien, alors pourquoi ne pas essayer cela?»

Le contexte

L'impact du contexte dans les projets de SE et un phénomène qu'il mentionne appelé «effet d'amnésie de Gell-Mann» deviennent encore plus clairs lorsque Barr dit:

Si vous racontiez aux membres d’une équipe Microsoft l’expérience d’une autre équipe en matière d’ingénierie, ils pourraient immédiatement identifier, en raison de leur connaissance du fonctionnement interne de Microsoft, en quoi cette autre équipe était différente de leur équipe, et par conséquent rejeter les indications ne sont pas pertinentes. Dans le même temps, ils auraient volontiers des conseils sur Scrum, même si cela n’était absolument pas applicable à leur équipe, car ils ne connaissaient pas les détails de l’environnement dans lequel ils avaient réussi.

Dans le chapitre «Design Thinking», il aborde des sujets tels que les avantages des modèles de conception et explique dans quelles situations ils peuvent être utiles, par exemple, s'il est probable que vous souhaitiez modifier ou étendre du code à l'avenir (car de nombreux modèles sur l’extensibilité future). Leur application peut toutefois être inutile si des modifications futures d'un module sont peu probables, auquel cas elles ne feraient qu'introduire de la complexité. De plus, le chapitre contient des références à des termes amusants de personnes notables comme Spolsky (par exemple, «astronaute de l'architecture» - quelqu'un qui voit des abstractions et des motifs plus larges partout…) ou d'autres observations spirituelles:

Bien que les architectes logiciels fondés soient considérés, à ce moment-là, mieux que les architectes privés d’oxygène, le fait que les architectes ont besoin d’être continuellement immergés dans le projet actuel de leur équipe est un autre signe du manque de connaissances et de vocabulaire généralement acceptés autour du génie logiciel.

L’auteur souligne que les «conseils raisonnables» de livres tels que «Clean Code» et «The Pragmatic Programmer» ne présentent pas «d’approches spécifiques». La conception logicielle est unique en ce sens que les systèmes développés sont difficilement comparables les uns aux autres. Étant donné que nous traitons souvent avec des domaines et des problèmes totalement nouveaux, la qualité des résultats de conception varie fortement, même pour les personnes très expérimentées. Barr affirme que «lorsque vous éliminez les absurdités de la conception de logiciels, vous vous retrouvez avec des modèles de conception et pas grand-chose d'autre».

Un peu lié au contexte, dans le chapitre «Votre langue préférée», il mentionne que le principal problème de notre multitude de langages de programmation et de leurs conceptions différentes est qu'il existe très peu d'indications sur le moment où une langue est supérieure à une autre pour résoudre un certain problème. Et encore une fois plus tard, dans le chapitre «Agile», nous n’avons que peu de connaissances sur le moment où les méthodologies et pratiques de logiciels agiles, telles que Scrum, sont vraiment utiles. Le chapitre se termine par:

Bien que l’agilité facilite un peu les problèmes simples, elle n’aide pas les problèmes difficiles. C’est attrayant pour les programmeurs, mais pour que l’ingénierie logicielle devienne une discipline de l’ingénierie, il faut quelque chose d’autre.

Recherche

Quand j'ai passé deux ans dans la recherche et l'enseignement à l'université, après avoir lu des articles pertinents ou «Making Software» (l'un des rares livres qui tentent de faire connaître la recherche sur les SE à un public plus large), j'ai été surpris de constater à quel point existe réellement. Souvent, cependant, cela me laissait quelque peu insatisfait des conclusions puisque vous attendiez secrètement des réponses universelles telles que «Non, le TDD n’est pas utile» ou «Oui, les modèles de conception sont précieux» - arguments que vous espériez utiliser lors de vos prochaines discussions avec des collègues pour démanteler leurs arguments religieux et leurs preuves anecdotiques. Bien sûr, à cause des contraintes imposées par les plans expérimentaux, les réponses étaient souvent similaires à «Oui, dans ces conditions et dans ce contexte spécifique, cela peut avoir un sens…». De plus, j’ai souvent eu l’impression que les plans de l’étude ne rendaient pas très bien compte des réalités du développement logiciel (ce qui est l’un des principaux défis de la SE basée sur des preuves).

Dojo de codage

J'ai particulièrement aimé le dernier chapitre «L'avenir» et les suggestions de l'auteur sur ce que nous pouvons réellement faire pour améliorer la situation. Naturellement, de nombreuses idées de Barr ont à voir avec l'éducation, la façon dont nous enseignons l'ES à l'université et la façon dont les étudiants préparé pour les emplois de l'industrie. Le chapitre est une source d’inspiration et, quand je repense à ma propre expérience universitaire, le fossé entre l’université et l’industrie m’a toujours dérangé. Barr cite Weinberg qui écrit:

Les projets logiciels réalisés dans les universités n’ont généralement pas besoin d’être maintenables, utilisables ou testables par une autre personne.

Pour tenter de réduire un peu cet écart, un de mes collègues et moi-même avons proposé à l’époque un nouveau concept de cours pour nos étudiants appelé «Coding Dojo». L’idée principale était d’organiser un séminaire intensif de plusieurs jours pour enseigner aux participants ce que nous considérions comme important pour travailler plus tard dans l’industrie et ce qu’ils n’apprendraient pas autrement dans le programme d’informatique. Nous avons donc réfléchi, proposé des idées, imprimé un dépliant qui devrait attirer les étudiants et construit un système interactif pour enseigner des sujets tels que la lisibilité du code, les odeurs de code, le refactoring, etc. Nous avons passé toutes nos vacances de Pâques à concevoir ce système en temps réel pouvant présenter des contenus interactifs. exercices avec des évaluations automatiques et essayé d’intégrer tout ce que nous savions sur le sujet à l’époque, y compris du matériel tiré de livres tels que «Code Complete» ou «Refactoring».

Je suis toujours fier du concept et le parcours a été un succès (du moins en termes de retour d’information et de popularité) mais, autant que je sache, jusqu’à aujourd’hui, c’était un effort ponctuel. De plus, des séminaires tels que «Coding Dojo» ne résoudraient pas le problème, à savoir que les étudiants ne doivent généralement pas travailler avec «de plus gros logiciels», ce qui, selon Barr, les exposerait très tôt à des programmes «construits à partir de connexions entre API». frontières »et les confrontent ainsi à des activités de développement importantes telles que la lecture, la compréhension et le débogage d’un système de grande taille.

Spécialisation

Il y a beaucoup à améliorer dans les curriculums CS et SE et, comme le soutient Barr, une spécialisation pourrait être utile, car le domaine dans son ensemble est devenu trop vaste et compliqué pour permettre une compréhension approfondie de tout. Ainsi, plutôt que de créer des sujets tels que des compilateurs, des graphiques et des structures de données avancées - sujets avec des bases bien documentées - obligatoires, les étudiants de premier cycle pourraient choisir de se concentrer sur leurs sujets de prédilection. Cela aiderait ensuite à façonner leur profil pour les futurs employeurs et donnerait plus de crédibilité au diplôme. Barr écrit:

Actuellement, les ingénieurs en logiciel sortant du collège sont considérés comme fongibles; il est prévu que tout programmeur, s'il le juge compétent quelle que soit la procédure d'embauche utilisée, puisse travailler sur n'importe quelle partie d'un programme. À mesure que les logiciels deviennent de plus en plus compliqués, il est plus logique que les gens se spécialisent dans différents domaines.

Humilité intellectuelle

Enfin, mon conseil préféré mentionné dans le livre et entendu ailleurs dans le passé est «L'amélioration modeste», soulignant le fait que si vous restez curieux et continuez à apprendre tout en ayant l'attitude de «Malgré des années d'expérience, je ne ne prétendez pas être un expert en la matière et il y a toujours plus à savoir ». Même si ce conseil peut sembler simple, j’ai souvent été étonné de voir à quel point les candidats qui postulent à un poste de SE évaluent leur propre niveau de compétence (nous demandons aux candidats de remplir une «feuille d’autoévaluation» avant un entretien technique). Mon impression est que c’est généralement un signe d’ancienneté lorsque des personnes ayant une expérience substantielle ne se donnent pas les meilleures notes dans des domaines particuliers - ce qui indique qu’elles restent intellectuellement humbles et qu’elles pourraient en fait être celles qui améliorent le plus leurs compétences.