Merci Riduidel pour cet article (
http://nicolas-delsaux.hd.free.fr/Shaarli/?_Abm9A), ça me fait réaliser une chose:
Un développeur a deux choses en main: Le problème qu'on lui demande de résoudre, et la technique qui lui permet de le résoudre.
On cherche à avoir la technique la plus efficace, afin de se concentrer sur le problème.
L'objectif, c'est le problème.
Donc nous avons conçu des outils pour nous simplifier la vie, pour rendre la partie technique plus efficace. C'est tout naturel.
Seulement ces outils censés nous simplifier la vie ajoutent en réalité une *charge mentale* aux développeurs.
Git est censé nous aider à gérer plus facilement les sources et leur modification. Mais il est complexe et impose un investissement intellectuel non négligeable, une charge mentale pour l'utiliser correctement.
Docker est censé simplifier le déploiement. Mais il a son lot de problème et impose une charge mentale pour savoir l'utiliser et régler ses problèmes spécifiques.
Les frameworks comme Vue.js/Angular/React sont censés simplifier et fluidifier le développement du front au back, mais nécessitent de comprendre et maîtriser leurs arcanes bien spécifiques avant même de produire un écran.
Tout ces outils, cumulés, finissent par imposer aux développeurs une charge mentale énorme sur la partie technique avant même de pouvoir commencer à produire du code, avant même de commencer à travailler concrètement sur le problème initial à résoudre.
Est-ce que ça vaut le coup ? Est-ce qu'on a vraiment gagné du temps ? Est-ce qu'on en gagnera à plus long terme avec ces outils ? Je ne sais pas.
En fait si, je sais un peu. Si on maîtrisait totalement *chacun* de ces outils, on gagnerait sans doute du temps, à court et à long terme. Cela ne fait aucun doute. Ces outils ont été conçus par des gens brillants, qui arrivent (par des sites web ou des conférences) à nous montrer tout le bien qu'ils peuvent produire. C'est beau, ça a l'air de marcher magnifiquement. Mais c'est normal: Ils maîtrisent à la perfection ces outils. Ils les ont conçus.
Dans la pratique, je constate que ces énormes cathédrales sont rarement bien maîtrisées (c'est le sujet de l'article), et que les gens perdent du temps à trouver comment bien faire les choses, voir comment faire les choses tout court. Non pas à cause du code qu'ils ont produit, mais déjà à cause des outils eux-mêmes.
Et c'est même pire que ça: Ces outils imposent une façon de penser spécifique. Mal comprise - et donc mal utilisée - cela impactera le code produit, qui non seulement sera sous-optimal par rapport au framework mais - comme il ne rentre pas bien dans l'état d'esprit du framework - sera compliqué à maintenir et faire évoluer. J'ai constaté ça sur divers projets.
Le monde du développement a oublié le principe du KISS pour se faire plaisir sur des outils qui - pris individuellement - sont séduisants. Du moins sur leur promesses.
Faites attention à la charge mentale que vous vous imposez en ajoutant ces outils.
Et un dernier mot d'avertissement: Faites attention à la perennité des outils que vous choisissez. Je pense en particulier aux frameworks Javascript dont la durée de vie est parfois particulièrement courte. C'est une dette technique que vous paierez. Et cher.
(Je le sais, je bosse en partie sur du WebObjects. Vous ne connaissez pas WebObjects ? Pourtant c'est le framework web qui était porté par une boîte aux moyen titanesques: Apple. Qui a décidé du jour au lendemain que ça ne l'intéressait plus.)
Grosse pensée pour les gens qui ont investi du temps à comprendre et maîtriser des technos mortes (Silverlight, etc.))
(
Permalink)