Pourquoi construit-on des logiciels ?

D’un « pourquoi » Ă  une proposition concrète pour mieux concevoir des logiciels

Publié le 02.06.2019
Temps de lecture estimé : ~ 9 min.
Traductions disponibles : en

Lorsque vous rencontrez des amis ou de la famille que vous n’avez pas vus depuis longtemps, en général, les gens vous demandent ce que vous faites dans la vie aujourd’hui — ou dans quel domaine vous êtes en termes d’études ; c’est à coup sûr quelque chose que vous demandez ou qu’on vous a demandé.

Si vous êtes étudiant en informatique, ou en génie informatique, vous devez principalement expliquer que vous travaillez avec des ordinateurs, que vous résolvez des problèmes difficiles, et que, pour cela, vous construisez des logiciels.

Généralement, les gens sont curieux vis-à-vis du type de logiciel sur lequel vous travaillez. Et vous répondez généralement que vous travaillez sur des sites Web, des applications mobiles, des programmes qui font voler des avions, des « choses » pour faire des simulations, des « trucs » qui optimise des « bidules », etc.

Mais parfois, on vous pose une question plus rare : « Pourquoi est-ce que tu fais du logiciel ? ».

En général, on s’arrête et on se pose des questions, puis on répond peut-être simplement quelque chose comme « parce que c’est amusant », « parce que c’est stimulant intellectuellement », « parce que j’aime ça », « parce que c’est utile », ou « parce que je peux gagner ma vie avec ça ».

Mais cette réponse peut être utilisée pour n’importe quel job en fait.

Qu’il y a-t-il de si spécial avec le logiciel ?

Cette question peut être contraignante et la réponse peut dépendre de ce que vous recherchez.

D’une part, il peut vous donner un moyen de créer facilement des choses qui font quelque chose de relativement efficace et bon marché. Contrairement à la construction de voitures ou d’autres choses ou biens physiques, vous pouvez faire un investissement initial relativement petit dans un logiciel et en tirer un résultat relativement important — que cet investissement soit quantifiable en termes d’argent ou de temps. Par conséquent, la création de logiciels vous donne une capacité concrète de traduire des idées en quelque chose dont vous tirez profit.

D’un autre côté, elle peut être considérée comme une façon assez particulière d’interagir avec le monde, de produire quelque chose. C’est une sorte d’art, et de science : une sorte de artisanat. Contrairement à la construction de voitures ou d’objets physiques, le simple fait d’écrire vous donne une forme spéciale de liberté, de possibilité de traduire facilement des idées en quelque chose que vous pouvez construire, partager, modifier et construire.

D’où cette question plus précise : Construisons-nous des logiciels pour faire fonctionner quelque chose et en tirer quelque chose d’autre, ou construisons-nous des logiciels pour atteindre cette forme de véritable artisanat ?

La première est nécessaire mais ne suffit pas : le second est sûrement l’objectif le plus beau et qui a le plus de sens pour chaque logiciel.

Comment arriver à produire des œuvres d’artisanat

Il n’y a pas de secret : cela vient avec un savoir-faire, de la dévotion et surtout un nombre d’heures passés dedans : vous pouvez avoir la meilleure idée du monde, de l’inspiration et de la motivation sans que vous produisez concrètement quelque chose.

Vous pouvez construire un logiciel seul, mais vous le créez généralement en équipe. Et, dans une équipe, tout est une question de construction d’une œuvre commune et d’un ownership distribué sur celle-ci, soit-elle une cathédrale ou une bazar.

Cela passe par la confiance mutuelle, l’organisation et la communication. Un jour, je suis venu à travers ce texte — apparemment célèbre — de Melvin E. Conway, How do comittes invent. Ce texte est assez long, et assez ancien — le genre d’article typique qui est re-découvert tous les deux ans environ. Ce qu’il faut retenir sur sa thèse est son concept de homomomorphisme entre l’organisation et les systèmes qu’ils produisent : en bref, « Toute organisation qui conçoit un système (défini plus largement ici comme système d’information) produira inévitablement une conception dont la structure et l’organisation est une copie de la structure de communication de l’organisation ». Cette vue peut être appliqué aux logiciels de construction d’organisation, mais pas seulement : si vous avez quatre équipes travaillant sur un logiciel, sur le long terme, vous obtiendrez un logiciel qui peut être décomposé en quatre parties. Si vous avez des gens qui sont organisés, vous êtes enclin à obtenir un logiciel qui est organisé aussi bien ; si vous avez des personnes qui sont communicatives, vous êtes enclin à avoir un logiciel qui est facilement compréhensible ; etc.

Que ce texte soit assez abstrait et logique dans sa volonté de prouver son point de vue1

Comment s’assurer qu’une bonne communication peut exister au sein d’une organisation pour mieux construire un logiciel ?

Des outils pour communiquer et documenter efficacement

Lors de mon premier stage, nous avons reçu la visite d’un ingénieur logiciel senior d’une banque. L’objectif de cette visite était de présenter leur stack technique et la façon dont ils construirent leur pipeline de stockage et de traitement des données, afin de partager leurs connaissances, leurs bonnes pratiques et leurs risques.

La présentation était claire, concise mais exhaustive. Les gens intéragissaient avec beaucoup de questions sur de nombreux points de conception mais aussi sur beaucoup de points et détails techniques. La session complète dure près de 45 minutes. Vous vous demandez ce qui a été utilisé pour faire une telle présentation ? Un petit jeu de diapositives, composé d’une seule slide avec un diagramme UML.

Quand j’étais à l’université, un professeur passait littéralement son temps à donner des conférences expliquant les avantages de l’UML. J’étais assez convaincu mais un peu sceptique quant à l’acceptabilité d’un tel outils dans les entreprises. Mais après cette présentation, j’ai compris le vrai pouvoir d’un tel langage.

