« Ne me donne pas de poisson, apprend moi plutôt à pêcher » Phrase de Mao Tsé Toung (ou de Confucius, à vous de choisir)
(Suite du chapitre 2 – L’âge d’or du développement web c’est maintenant)
Si le développement d’applications semble réservé à un petit nombre de geeks, c’est certainement à cause de la mythologie qui entoure la figure du développeur, tel un sorcier, adepte des langages les plus ésotériques, choisi depuis l’enfance pour son talent et sa passion des machines, héritier d’un savoir transmis par ses pairs au cours de longues nuits de chats et de pages de forums sybillines…
« Toute technologie suffisamment avancée est indiscernable de la magie », écrivait Arthur C. Clarke, l’auteur de 2001: A Space Odyssey.
En réalité l’art de coder est ouvert à tous, et probablement le meilleur moyen de dompter la technologie que nous utilisons quotidiennement. Malheureusement il est souvent enseigné de manière théorique et sur des exemples simples, à la manière d’un jeu. Si cet aspect ludique permet d’ouvrir l’art de coder à un plus grand nombre, il reste difficile de passer ensuite à l’application réelle, et à la création de logiciels utiles pour soi ou pour le plus grand nombre.
Et si au lieu de cela nous étions capables d’apprendre à coder au fil de l’eau, en fonction de nos idées et de nos besoins ? Et d’appliquer immédiatement nos nouvelles connaissances à des projets concrets ? Un exemple : j’aimerais trouver une application qui m’apprenne à faire des Sudoku avancés, mais sans me donner la solution, juste en me fournissant des indices lorsque je sèche pendant plus de 30 secondes. Cette application n’existe pas, et pourtant je suis sur qu’elle pourrait séduire beaucoup d’autres amateurs de Sudokus. Comment puis-je apprendre à créer cette application ?
Comme nous l’avons vu au chapitre précédent, je dois commencer par décrire plus précisément mon idée, et ensuite pour chaque scénario à implémenter choisir les bons composants technologiques, en me laissant guider par mon environnement (Django, Rails,…) qui me propose presque toujours une architecture par défaut. Il y aura souvent des composants que je ne connais pas encore, mais que je peux apprendre à utiliser au fil de l’eau.
Peut-être demain disposerons nous pour cela d’environnements dotés d’intelligence artificielle auxquels il suffira que j’explique mon idée d’application pour que celle-ci apparaisse sous mes yeux sans que j’aie besoin d’écrire une seule ligne. La parole vague et le geste auront alors remplacé l’écriture chirurgicale de dizaines voire de milliers de lignes de code ! Pourquoi pas ? Ce jour là l’imagination n’aura plus de limites. Mais aujourd’hui il faut en passer par l’écriture de code, et pour cela rien ne vaut l’aide de mes pairs qui sont passés par là avant moi.
En effet les premières sources d’enseignement pour ceux comme moi qui souhaitent développer leurs applications, sont d’abord le condensé de savoir laissé par nos pairs dans des documentations en ligne [1] ou dans des vidéos d’explications, et ensuite les forums [2] où d’autres ont posé les mêmes questions avant nous. Souvent il est donc suffisant de suivre les traces de nos prédécesseurs pour faire les bons choix.
Au fil du développement d’une application il y a plusieurs types de questions que j’essaye de résoudre : (1) Quels composants utiliser pour réaliser telle fonction ? (2) Comment utiliser ce composant ? (3) Que veut dire ce message d’erreur ? ce qui équivaut à la question « Pourquoi ce que j’ai fait ne fonctionne pas ? »
La documentation en ligne est surtout faite pour répondre aux questions du type (2), tandis que les forums en ligne sont souvent la seule source d’aide pour les questions du type (3).
Pour la première de ces questions (« quels composants utiliser ? ») il faut parfois chercher un peu plus longtemps. Les cours théoriques, les vidéos d’exemples et certaines parties de la documentation en ligne, sont faits pour vous donner cette culture qui vous permettra ensuite de concevoir seul l’architecture de ce que vous imaginez. Si je veux absolument travailler seul il faudra que je prenne le temps de parcourir ces contenus, d’apprendre l’existence de tel ou tel composant et ce que je peux faire avec. Mais je peux aussi choisir d’assembler ou de rejoindre une équipe, et bénéficier de la connaissance des autres.
Il me semble ainsi que le rôle d’ « architecte logiciel » peut jouer un rôle déterminant dans le développement collaboratif d’applications par le plus grand nombre. Celui-ci peut rapidement apporter sa culture technologique pour convertir les scénarios imaginés par le groupe en architectures logicielles. Beaucoup de théoriciens planchent sur ce domaine depuis avant l’invention de l’informatique pour trouver les moyens de cartographier exactement l’architecture d’un système technologique : Merise, UML, SysML… Je ne parle pas de cela. L’architecte peut aussi plus simplement guider le développeur en lui expliquant quels composants utiliser pour réaliser un scénario et comment il pense qu’il faudrait les relier entre eux. C’est une discussion et un enseignement plutôt qu’une relation maitre – esclave. Le but est que le développeur entrevoie les différents composants qu’il peut mettre en oeuvre, et fasse ensuite ses propres choix. Ainsi l’architecte apporte très rapidement une valeur importante au groupe, et peut apporter cette valeur à un grand nombre de développeurs sur un ou plusieurs projets.
A cette approche que je réserverais plutôt pour le début d’un projet ou pour des scénarios innovants, on pourrait ajouter la possibilité de créer un chemin d’apprentissage pour les développeurs qui souhaitent rejoindre un projet en cours de route. Un peu comme ces nouveaux colons qui arrivaient en Amérique, et avant de trouver leur place au soleil, devaient parcourir le territoire entre leur port d’arrivée et leur village de destination, et apprendre au passage à connaitre ce nouveau territoire, ses habitants et leurs règles [3]. Il me semble qu’il serait facile de créer ces chemins de découverte du code créé par une équipe en retraçant pour le nouvel arrivant l’ordre d’arrivée des différents composants, et en lui proposant de s’entrainer en codant lui-même certains scénarios déjà réalisés. De cette manière il arriverait ensuite rapidement et préparé au mieux à participer au développement de nouveaux scénarios. De plus la création de ce parcours pourrait être automatisée en utilisant l’historique du code et les scénarios de test disponibles.
(A suivre…)
Notes
[1] Exemples de documentation: Django : https://docs.djangoproject.com/; Rails : https://guides.rubyonrails.org/; Python : https://www.w3schools.com/python/; Ruby : https://www.ruby-lang.org/fr/documentation/
[2] Exemple de forums: https://stackoverflow.com/questions/tagged/django
[3] Voir à ce sujet des curiosités comme le chapitre 2 de ce livre de 1884 sur Les Français en Californie.