3 Mythes sur le développement logiciel : Démystifier les idées reçues

C'est étrange. Le code fait partie de notre vie quotidienne, mais certains mythes ont la vie dure. Voulez-vous apprendre à coder ? Voulez-vous travailler avec des programmeurs ? Voulez-vous comprendre comment ils pensent ? Si vous avez répondu oui à une de ces questions, il faudra vous défaire de ces idées fausses.

Regardons ça ensemble.

Le mythe de la solution logique

L'une des idées reçues les plus pernicieuses, est que tout problème a une solution logique. C'est ce même sentiment qui sous-tend la question : "L'IA remplacera-t-elle un jour les développeurs de logiciels ? “, ou la réflexion : "La programmation, c'est juste des conditions, des variables, et des boucles”.

Mais on pourait tout aussi bien dire que l'écriture n'est qu'une suite de lettres. Ou que composer de la musique consiste simplement à choisir la bonne séquence de notes.

Pour illustrer ce propos, penchons-nous sur un problème apparemment très simple. On veut classer une liste de nombres du plus petit au plus grand. Il doit bien y avoir une solution logique à ce problème, non ? Comment vous y prendriez-vous ?

Prenez deux secondes pour réfléchir.

Première solution: Passer en revue tous les nombres pour trouver le plus grand, puis répéter le processus pour les autres.

Mais vous pouvez aussi parcourir la liste du début à la fin et comparer les entrées adjacentes deux par deux. Échangez-les chaque fois que vous en trouvez deux dans le mauvais ordre. Puis, répétez le processus jusqu'à ce qu'il ne reste plus rien à trier.

Une troisième méthode de tri consiste à commencer par sélectionner une entrée dans la liste. Commencez par trier les nombres en deux segments : les nombres qui sont plus grands que l'entrée et ceux qui sont plus petits. Répétez ensuite le processus pour chaque sous-segment.

Je pourrais continuer ainsi, car il existe 21 autres algorithmes répertoriés sur Wikipédia, et il ne s'agit que de ceux dont les performances sont acceptables.

Lequel est le meilleur ?

J'ai une mauvaise nouvelle. Il n'y a pas de meilleur algorithme.

Le choix dépend de beaucoup de paramètres: de l’ordre dans lequel nous pensons que la liste peut être triée. De la taille de la liste. Du coût de la lecture des données. Et de bien d'autres choses encore. Chacun de ces algorithmes présente des avantages et des coûts. Il n'existe pas de solution optimale.

Et vous savez quoi ? C'est encore pire.

Il existe une catégorie de problèmes appelés "problèmes NP", ce qui signifie "non polynomial". Ces problèmes n'ont aucun algorithme connu qui puisse les résoudre en un temps raisonnable.

Le mythe de la solution logique est dangereux. La logique est importante, certes, mais elle est loin d'être le seul facteur à prendre en compte.

En tant qu'ingénieurs logiciels, nous devons plutôt trouver des solutions créatives et élaborer la meilleure solution possible pour un problème donné. Pour ce faire, nous devons d'abord comprendre le problème.

Le mythe du code comme unique tâche

Ce qui m'amène à ma prochaine question. Selon vous, quel est l'outil le plus important d'un ingénieur logiciel ? L'ordinateur ? L'éditeur de code ? Un stylo et du papier ? Est-ce notre bouche et nos oreilles ?

Le codage n'est pas la seule tâche des ingénieurs en informatique. Ce n'est même pas la tâche la plus importante du développement logiciel. Nous devons d'abord utiliser

• notre bouche et nos oreilles,
• puis le papier et le crayon,
• et seulement ensuite notre éditeur de code.

Pourquoi ?

Avant de commencer à programmer, les développeurs doivent d'abord comprendre le problème ou le besoin. Cela nécessite de communiquer avec les parties prenantes pour comprendre leurs besoins et leurs attentes. Un ingénieur logiciel doit être capable de poser les bonnes questions et de comprendre les réponses. Sinon, nous risquons de perdre notre temps à travailler sur quelque chose dont personne ne veut.

C'est la raison pour laquelle je ne crains pas que l'IA prenne nos emplois. Car la partie la plus difficile de la conception d'une fonctionnalité n'est pas l'écriture du code. Il s'agit d'acquérir une compréhension profonde des besoins de l'utilisateur.

La deuxième étape consiste à concevoir une solution. Il est tentant de se lancer. Mais il faut d'abord tracer un chemin. Nous devons penser à tout ce qui pourrait mal tourner. À l'impact du changement sur les autres utilisateurs et les autres systèmes. À des éléments tels que les performances, les coûts, les meilleures pratiques, les risques, la maintenabilité et les contraintes juridiques.

