Le sophisme du développement logiciel anecdotique | de Michael Long | janvier 2023

Ou que se passe-t-il lorsqu’une taille ne convient pas à tous ?

Le développement de logiciels anecdotiques est défini comme une dépendance excessive à l’expérience ou à l’opinion personnelle lors de la conception et de la construction de logiciels.

Vous ne l’avez probablement jamais entendu dire de cette façon auparavant, mais c’est ainsi que la majorité des gens écrivent et développent des logiciels. Et si vous vous arrêtez pour y penser, comment pourrait-il en être autrement ?

Sinon comment pourrais nous le faisons? Sinon, comment pouvons-nous écrire des logiciels, si ce n’est sur la base de notre propre éducation, de nos propres compétences et de notre propre formation ?

Il y a une réponse à cette question, mais d’abord, considérons certains des dangers qui la sous-tendent.

Reprenons la définition :

Le développement de logiciels anecdotiques est défini comme une dépendance excessive à l’expérience ou à l’opinion personnelle lors de la conception et de la construction de logiciels.

Donc quel est le problème?

Premièrement, les preuves anecdotiques – de tout type – ne sont généralement pas vraiment représentatives d’une population ou d’un groupe plus large. C’est la connaissance qui repose principalement sur l’observation personnelle, souvent recueillie de manière occasionnelle ou non systématique. (Débordement de pile, quelqu’un ?)

Cela étant, le fait de fonder les décisions de développement de logiciels uniquement sur l’expérience personnelle peut ne pas refléter avec précision les besoins ou les préférences du projet ou ceux de ses utilisateurs prévus. Cela peut conduire à des logiciels mal conçus, difficiles à utiliser ou inutiles pour une partie importante du public cible.

Deuxièmement, les preuves anecdotiques sont sujettes à des biais et à des erreurs.

Lorsque les développeurs de logiciels s’appuient uniquement sur leurs propres expériences, ils peuvent être influencés par leurs propres idées préconçues, préjugés ou souvenirs, ce qui peut conduire à une compréhension erronée ou incomplète du problème à résoudre.

Enfin, s’appuyer sur des preuves anecdotiques dans le développement de logiciels peut entraîner un manque de transparence et de responsabilité.

Lorsque les décisions sont basées sur des expériences personnelles plutôt que sur des données empiriques, il peut être difficile de justifier ou d’expliquer ces décisions aux autres. Cela peut créer des problèmes en termes de communication, de collaboration et de prise de décision au sein d’une équipe de développement, ainsi qu’avec les parties prenantes ou les clients.

Bien que ce qui précède puisse certainement être problématique, je suis plus préoccupé par le processus de développement logiciel lui-même. Que se passe-t-il sous le capot ?

Alors prenons un exemple et allons-y.

J’ai vu beaucoup d’articles et de commentaires récents sur ce qui constitue exactement une « meilleure pratique » dans le développement de logiciels. Les opinions vont et viennent généralement, et parfois les sections de commentaires peuvent être assez passionnées.

Prenons, par exemple, la pratique de développement connue sous le nom de test unitaire.

Si vous ne l’avez jamais fait, ne l’avez jamais pratiqué ou n’avez jamais servi dans une organisation qui l’exigeait, alors les tests unitaires peuvent sembler une perte de temps, d’énergie et de ressources.

Et si votre point de vue appartient à la dernière catégorie, la division de votre code en vues et modèles de vue distincts peut également sembler inutile.

Après tout, l’un des principaux avantages revendiqués est qu’il permet de sortir la logique métier de la vue et de la placer dans un endroit où elle peut être vue et testée. Mais si nous ne testons pas, alors pourquoi faire l’effort supplémentaire ?

Même chose avec l’utilisation d’un système ou d’une stratégie d’injection de dépendances. L’idée est de réduire le couplage et de rendre à nouveau un objet plus facile à tester et à simuler. Mais si nous ne testons pas, encore une fois, pourquoi faire l’effort supplémentaire ?

Donc, pour en revenir à notre sujet, si vous n’en voyez personnellement pas la nécessité – et si cela constitue votre principal argument contre cela – alors vous vous engagez dans le développement de logiciels anecdotiques.

