Avec la dépendance croissante à l’écriture de code assistée par IA, l’époque où l’on voyait quelqu’un sortir son cahier et esquisser des algorithmes ou des plans pour résoudre un problème donné est révolue. À l’époque, l’organigramme était l’un des moyens fondamentaux que l’on pouvait utiliser pour cartographier et rendre ses solutions visuelles ! Cela prend certes du temps, mais à long terme, cela produit des solutions avec moins de bugs, donc peut-être, juste peut-être, ça vaut la peine de s’y remettre !
Ci-dessous se trouve un extrait tiré du livre « Programming the 8086/8088 by James W. Coffron », je ne m’attribue aucun crédit pour les perspectives de ses écrits. Il a été publié en 1983 quand les gens écrivaient encore du code sur leurs gros PC IBM ressemblant presque à des réfrigérateurs avec juste du bon vieil assembleur, fouinant dans la mémoire pour trouver leur chemin à travers la logique de leur code.
Quelle époque différente c’était…
L’organigramme
Un organigramme est simplement une représentation symbolique d’un algorithme, habituellement exprimée comme une séquence de rectangles et de losanges. Dans un organigramme, les rectangles sont utilisés pour représenter des commandes (ou instructions exécutables), et les losanges sont utilisés pour les tests tels que : Si l’information X est vraie, alors prendre l’action A ; sinon, prendre l’action B.
La Figure 1.1 montre un exemple d’organigramme. L’organigramme est une étape intermédiaire hautement recommandée entre la spécification d’un algorithme et le codage réel d’une solution. Remarquablement, on a observé que peut-être 10% de la population de programmeurs peut écrire un programme avec succès sans avoir à préparer un organigramme. Malheureusement, on a aussi observé que 90% de la population croit appartenir à ces 10% ! Le résultat, alors, est que, en moyenne, 80% des programmes échouent la première fois qu’ils sont exécutés sur un ordinateur. (Ces pourcentages ne sont naturellement pas censés être précis.) En bref, la plupart des programmeurs novices voient rarement la nécessité de dessiner un organigramme.
Diagramme tiré du livre Programming the 8086/8088 de James W. Coffron
Ignorer l’étape de l’organigramme résulte généralement en un programme erroné, et le programmeur doit alors passer un long moment à tester et corriger son programme. (C’est ce qu’on appelle la phase de débogage.)
La discipline de l’organigramme est, par conséquent, hautement recommandée dans tous les cas. L’organigramme nécessite généralement une petite quantité de temps supplémentaire avant le codage, et résulte habituellement en un programme clair qui s’exécute correctement dans un court laps de temps. Une fois que la procédure d’organigramme est bien comprise, un petit pourcentage de programmeurs peut effectuer cette étape mentalement, sans utiliser de papier. Malheureusement, dans de tels cas, les programmes qu’ils écrivent sont généralement difficiles à comprendre pour les autres, puisque la documentation normalement fournie avec un organigramme n’est pas disponible. Il est universellement recommandé que l’organigramme soit utilisé comme une discipline stricte pour tout programme de plus de dix ou quinze instructions.
Bien que cette pratique puisse ne plus être nécessaire pour livrer du code fonctionnel robuste, elle pourrait encore rester un bon outil quand on cherche de bonnes solutions quand l’improvisation semble parfois impossible.