La conception de logiciels consiste à traduire les exigences en architecture logicielle. La meilleure façon de procéder est d'utiliser un stylo et du papier, et non un clavier. Elle requiert de la créativité et des compétences en matière de résolution de problèmes.

Une fois que nous avons recueilli les besoins et conçu le système, nous pouvons commencer à taper le code source.

Mais pas seulement pour la fonctionnalité. Nous écrivons également des tests pour détecter automatiquement les défaillances. Cela permet de s'assurer que le code est maintenable. Idéalement, nous commençons par les tests... avant même de coder la fonctionnalité.

Une fois le logiciel codé et testé, le produit est publié. Mais ce n'est que le début de l'histoire. Vient ensuite la maintenance, dont une part importante consiste à chasser et à éliminer les bogues.

Et il n'y a pas de bogue simple. Des erreurs stupides, comme de simples fautes de frappe, peuvent prendre une semaine à trouver et à corriger. Parce que la résolution des bogues nécessite souvent une réflexion analytique approfondie et la résolution de problèmes. Il s'agit de déconstruire la logique et de comprendre où elle a mal tourné.

Comme vous pouvez le voir, le développement de logiciels est une discipline complexe et à multiples facettes. Il demande des compétences en matière de communication, de créativité, de résolution de problèmes, d'attention aux détails et d'analyse. Les gens croient souvent que la difficulté de la programmation réside dans le langage. Ce n'est pas le cas : la difficulté réside dans la pensée abstraite et la modélisation.

Le codage n'est qu'une pièce d'un puzzle plus vaste. Un ingénieur logiciel doit être capable de travailler avec les utilisateurs et de comprendre leurs besoins. Il doit être capable de concevoir des systèmes logiciels. Ensuite, il doit écrire le code, le tester et le maintenir.

Et la maintenance pourrait bien être la seule tâche que nous sous-estimons tous. Pourquoi ? Il existe un dicton : "Le code que vous avez écrit il y a six mois peut tout aussi bien avoir été écrit par quelqu'un d'autre. Permettez-moi d'expliquer.

Le mythe des corrections rapides (et sales)

Imaginez... Nous devons apporter un changement, et nous devons le faire rapidement. Que faire ?

Nous avons le choix.

Prenons-nous le temps de réfléchir à l'impact ? Testons-nous le résultat ? Prenons-nous le temps de faire relire le code par quelqu'un d'autre ? Ou bien nous précipitons le changement et le poussons vers la production ?

Pour être honnête, j'ai souvent choisi la deuxième solution. Parfois, il faut aller vite. Et c'est très bien ainsi.

Mais j'en ai toujours payé le prix. Dans la vie réelle, la tricherie _peut vous causer des ennuis. Mais dans le domaine du génie logiciel, les raccourcis ont toujours des conséquences. Il y a toujours un coût à payer.

En programmation, le karma n'est pas une croyance, c'est une réalité.

Pourquoi ? Permettez-moi de vous expliquer.

Si la programmation ne concerne qu'une chose, c'est bien les conséquences. Si ceci, alors cela, vous vous souvenez ? Il s'agit de construire un système complexe avec des règles logiques complexes. Et aucun esprit humain ne peut connaître les détails précis du comportement de chaque système, ni la logique de chaque fonctionnalité. Ni la logique de chaque fonctionnalité.

Lorsque nous trichons et choisissons la voie rapide et sale (au lieu de la voie lente et régulière), nous créons... une dissonance cognitive. Nous créons des frictions mentales. Nous rendons notre code plus difficile à comprendre. Nous créons un coût futur pour nous-mêmes.

Ce coût futur a un nom. Nous l'appelons la dette technique. Cela signifie que nous avons fait des économies, mais que nous devrons passer plus de temps à l'avenir pour rendre les choses plus propres.

Et c'est là que le problème auquel j'ai fait allusion plus tôt entre en jeu. Je ne saurais vous dire combien de fois il m'est arrivé de me pencher sur un morceau de code et de me dire : "Qui est l'abruti qui a écrit ça ? Puis je me suis rendu compte que c'était moi, alors que j'essayais d'être intelligent ou rapide. Et que le crétin, c'était moi.

Il existe une chose appelée l'effet Dunning-Kruger. Il s'agit d'un étrange biais cognitif. Les gens surestiment leurs compétences lorsqu'elles sont faibles et les sous-estiment lorsqu'elles sont élevées.

En d'autres termes, il est dangereux d'avoir peu de connaissances.

Inversement, lorsque vous devenez compétent, vous commencez à douter de vos capacités. Parce que vous êtes conscient de l'étendue du chemin à parcourir. Vous vous rendez compte de tout ce que vous ne savez pas. Vous vous rendez compte qu'il vous reste encore beaucoup à apprendre.

Et ça, mes amis, c'est le voyage qui nous attend.