Je ne le fais pas. Je ne l’ai jamais fait. Ma société ne le fait pas. Il ne doit donc pas être nécessaire.

Et quiconque pense le contraire est un idiot.

Vous pouvez aussi renverser l’argument. Si vous l’avez toujours fait, ou si vous êtes dans un environnement de santé ou financier qui a des exigences de test et de couverture de code, alors vous aussi allez probablement avoir du mal à envisager une situation dans une startup ou lors de la construction d’une preuve- application du concept là où elle n’est peut-être pas justifiée.

Les deux parties souffrent du sophisme anecdotique du développement logiciel,

Vous tombez dans le piège à la seconde où vous dites : « Eh bien, je ne l’ai jamais fait de cette façon… » ; ou c’est l’opposé polaire, « j’ai toujours fait comme ça… » ; ou même simplement, « D’après mon expérience… »

Anecdotes.

Au cours des dernières décennies, les praticiens du développement logiciel et de l’ingénierie logicielle ont généré de nombreuses bonnes pratiques et principes tels que SOLID, DRY, etc. Et nous avons créé des architectures telles que MVVM, Clean, VIPER, etc.

Ces meilleures pratiques sont souvent basées sur les connaissances et l’expérience accumulées d’experts dans un domaine particulier et ont été conçues pour aider les développeurs à obtenir les meilleurs résultats possibles.

Mais les bonnes pratiques, les frameworks et les architectures ne sont pas des règles absolues.

Ils peuvent être utilisés comme point de départ ou comme guide, mais ils doivent également être adaptés et personnalisés selon les besoins afin de répondre au mieux aux besoins du projet et de l’équipe spécifiques.

Mais il y a une vue d’ensemble à voir ici, et je pense qu’elle touche au cœur du problème.

Taille unique n’a pas s’adapter à tous.

Une application de liste de courses n’est pas conçue à la même échelle qu’une application de trading financier. Une entreprise avec un seul ensemble de développeurs – ou même un seul développeur – est confrontée à un ensemble de problèmes différent d’une entreprise avec plusieurs équipes travaillant sur plusieurs fonctionnalités simultanément.

Une application bancaire fonctionne selon un ensemble de règles, de contraintes et d’exigences légales différent de celui d’une application Sudoku.

Taille unique n’a pas s’adapter à tous.

Si vous avez principalement travaillé sur des applications plus petites, la quantité de modularisation et d’encapsulation généralement nécessaire avec une application commerciale avec une demi-douzaine d’équipes peut sembler lourde, surmenée et complètement inutile.

Et si vous êtes confronté à un article prônant une telle approche, vous pourriez simplement le rejeter d’emblée. « Pourquoi ferais-tu ça? Je n’ai jamais eu besoin de faire ça !

Anecdotes.

Donc, si le développement de logiciels anecdotiques est un problème, alors quelle est la solution ?

Il y a peu de réponses à cette question.

La collaboration peut apporter diverses perspectives et expertises au processus de développement. En travaillant avec d’autres personnes ayant des antécédents, des expériences et des compétences différents, les développeurs peuvent bénéficier d’un large éventail d’idées et d’approches, ce qui peut conduire à des solutions plus créatives et efficaces.

La collaboration peut également aider à identifier et à résoudre les problèmes plus efficacement. En travaillant ensemble, les développeurs peuvent partager des connaissances et des ressources, et peuvent également s’entraider pour résoudre les problèmes au fur et à mesure qu’ils surviennent.

Vous partagez maintenant vos arrière-plans. Vos points de vue.

En bref, étant donné une équipe diversifiée, vous passez maintenant du domaine de l’individu, des anecdotes personnelles au pays du consensus.

Cela va de pair avec…

L’éducation peut aider les développeurs de logiciels à mieux comprendre les principes du développement et de la conception de logiciels. En acquérant une base solide et une compréhension des principes fondamentaux, nous pouvons être mieux équipés pour prendre des décisions éclairées et fondées sur des preuves au cours du processus de développement.

