Lorsque j'ai commencé à programmer, je me suis beaucoup appuyé sur les organigrammes (et les tableaux d'espacement des imprimantes). Pendant que j'étais en classe COBOL, je ne pouvais pas commencer à écrire de code tant que mon organigramme n'était pas signé par l'instructeur. À l'époque, je devais faire un organigramme pour tout.

Aujourd'hui, vingt-cinq ans plus tard, je ne me retrouve à schématiser que deux types de choses. Algorithmes très spécifiques où la logique est délicate ou concepts très généraux pour m'assurer que j'obtiens toutes les grandes étapes définies et dans le bon ordre.

Existe-t-il d'autres cas d'utilisation pour les organigrammes que j'ai simplement ignorés?

Absolument.

Chaque fois que j'implémente quelque chose que je n'ai pas fait auparavant (et que l'algorithme prend plus de quelques étapes), je vais le tracer. Je trouve que cela m'oblige vraiment à analyser la solution entière à un niveau plus atomique et plus minutieusement que si elle n'était pas tracée. Je trouve qu'il y a trois avantages majeurs à cette pratique:

• Moins de "oh craps" parce que j'ai pensé à tout l'algorithme
• Élimine tous les problèmes potentiels pouvant survenir dans le reste du système
• Me permet de guider facilement quelqu'un d'autre à travers l'algorithme

Les deux différentes occasions où j'utilise ces derniers sont:

• Algorithmes de bas niveau (ish). Je veux dire une solution très spécifique à un problème très spécifique. Je les transmets généralement par des pairs avant la mise en œuvre.
• Flux d'utilisateurs. Non seulement je peux l'utiliser pour passer par un pair, mais je vais également l'utiliser pour expliquer (de manière très non technique) le flux à un expert en utilisabilité.

Cela dit, je ne produis pas d'organigrammes quotidiennement (et même lorsqu'ils sont terminés, il s'agit généralement d'une session de tableau blanc, sauf si j'écris un document de conception technique).

Jamais

Les organigrammes - particulièrement ceux pratiqués il y a plus de 25 ans - ont été remplacés par des techniques de création de diagrammes beaucoup plus expressives (cf. diagrammes d'action, diagrammes de séquence, diagrammes d'état, et al).

Les propres études d'IBM ont montré que l'utilisation des organigrammes n'avait aucun effet sur la qualité de la conception ou de la mise en œuvre d'un système (bien qu'ils soient légèrement utiles pour communiquer avec les utilisateurs et les autres développeurs) [référence précise pas facilement disponible, mais a été citée dans les techniques de création de diagrammes de James Martin pour les analystes et programmeurs ].

Je n'ai pas dessiné d'organigramme classique depuis mon premier cours de programmation en 1976, et je n'ai vu personne d'autre en créer un depuis le début des années 80. Les organigrammes étaient utiles pour communiquer la logique du programme lorsque le code était en langage assembleur. À la fin des années 1960, les programmeurs en langage assembleur utilisaient un pseudo-code. Lors de la programmation dans les langages OO modernes, ni les organigrammes ni les pseudo-codes n'ont de valeur. Vous pouvez tout aussi bien écrire du code de haut niveau dans le langage d'implémentation.

Je dessine occasionnellement des diagrammes UML, principalement sur papier, pour exprimer des idées de conception, mais ces diagrammes ne vivent que jusqu'à la fin de la discussion. Je dessine également des diagrammes de transition d'état de temps en temps, puis les convertis en une table d'état dans le langage d'implémentation.

J'utilise des organigrammes tout le temps pour un certain nombre de raisons:

1. À mon avis, ils sont meilleurs que les diagrammes de cas d'utilisation UML. Ils peuvent refléter un certain nombre de cas d'utilisation différents et comment ils interagissent, et ils font globalement un meilleur travail en réunissant l'expérience utilisateur et les décisions.

2. Ils sont plus faciles à comprendre et plus intuitifs. Votre esprit suit naturellement les flèches comme un labyrinthe du début à la fin. Vous pouvez utiliser des organigrammes pour terminer et référencer un autre organigramme pour une autre user story. Je peux généralement les imprimer dans un livre numéroté et retourner rapidement les pages pour naviguer vers le prochain organigramme.

3. Ils sont universels. Peu de personnes en dehors du génie logiciel connaissent et comprennent les diagrammes UML, où les diagrammes de flux sont beaucoup plus reconnaissables par les utilisateurs et les analystes commerciaux. J'essaie de communiquer des cas d'utilisation complexes à un client et ils ont parfois du mal à comprendre, je leur dessine un organigramme et ils comprennent pourquoi ils comprennent enfin toutes les nuances qui le rendent beaucoup plus complexe qu'ils ne le pensaient.

Les organigrammes sont utiles lorsque les choses doivent être effectuées dans un ordre spécifique. Là où ils brillent vraiment dans mon esprit, c'est de montrer où les décisions sont prises et de s'assurer que chaque décision possible a un chemin. Cela empêche de créer des programmes où une approbation de gestionnaire est requise mais n'a aucun moyen de le gérer si le gestionnaire (qui approuve 98% du temps) dit non. Ils nous rappellent que le chemin le plus courant n'est pas le seul chemin. Je les trouve utiles pour parler aux utilisateurs des exigences, car souvent ils ne vous indiqueront que le chemin le plus courant.

Les diagrammes de flux peuvent être utiles pour la rétro-ingénierie de code très mal structuré. Surtout si elle a des gotos. Heureusement, je n'ai pas vu beaucoup de code goto-riddden récemment.

Comme d'autres l'ont fait remarquer pour avoir communiqué avec les utilisateurs finaux. Je trie le démarrage d'un émetteur TV documenté par un organigramme. Les gens du matériel et des logiciels avaient une spécification commune sur laquelle travailler.

Le diagramme d'activité et l'organigramme UML sont utiles pour montrer la complexité faible à moyenne d'un processus ou d'un algorithme.

Ils sont très bons pour communiquer avec les utilisateurs métier sur les règles métier.

Il existe une variation sur la forme de BPMN 2.0 qui est très utile dans la modélisation des processus métier.

Certains outils BPMN peuvent générer des applications Web en cours d'exécution à partir de graphiques.

Alors oui, les organigrammes ont toujours une place mais ils doivent être utilisés à bon escient.

Je ne suis pas programmeur. Je suis un technicien en génie matériel.

Il est logique pour moi de commencer par au moins des commentaires expliquant les blocs logiques qui seront utilisés. Après cela, étoffer le squelette du programme avec le code réel. Cela revient à démarrer un script de film avec un story-board, puis à compléter les détails de l'action et la boîte de dialogue par la suite.

Ne faut-il pas planifier soigneusement tout effort utile? Dans le domaine matériel, nous commençons par un document sur les exigences du client, puis rédigeons un document de spécification du matériel, puis étoffons le schéma, puis dessinons une disposition de carte, puis élaborons la documentation d'assemblage. Nous ne commençons pas seulement à saisir des pièces et à les souder ensemble lorsque nous trouvons des idées pour fabriquer le produit final.

Je ne vois pas comment un code efficace peut être écrit dans un programme de 15 Ko ou 15 Mo sans beaucoup de travail de préparation avant de commencer le codage proprement dit.