Dans le monde de workflow agile et scrumbatique, il semble que les gens ne pensent pas vraiment ou ne croient pas ou ne veulent pas considérer des outils comme UML ; la raison principale — et souvent recevable — étant que le temps est généralement contraint et que l’investir à documenter du code c’est ne pas en investir dans l’écriture du code.

Le problème de la documentation du code

Se lancer dans une nouvelle base de code est sûrement la partie la plus difficile de toute contribution dans un projet informatique. Dans ces moments-là, j’aurais vraiment aimé avoir une vue d’ensemble d’un tel projet, plutôt que de sauter dans les détails du code directement. Mais lorsqu’il n’y a de documentation, il n’y a pas d’autre choix que de se lancer.

De plus, je travaille moi-même sur des projets personnels et j’aimerais disposer de plus de temps ou de facilité pour les documenter et pour maintenir ces documentations.

J’ai utilisé un langage de présentation pour UML, PlantUML3, après une suggestion très rapide et fortuite de quelqu’un de ma première entreprise qui voulait documenter son travail. Jusqu’à présent, je l’utilisais pour documenter des projets ou même parfois pour exposer aux gens des propositions de design ; ou même juste lorsque j’avais besoin d’organiser mes pensées.

En utilisant Atom et quelques autres extensions 4, vous pouvez facilement dessiner des diagrammes en quelques minutes : la syntaxe est vraiment très simple à apprendre et à utiliser, et ce que vous commencer à faire termine généralement comme l’élément de documentation final que vous souhaitiez avoir. 5.

Pourtant, le problème principal de documenter un logiciel n’est pas de l’écrire, c’est plutôt de le maintenir en phase avec le code : mettre à jour une ancienne documentation est vraiment pénible, car il faut garder une trace de ce qui existe encore et de ce qui ne l’est pas si on le fait manuellement.

Des outils existent pour que la documentation soit en phase avec le code réel : c’est par exemple le cas deSphinx ou Doxygen. Ces outils sont utiles, mais restent à un niveau inférieur de documentation du code : le niveau des signatures.

Je suis convaincu que beaucoup d’autres personnes voudraient comprendre une base de code nouvelle rapidement tout en minimisant le temps et les efforts qu’ils consacrent à la documentation de ce qui suit plus grande vue d’ensemble.

Je suis convaincu que les gens seraient enclins à apprendre UML s’ils pouvaient l’utiliser d’une manière vraiment efficace, et je suis aussi convaincu que cela pourrait rendre les logiciels plus appropriable pour tout le monde, y compris pour les non développeurs.

Une proposition pragmatique pour documenter du logiciel

J’ai créé pulm6, un CLI pour générer automatiquement des scripts PlantUML à partir du code source 7.

Un petit exemple reflectif

Pour donner un petit exemple de pulm, quoi de mieux que d’utiliser son code source directement ?

Vous pouvez tout d’abord installer pulm avec:

$ pip install pulm

Remarque: pulm ne supporte et ne supportera jamais Python 2 tout simplement parce que Python 2 est en fin de vie.

En clonant le dépôt vous pouvez ainsi générer le script PlantUML:

$ git clone http://github.com/jjerphan/pulm.git
$ pulm pulm/pulm

Ce que vous obtienrez est une description du module en question qui reprend les différentes classes utiliser dans pulm lui-même.

Vous pouvez générer un diagramme en raster ou en vectoriel avec la puissance de la plomberie UNIX ainsi:

$ ./pulm/pulm.py – path ./pulm/pulm.py | plantuml – p > out/pulm.png && open
out/pulm.png

et vous obtiendrez quelque chose semblable à ceci:

pulm class diagram

Et la suites?

C’est vraiment minime pour l’instant : j’utiliserai cela pour re-documenter des projets précédents avec plus tard, en corrigeant des choses pour qu’il fonctionne plus généralement utilisable.

Ce que je vois pour cet outil est un usage similaire à d’autres outils comme Black qui peuvent être facilement ajoutés via dans une intégration continue et dont les artefacts peuvent être intégrés dans une documentation en ligne.

Il faut que je réfléchisse et que je conçoive cela davantage : les contributions sont vraiment les bienvenues !


  1. Voir la « preuve » et les diagrammes, dans la section Relating the Two. 2 ↩
  2. , leurs principaux arguments sont valables. ↩
  3. Certains utilisent aussi Mermaid qui est assez sympa pour dessiner des diagrammes mais cet outil est peut-être plus adapté pour les diagrammes que PlantUML ne gère pas, comme les diagrammes de Gantt ou de branchement git. Si vous souhaitez avoir un bon aperçu et une bonne comparaison de ces deux outils, ce billet de blog vous sera utile. ↩
  4. Principalement, language-plantuml, et plantuml-viewer. ↩
  5. Cependant, vous pouvez aurez peut-être besoin de régler vous mêmes les problèmes de layout s’il y a plus de 10 classes, mais cela est relativement gérable.  ↩
  6. C’est un raccourci pour Python ULM_’ ; ULM pour « ultra-léger motorisé » : quelque chose de léger qui vous donne une vue d’ensemble du paysage. Aussi un petit jeu de mots pour UML. Oui, je n’étais inspiré du tout pour trouver un bon nom. ↩
  7. Certains projets existent ou existaient, mais leurs status n’est pas clair : PyCharm a bien un générateur de diagramme UML, mais ceci n’est disponible que dans la Enterprise Edition de l’IDE ; il y a aussi Pyreverse mais l’état de cet outil et la façon dont on peut y contribuer est assez difficile à trouver.  ↩