Mais il ne suffit pas de pouvoir énoncer les cinq principes qui sous-tendent SOLID. Nous devons également savoir Pourquoi ces principes existent. Quels problèmes essayaient-ils de résoudre ?

Si nous comprenons comment fonctionnent, nous sommes également mieux placés pour juger de leur adéquation au projet en cours. Nous sommes en mesure de discuter et de peser ces lignes directrices et d’équilibrer les compromis entre elles.

L’éducation dans des domaines autres que le développement de logiciels peut également aider à élargir ses horizons. En introduisant de nouvelles idées, concepts et perspectives, les développeurs peuvent élargir leur compréhension du monde et de leur place dans celui-ci.

Le développement de logiciels, après tout, ne se déroule pas dans le vide.

Enfin, les professionnels du logiciel doivent également être proactifs dans la recherche d’opportunités d’apprendre et de développer leurs connaissances. Cela peut impliquer de rester engagé avec la communauté de développement de logiciels, d’assister à des conférences et des ateliers, et de participer à des opportunités de formation continue et de développement professionnel.

La collaboration et l’éducation sont importantes, mais elles reposent essentiellement sur une même valeur fondamentale.

Être ouvert aux nouvelles idées est un aspect important de l’apprentissage et du développement de ses connaissances dans n’importe quel domaine, y compris le développement de logiciels.

En étant ouverts aux nouvelles idées, les développeurs de logiciels et autres professionnels peuvent élargir leur compréhension et leur perspective et être mieux équipés pour s’adapter aux nouvelles technologies et approches à mesure qu’elles émergent.

Le génie logiciel évolue constamment à mesure que de nouvelles technologies et approches sont développées et adoptées. Cette évolution peut être entraînée par une variété de facteurs, y compris des changements dans les besoins et les préférences des utilisateurs, des changements dans l’environnement des affaires, ou même simplement par les progrès du matériel informatique et des logiciels.

Et les paradigmes changent.

SwiftUI est illustratif à cet égard, dans la mesure où bon nombre des meilleures pratiques que nous avions autrefois, ou qui ont été développées pour d’autres plates-formes et d’autres langages, ne fonctionnent tout simplement pas bien dans un environnement SwiftUI.

Mais si nous savons comment l’architecture a été conçue et les problèmes qu’elle a tenté de résoudre, et si nous comprenons comment SwiftUI fonctionne et gère ses vues et ses mises à jour, alors nous sommes dans une bien meilleure position pour juger de la pertinence d’une approche ou d’une pratique donnée.

Surtout lorsque nous prenons en compte les questions du tableau d’ensemble :

• Quelle est la taille de l’application ?
• Quelle est la complexité ?
• Quel est le délai ?
• Quelle est la taille de l’équipe ?
• Quel est notre cycle de publication ?
• Quelles exigences et contraintes supplémentaires avons-nous ?

Toutes ces choses doivent être considérées.

N’oubliez pas : une taille ne convient pas à tous.

Avons-nous bouclé la boucle ? Pratiquer ce qui précède augmente vos connaissances et votre expérience, mais sommes-nous encore une fois en train de nous développer sur la base de nos propres connaissances et expériences personnelles ?

Hé bien oui. Et non.

Parce que maintenant, espérons-le, nous fonctionnons sur la base partagé connaissances et partagé expériences.

Nous nous appuyons sur les connaissances accumulées et la sagesse des experts dans notre domaine.

Nous sommes conscients que notre connaissance d’un domaine particulier peut être limitée et que nous devons toujours chercher à l’élargir.

Et nous sommes conscients du fait que les meilleures pratiques, processus et outils évoluent et changent avec le temps, et que, si nous savons pourquoi, nous pouvons juger de leur adéquation au projet en cours.

Où ils s’adaptent. Où ils ne le font pas. Et où ils doivent être adaptés.

C’est un sujet qui me tient à cœur et j’aimerais entendre ce que vous en pensez. Laissez simplement un commentaire ci-dessous et, pendant que vous y êtes, écrasez le bouton J’aime si vous voulez en voir plus.

Jusqu’à la prochaine fois.