Ayant créé Tech Me Up il y a 13 ans maintenant, je dirai qu’à mon sens, opter pour la création de sa propre activité revient principalement à choisir la liberté de l’entreprenariat à la sécurité du salariat.
Il y a bien sûr des avantages et des inconvénients pour chacun de ces statuts. Mais, même s’ils j’ai connu certaines périodes plus difficiles, je n’ai globalement jamais regretté mon choix de me mettre à mon compte.
Par ailleurs, le deal est le suivant : pour gagner une certaine liberté d’agenda, de choix de clients, et de missions, il faut aussi accepter d’être multitâches, et de gérer une grande TODO LIST aux activités hétérogènes : administratif, compta, commerce, fond de commerce… et création de son site.
A ce propos, j’ai pu discuter avec bon nombre de personnes qui lançaient leur activité, et avaient pour objectif de créer leur propre site. Souvent, il me contactaient pour savoir quelle formation je leur recommandais. Beaucoup m’ont expliqué qu’avant de décider de créer leur site eux-même, ils avaient considéré plusieurs options : externaliser sa création à des professionnels, utiliser des site builders, etc.
Comme cette thématique semble intéresser beaucoup d’indépendants et entrepreneurs en création d’activité, j’ai essayé de compiler, dans cette page, les diverses options offertes aux entrepreneurs qui souhaitent créer leur site, avant de… passer à la prochaine étape de leur grande TODO LIST !
Prévisions sur l’évolution du développement , basées sur TRIZ
Les Lois d’évolutions de TRIZ expliquent que le développement va se simplifier et tendre vers un idéal. En m’inspirant de cette méthode d’innovation, je pense que cette simplification se fera par 2 moyens principaux, déclinés en 5 tendances.
Simplification par réduction des erreurs
visualisation ergonomique
abstraction
Simplification par réduction des tâches à accomplir
unification
automatisation
délégation
Je vous propose de détailler ces 5 tendances et de voir en quoi elles nous permettent d’imaginer l’évolution du développement. A titre d’exemple, je vous proposerais d’imaginer l’évolution des tests unitaires.
Visualisation ergonomique
Visualisation ergonomique = user-friendly
Linux est gratuit, open-source, rapide, et secure comparé à Windows ou OSX qui pourtant sont bien plus populaires pour les utilisateurs lambda.
Ce n’est pas un hasard. Une interface graphique bien pensée est plus compréhensible, plus mémorisable, plus intuitive et donne une bonne vue d’ensemble des opérations possibles. Windows et OSX sont bien plus visuellement ergonomiques, plus user-friendly, et plus compatibles que Linux, qu’il soit utilisé en ligne de commande ou en GUI. Leur interface graphique bien pensée les rend tout simplement plus simples à utiliser, ce qui est le nerf de la guerre dans l’adoption d’un techno, surtout par des non-techs.
A l’inverse, la CLI nécessite la plupart du temps un apprentissage, et/ou une doc de référence, et n’est pas intuitive. Oui, elle est utile dans certains cas, voire incontournable pour certaines opérations qui sont bien plus rapides à faire avec une bonne ligne de commande plutôt que par une interface. Mais je suis convaincu que trop souvent, la CLI n’est pas le bon choix, et relève d’une implémentation de fonctionnalité qui n’a pas été jusqu’au bout : il manque un layer graphique.
Visualisation ergonomique = moins d’erreurs
Par ailleurs, une interface graphique permet d’éviter les erreurs qui pourraient être commises via du code ou via une ligne de commande. Cela est dû au fait qu’elles peuvent facilement contraindre les actions ou les options possibles. On le voit par exemple au travers des applications No ou LowCode. Dans bubble.io, si nous assignons une action à un bouton, ça ressemble à ça :
Bubble.io
Il y a une liste déroulante qui permet de choisir le type d’évènement à détecter (clic). Plusieurs autres qui permettent de choisir les actions à réaliser (identifier, envoyer un e-mail, rediriger vers l’accueil). Non seulement c’est intuitif, mais ces listes déroulantes, contrairement au code, empêchent les erreurs de syntaxes, l’appel de fonctions inadéquates, ou le passages de paramètres incohérents.
Visualisation ergonomique = gain de temps
Les interfaces user-friendly font également gagner du temps. Elles pourront même en faire gagner aux devs, et ce même s’ils pourraient s’en passer car ils ont la capacité d’apprendre la CLI ou les langages.
Car là n’est pas la question : nous cherchons à savoir ce qui est le plus efficace pour maitriser une API en partant de 0. Si vous êtes un virtuose du shell ou de la CLI d’un framework, je ne doute pas dans ce cas que vous pouvez faire les choses rapidement.
Mais vous avez dû apprendre ces commandes, ce qui représente un coût non-négligeable en termes de temps. Et lorsque nous parlons de Code Ergonomy, nous cherchons à réduire ce coût. Hors une API inconnue est bien plus rapide à maitriser lorsqu’elle est visuelle que lorsque elle est utilisable par du code ou par une CLI.
Prenons l’exemple de la mise en place d’un environnement de développement. A l’heure actuelle, on peut utiliser une première ligne de commande pour cloner un projet git, ou pour lancer la création d’un projet type. Il faut ensuite lancer une nouvelle commande pour lancer l’importation des modules. Puis en lancer une autre pour servir le projet, avec entre temps une possible modification de webpack ou autre bundler afin de coller à nos exigences en termes de transpilation, de linting, de hot-reloading, etc. Dans codesandbox.io, tout cela est visuel, et nécessite 3 clics. Bref, on gagne du temps.
configuration de l’environnement avec codesandbox.io
Est-ce aux devs de réaliser des UI efficaces ?
Ce n’est pas l’idéal, mais lorsque l’on travaille sur un projet solo ou dans une petite équipe qui n’a pas de graphiste ou d’expert UX, les devs sont amenés à concevoir des interfaces bien pensées.
Trop souvent pourtant, ils ont tendance à négliger l’ergonomie visuelle, considérant que ce n’est pas de leur ressort et que leur valeur-ajoutée réside dans la mise en place de fonctionnalités. Il y a un cloisonnement inopportun entre ce qui relève de ingénierie et ce qui relève du graphisme.
Pourtant, à la Renaissance, il n’y avait pas de cloisonnement entre ce qui relevait de la Science ou de l’Art. On cherchait à être complet. Je pense donc que les devs gagneraient à se confronter à l’exercice de création d’une UI efficace et bien pensée.
Léonard De Vinci : scientifique, ingénieur, inventeur, anatomiste, peintre, sculpteur, architecte, urbaniste, botaniste, musicien, poète, philosophe et écrivain
Abstraction
Utiliser un langage de haut-niveau, et séparer la description d’une application métier, de son moteur, permet de bénéficier des évolutions permanentes des patterns et syntaxes sans avoir à se former continuellement : car l’application reste optimisée sans avoir à être réécrite par leurs devs. Cela nécessite un article à part entière que vous trouverez ici.
Unification
Dans les lois d’évolution de TRIZ, on observe de multiples tendances. L’une d’elle concerne la fusion des composants d’un système. Voyez plutôt les tendances “Using dissimilar Elements” ou “Using Similar Elements” dans ce graphique.
Tiré de l’excellent livre Triz for Engineers de Karen Gadd, page 444.
Les multiples composants du développement vont s’unifier pour devenir un environnement de programmation tout-en-un, un peu comme Flash il y a des années (bien qu’il manquait le côté serveur), Meteor, Unreal Engine, ou Unity.
Unreal engine
Il y aura ainsi une fusion des multiples outils utilisés aujourd’hui séparément : bundler, gestionnaire de modules, versioning, transpiler, CLI, etc. Tout sera intégré dans l’éditeur de code, le plus souvent sous forme d’options, de paramètres, et de menus.
Là encore, on le voit bien dans codesandbox.io ainsi que dans visual studio code qui intègre un terminal, une console de debug, et toutes sortes de modules.
Visual Studio Code
La loi d’évolution n°6 de TRIZ — Transition vers le super système, spécifie également qu’un système devient une partie de son super-système, c’est à dire de son environnement.
Ainsi l’environnement de programmation (système) sera intégré au cloud (super-système).Il n’y aura donc plus non-plus de séparation local / distant. Tout sera en ligne.
On le voit déjà avec CodeSpaces de GitHub (encore en version beta) qui est un environnement de développement intégré au cloud :
Codespaces
Automatisation
C’est surement le point le plus important. Grâce à l’automatisation, moins, voir plus du tout de configuration.
Plus de configuration d’environnement
A la manière de codesandbox ou grâce au tree-shaking de parceljs, capable de s’autoconfigurer en analysant lui même le code source et les dépendances d’un projet.
Plus de configuration du versioning
Utiliser la ligne de commande peut être amélioré. Les sauvegardes peuvent être partiellement automatisées, un peu comme les sauvegardes incrémentielles de Synology Cloud Backup ou dans la TimeMachine d’Apple :
Apple Time Machine permet de parcourir la frise du temps à droite et de retrouver l’état d’un projet passé par de multiples fenêtres superposées
J’ouvre une parenthèse pour préciser que visuellement, le versioning pourrait s’inspirer du gestionnaire d’historique de WordPress ou de la suite Adobe, mais avec les capacités de forks, de merge et autres subtilités de git. Il y a beaucoup de possibilité d’évolutions, mais en attendant, des outils comme Git Kraken ou Git Tower proposent un UI améliorée.
Git Kraken
Plus de configuration du cloud ni de déploiements fastidieux
A la manière de softaculous, qui permet de mettre en place ou de cloner un WordPress ou autre système en un clic, les clouds pourraient être automatisés.
Softaculous
Les hébergeur pourraient techniquement détecter le boilerplate et les fichiers de configuration de nos projets, en déduire toutes les dépendances, les mettre en place et les configurer. Après tout nous disions que Parcel est capable de le faire pour les environnements de dev.
Par ailleurs, le déploiement pourraient se faire via un bouton [Déployer] dans l’IDE. Voir Codespaces.
Les services de Cloud ont encore de larges possibilités d’évolutions, car ils ne se sont pas assez adaptés aux nouvelles pratiques du développement front. Ils devraient s’automatiser car cela rendrait un vrai service aux développeurs, qui sont leurs utilisateurs et clients typiques. Ils amélioreraient ainsi considérablement leurs parts de marché.
Plus de programmation des tests unitaires
Au-delà du débat sur l’utilité des tests unitaires, dont nous nous sommes passés pendant des dizaines d’années alors que beaucoup d’applications restaient de bonne qualité (de part les tests utilisateurs), nous sommes encore trop bas niveau quand nous les écrivons.
Ces tests pourraient être partiellement automatisés. J’aborderais ce cas plus en détail dans la dernière partie de cet article.
Mais surtout : moins, voir pas du tout, de code
L’app pourrait être décrite soit par un langage de haut-niveau, soit visuellement, et traduite par un moteur d’interprétation.
On peut encore citer ici les plateformes No ou Low code. L’exemple le plus parlant à mon sens est encore bubble.io qui reste très flexible et n’est pas cantonné à la création de sites web vitrines comme beaucoup pourraient le penser. Testez donc le tutoriels de 5min pour en avoir une idée.
Cette séparation Description / Moteur est la condition pour une automatisation efficace. On la trouve dans les SGBD, avec le SQL qui peut être combiné aux moteurs MyISAM ou InnoDB par exemple.
Il y a beaucoup de chose à dire à ce sujet, que je traite avec l’Abstraction, dans cet article.
Délégation
Actuellement les devs s’occupent a peu de tout : de l’architecture, de la configuration de l’environnement, du développement, des tests, du débogage, du versioning, de la configuration serveur, et des mises en ligne. Comment tout maitriser ? Peut-on être spécialiste en tout ? Acceptons-nous d’être spécialisé en rien ? Ou peut faire plus optimisé ?
Les tâches qui incombent aux développeurs vont se réduire : ce qui ne pourra être automatisé sera simplifié. Ce qui ne pourra pas non plus être simplifié sera confié à des spécialistes.
Je pense particulièrement à ce qui relève de la gestion du cloud, dont j’ai parlé plus haut : si un hébergeur offre un déploiement réellement en un clic, adapté aux architectures les plus courantes, il remportera de nombreuses parts de marché.
Par ailleurs, au sein même de la communauté dev., je pense qu’une distinction entre les dev. créateurs d’application et les dev. créateurs d’outils sera nécessaire, afin de se spécialiser dans l’apprentissage de ce qui nous est réellement utile. Pour ne pas me répéter, je vous invite de nouveau à lire cet article pour plus de détails.
Exemple : évolution des tests unitaires
Essayons de voir à travers cet exemple comment ces 5 tendances nous permettent d’imaginer l’évolution des tests unitaires.
Le problème
Le problème, c’est qu’en plus d’être rébarbative, l’écriture des tests unitaires double grosso-modo le temps et donc le coût de développement.
Axe d’évolution, à partir des 5 principes
Les tests seraient intégrés à l’IDE qui pourrait auto-tester un projet (unification des composants et délégation des tests à l’IDE) en appuyant sur un bouton plutôt que par une CLI (abstraction, visualisation).
L’IDE testerait automatiquement (automatisation), pour chaque composant d’un interface, toutes les évènements possibles (un bouton serait cliqué, double-cliqué, survolé, tandis ce qu’un formulaire serait envoyé, remis à zéro, etc.). Les réactions aux évènements seraient analysées et cela permettrait de mettre en valeur les incohérences ou conflits de l’application.
Par exemple, l’IDE pourrait se rendre compte qu’une même fonction serait invoquée plusieurs fois mais avec des arguments de types différents, ou bien qu’elle retournerait des valeurs de types différents.
Il en résulterait alors une liste de ces incohérences trouvées dans une interface (visualisation), qui nous proposerait de trancher sur l’input ou l’output réellement attendu. Cela se rapprocherait de GitKraken lorsqu’il nous demande de trancher lors d’un merge conflict, mais ici, le choix se ferait le plus souvent au moyen de listes déroulantes.
Les résolutions de conflits permettraient ainsi de faire évoluer le fichier de configuration qu’à ce jour nous créons à la main.
Ce que les développeurs peuvent apprendre des géants
2009, Berlin : Usain Bolt bat le record du monde du 100m hommes en 9,58 secondes. Voyez comme cela parait simple, pour lui :
2012, Pékin : Lang Lang joue La Campanella. Cela a l’air si simple pour lui qu’on dirait qu’il s’amuse :
Malgré la complexité sous-jacente de ces métiers, malgré tout le temps et les efforts qui ont été nécessaires pour atteindre le niveau maximal, lorsque l’on regarde leur manière d’être et de faire, cela parait simple.
Trop souvent, on pense que ce qui semble simple n’est pas optimisé
Bien avant mes premiers articles sur la simplication du développement, j’ai eu de nombreuses discussions avec des développeurs maîtrisant les complexes frameworks actuels que sont Angular ou React, ainsi que leurs outils d’environnement associés.
Souvent, mes interlocuteurs n’étaient pas d’accord sur le fait que le développement devrait devenir et deviendra simple. Pour eux, la maîtrise de la technologie est naturellement complexe et le restera.
Ils disaient que cela faisait partie de notre travail, en tant que devs, d’apprendre continuellement afin de rester à jour sur les dernières évolutions techniques. C’est ainsi que les applications peuvent évoluer et continuer à être optimisées.
La plupart d’entre eux n’ont pas ressenti le besoin d’avoir des outils ou des frameworks simples. Car c’est à nous de nous adapter. Nous devons nous former continuellement. Parce qu’en tant que développeurs ou ingénieurs, nous en sommes capables.
Le code le plus optimisé est un code simple
Usain Bolt et Lang Lang ont atteint le sommet de leurs domaines respectifs.
Quand Usain Bolt court, ça semble simple, mais ça ne l’est pas. Quand Lang Lang joue, ça semble simple, mais ça ne l’est pas. Sous le capot, il y a des milliers d’heures d’apprentissage et d’entrainement complexe.
Il est possible d’imaginer des outils de développement simples et de haut niveau, qui nous permettraient d’atteindre des performances optimales en générant les applications les plus performantes. Des outils de premier ordre qui semblent simples, mais qui ne le sont pas. Des outils que nous pouvons utiliser de façon simple, mais qui sont performants en raison de leur complexité sous-jacente.
Vous n’êtes pas un mauvais développeur si vous préférez les syntaxes et patterns simples, lisibles, et de haut-niveau, au lieu de syntaxes et patterns certes à la mode mais confus ou complexes. Parce que si les outils étaient bien pensés, ils pourraient offrir à la fois simplicité et performance. C’est techniquement possible.
Outre l’optimisation, simplicité signifie meilleure lisibilité, meilleure maintenance, meilleure évolutivité, meilleur travail d’équipe, moins de temps de formation et donc moins de coût global de développement.
Et la Simplicité apporte quelque chose de plus.
Quelque chose que vous trouverez dans la façon d’être des gens simples.
Quelque chose que vous trouverez dans de rares démonstrations mathématiques.
Quelque chose que vous trouverez dans la programmation, la science, la mode ou le design.
Elle apporte l’Élégance.
Développeur et formateur web depuis une quinzaine d’années, je n’ai pas été épargné par la “Javascript Fatigue”. Ma recherche d’une “cure” à cette fatigue, m’a amené à réfléchir aux absurdités de la programmation, et à l’environnement de programmation idéal.
J’aimerais, dans cet article introductif, vous exposer ce dont je suis persuadé : le développement va se simplifier. Par la suite, je préparerais une série d’articles décrivant en détail les raisons de mon opinion. Cela vous permettra je l’espère, d’entrevoir à quoi ressembleront les prochains environnements de développement, ainsi que la programmation web.
Mes propos s’inspirent de TRIZ
Imaginer l’avenir, c’est plus facile en se basant sur une méthode. A plusieurs reprise, je ferai référence à TRIZ, une méthode soviétique dont je me suis inspiré, permettant à la fois de résoudre des problèmes d’innovation, et d’innover en prévoyant l’évolution des technologies.
TRIZ à fait ses preuves : à titre d’exemple, Samsung l’utilise depuis des années et elle lui a permit de déposer bon nombre de brevets. Par ailleurs, cette méthode est enseignée dès l’école en Corée du Sud, pays on ne peut plus innovant.
La première chose à savoir, d’après la Loi d’évolution N°4 — Accroissement de l’idéalité, c’est que les outils de programmation, comme tout système, vont tendre vers un idéal. L’idéal, au sens de TRIZ, est définit ainsi :
Un système est idéal s’il offre un maximum de bénéfices, sans coût, et sans effets néfastes.
Cette équation simple remet donc en question une croyance répandue auprès de nombreux développeurs, selon laquelle si les outils actuels permettent de créer des applications plus sûres, plus fiables, plus orientées travail en équipe, plus évolutives, et plus réactives, il faudrait absolument les utiliser.
Ce sont en effet de nombreux bénéfices qu’apportent les outils et frameworks modernes. Sauf que l’idéal n’est pas atteint pour une raison simple :
Les outils et frameworks actuels ont un coût et des effets néfastes
Ne le pensez-vous pas ? En voici une liste non-exhaustive :
confusion dans les choix techniques due à la multiplication ****d’outils concurrents (frameworks, librairies, et outils/modules des environnements)
manque de pérennité des applications, due à ces choix techniques incertains, ainsi qu’aux changements fréquents des syntaxes, et des bonnes pratiques
nécessité de posséder de nombreuses connaissanceset de se former continuellement afin de maitriser les bonnes pratiques nécessaires à la production d’une application ad-hoc structurée, sécurisée, testée, et optimisée
difficulté pour recruter des profils de développeurs à la fois experts et polyvalents, et difficulté pour trouver des missions pour les développeurs non-aguerris aux technos tendances
augmentation du temps de production dus à l’augmentation générale du temps de formation, de paramétrage de l’environnement, du développement, de l’optimisation, des débogages, des tests, des mises en production, etc.
augmentation des coûts de production dû à cette augmentation du temps de production, ainsi qu’à à la rémunération des (rares) développeurs stars maitrisant toutes les techs requises
perte d’argent lorsqu’il faut reprendre des applications à cause des changements fréquents des techs, pratiques, et outils tendances
Cette liste pourrait être allongée et détaillée. Mais il faut simplement retenir que d’après les lois d’évolutions de TRIZ, ces problèmes actuels trouveront une solution.
Ne faudrait-il pas juste s’(auto-)former ?
Certains d’entre vous pensent peut-être que la solution, c’est de s’y mettre. D’apprendre les dernières syntaxes, patterns, outils, et frameworks actuels. D’autres diront qu’il faut se spécialiser dans l’un de ces outils et d’y passer le temps qu’il faut. Qu’après tout ça fait partie de notre métier, qu’il faut toujours ce mettre à jour, parce que c’est comme ça.
Mais demander aux développeurs de se former ou de s’auto-former continuellement est sous-optimisé. Justement parce que la formation représente un coût en termes de temps et/ou d’argent.
Et ce coût est non-négligeable, même pour les développeurs confirmés. J’aurai ici voulu pointer sur un article parlant de la javascript fatigue mais il y en a trop et je ne peux choisir. Il y a quelque chose dans cette situation qui ne tourne pas rond…
Ainsi, le coût d’attendre des devs qu’ils se forment continuellement réduit l’idéalité.Ce n’est pas assez efficace. En revanche, il y a une autre solution que j’aimerais proposer.
Simplifions le dev.
Il est intéressant de remarquer que la seule SIMPLIFICATION du développement permet de répondre à chacun des problèmes cités.
En effet, si les nombreux outils concurrents actuels (frameworks, librairies, bundlers, langages, etc.) ont des niveaux de flexibilité et d’efficacité proches, le plus simple deviendra le plus populaire, simplement car il est par définition moins coûteux en efforts, en temps de formation, en temps de développement et donc en coût de production.
Pendant un temps cette règle n’était pas totalement vraie car les entreprises et développeurs orientaient leur choix vers des outils promus par des références comme Google (Angular) ou Facebook (React). En effet, la popularité des créateurs de ces outils rassurait les entreprises, qui y voyaient en fait les bénéfices de la pérennité, de la fiabilité, et de l’optimisation. Leur complexité représentait certes un investissement (en terme de formation notamment), mais un investissement sûr et conférant de nombreux bénéfices.
Or le scandale du passage d’AngularJS à Angular, ou encore la nouvelle popularité des frameworks “challengers” comme VueJS ou Svelte, montre que ce critère de popularité est de moins en moins déterminant dans le choix d’une technologie. Parce qu’on s’est rendus compte qu’on peut faire aussi bien, en (un peu) plus simple.
Ainsi la Simplicité devient petit à petit un critère déterminant car elle augmente l’idéalité :on atteint les même bénéfices pour moins de coûts.
Simplification
= moins de temps de formation et moins d’outils concurrents
= moins de temps de développement et moins de pb dans les choix techs
= moins de coûts de développement, moins de difficultés de recrutement et une meilleure pérennité des applications
Ainsi, il y a tout à parier qu’à performances similaires, les solutions plus simples remplaceront petit à petit les solutions plus compliquées.
Conclusion
Plutôt que de se former continuellement, il nous faut changer de paradigme en simplifiant le développement. Simplifier résout de nombreux problèmes engendrés par les pratiques et habitudes actuelles.
Toutefois, cette simplification ne sera efficace et utile qu’à condition de conserver flexibilité et performance offertes par les outils actuels.
Mais cette question mérite d’être abordée plus en détails dans mes prochains articles. Celui-ci se voulait introductif : comme le préconise TRIZ, je souhaitais ici préciser l’objectif à atteindre, en gardant en tête l’idéal.
Dans cet article, j’expliquerai pourquoi les développeurs n’ont pas besoin d’optimiser leurs applications. Cela est lié au fait que le développement Web va évoluer pour devenir plus simple, par l’Abstraction. Je commencerais par comparer les évolutions des voitures et des outils de développement, avant d’expliquer pourquoi je pense que nous nous faisons fausse route. Je proposerais ensuite un moyen de résoudre les problèmes lié au développement web moderne, en reconsidérant les rôles des développeurs et la structure du code source. Je conclurais enfin en abordant une nouvelle façon d’utiliser les frameworks modernes. J’espère que mon point de vue vous paraitra pertinent.
Comparons l’évolution des voitures et des outils de développement
L’évolution de la voiture
Les voitures ont évolué. Elles sont devenues plus rapides, plus sûres, moins consommatrices, moins polluantes. On peut dire qu’elles ont été optimisées. Est-ce que l’utilisation de ces voitures à évolué ?
Non, ou très peu. Un conducteur de voiture en 2020 conduit grosso modo comme un conducteur en 1940.
Il n’a pas besoin de savoir comment gagner en vitesse, sécurité, consommation, ou écologie. C’est la voiture qu’il utilise qui s’en occupe. Des spécialistes ont travaillé sur le sujet et l’on optimisée. Il n’y a pas besoin de savoir comment ça marche pour profiter de ses performances.
L’évolution des langages et des outils de développement
Les langages et outils de développement ont, eux aussi, évolués. Ils permettent de créer des apps plus rapides, plus sûres, moins lourdes, plus fiables, responsives, etc. On peut dire qu’ils ont été optimisés. Est-ce que l’UTILISATION de ces outils et langages à évolué ?
Drastiquement. Un développeur front-end des années 2000 avait simplement besoin de connaitre le HTML et le CSS. Il n’avait aucunement besoin de maitriser un framework JS, de paramétrer un environnement Node, de configurer Webpack, de savoir ce que sont les promises, les immutables, les observables, les design patterns, les appels API, la délégation d’évènements, le hoisting, ou de réaliser des tests unitaires ou fonctionnels.
En 2020, il faut maitriser ces concepts, sous peine de ne pas développer avec les dernières techs tendances et risquer d’être considéré comme quelqu’un créant des applications sous-optimisées.
Nous faisons fausse route
Pourquoi note t’on une telle différence entre l’évolution de la voiture et celle des outils de développement ?
Utilisateurs de voitures
Dans le cas de la voiture, l’utilisateur de la voiture est clairement identifié (M. Tout le monde) et séparé des différent des concepteurs de la voiture (ingénieurs, mécaniciens, designers, etc.).
Il est clair qu’il n’est pas concevable d’attendre de l’utilisateur qu’il connaisse comment ça marche pour pouvoir bénéficier de l’optimisation de la voiture.
Utilisateurs des outils de développement
Dans le cas des outils de création d’applications, les utilisateurs et les concepteurs de ces outils sont tous des développeurs.
Ainsi, il semble naturellement beaucoup plus concevable d’attendre des utilisateurs de ces outils qu’ils comprennent leur fonctionnement, et qu’ils adoptent les bonnes pratiques de codage permettant de favoriser travail d’équipe, maintenabilité, et optimisation.
C’est pourquoi actuellement, la maitrise d’un framework nécessite un long apprentissage : sa mise en place et son boilerplate doivent être démystifiés, les opérations possibles via sa CLI comprises, son organisation et ses design patterns clarifiés. Il faut aussi comprendre quelles sont les principales classes / fonctions utilisées, et quels concepts clés il est nécessaire d’adopter (l’état doit être immuable, le fonctions doivent être pures, etc.).
Ce qui cloche dans le développement moderne
Demander aux utilisateurs d’outils de développement de comprendre des concepts en constante évolution, c’est comme attendre d’un utilisateur de voiture qu’il comprenne de quel type de caoutchouc ses pneus sont faits pour être plus sûrs, quelles fréquences ses radars de stationnement utilisent, ou comment fonctionne l’injection de carburant.
Cela doit rester sous le capot, même si l’utilisateur de la voiture s’avère être un ingénieur et serait capable de comprendre. Car prendre le temps nécessaire pour comprendre a un coût en termes d’efforts, de temps de formation, de temps de pratique, de temps de débogage, et donc de coût de développement.
Il est donc sous-optimal d’attendre des utilisateurs d’outils de développement qu’ils acquièrent toutes ces connaissances afin de favoriser le travail d’équipe, la maintenabilité, et l’optimisation de leurs applications.
Comme pour les concepteurs automobiles, la maîtrise de ces concepts devrait rester l’affaire d’un type particulier de développeurs spécialisés dans la conception d’outils de développement.
2 nouveaux types de développeurs
Au lieu d’un distingo dev. front / dev. back (qui a de moins en moins de sens), je vous propose d’imaginer un distingo dev. utilisateur d’outils / dev. concepteur d’outils.
Développeur utilisateur d’outils
Le développeur utilisateur d’outils à pour mission de créer des sites et applications en suivant un cahier des charges. Il sait réaliser une interface et décrit les composants, les fonctionnalités, et les interactions de l’application.
Développeur concepteur d’outils
Le développeur concepteur d’outils est un spécialiste maitrisant les structures de code les plus optimisées, les designs patterns les plus pertinents pour résoudre un problème donné. Il est en charge de créer et de faire évoluer des outils de développement permettant de réaliser les même fonctions (détections d’évènements, modification de l’interface, sauvegarde, authentification, etc.), mais de manière toujours plus performante.
Application vs moteur
Il est possible de créer des applications qui facilitent le travail d’équipe, sont optimisées et maintenables, sans avoir à maîtriser les meilleurs pratiques et les concepts de programmation toujours plus nombreux. Nous pouvons y parvenir en séparant l’application du moteur.
Application
Les développeurs utilisateurs d’outils de développement ne doivent s’occuper que de la description de leurs applications (fonctionnalités, interactions, composants, interface utilisateur).
Une façon de le faire serait de décrire les applications visuellement. Les applications NoCode telles que bubble.io proposent de le faire, puis de traduire la description visuelle de chaque application en une véritable application. De nombreux développeurs pensent que ces outils offrent des possibilités limitées, mais je vous suggère d’essayer leurs tutoriels de 5 minutes pour voir quelle flexibilité vous pouvez obtenir.
Une autre façon de procéder serait d’utiliser un langage haut-niveau qui ressemblerait à des spécifications fonctionnelles, mais qui décrirait l’application d’une manière beaucoup plus programmatique (donc structurée).
Par exemple : Il existe la possibilité d’identifier l’utilisateur via [e-mail/ mot de passe / empreinte digitale / rétine / etc.] matérialisé par [une boîte de connexion avec 2 champs / un appareil / etc.] Cette boîte utilisera [des enregistrements en base / des enregistrements en fichiers / etc.] En cas de succès, nous [accéderons à une page / ajouterons une entrée en base de données / enverrons un e-mail / etc.]
Ce langage serait écrit dans un seul outil de développement, qui serait configuré pour utiliser un moteur d’optimisation parmi d’autres. Pour la fonctionnalité d’identification de l’utilisateur, chaque moteur offrirait de nombreuses options concernant, par exemple, les entrées [e-mail / mot de passe / emprunte digitale / rétine / etc.], l’affichage [une boîte de connexion de 2 champs / un appareil / etc.], les relations [enregistrements dans la base de données / enregistrements dans le fichier / etc.], ou les actions de sortie [accès à une page / ajout d’une base de données de connexion / envoi d’un e-mail / etc.]
Moteur
Les développeurs concepteurs d’outils travailleraient en fait sur les moteurs. Ils seraient chargés de traduire les descriptions des applications en un code optimisé, bien structuré, bien testé et sans bogue. De temps en temps, il y aurait une mise à jour d’un moteur, pour des performances toujours meilleures. Chaque mise à jour ne casserait rien car les moteurs seraient totalement indépendants des descriptions d’applications.
Pour avoir une idée de la façon dont cela fonctionnerait, vous pouvez penser à ce qui s’est passé avec PHP, puisque son noyau a été remanié à plusieurs reprises. PHP7 est par exemple beaucoup plus rapide que ses prédécesseurs, mais en tant que développeur PHP, vous n’avez pas besoin de comprendre ou de vous soucier de ce qui a changé en interne. La nouvelle version permet de meilleures performances, même si vous conservez le même code d’application. C’est tout ce que vous avez besoin de savoir.
Vous pouvez également penser aux bases de données relationnelles, où la séparation entre l’application et le moteur existe déjà. Les moteurs MyISAM, ou InnoDB, offrent des différences tout en étant liés au même langage SQL.
Les frameworks pourraient devenir des moteurs
La plupart des frameworks sont le résultat d’un travail de qualité, compte-tenu des nombreux spécialistes qui ont participé à leur élaboration. Par conséquent, ne pas utiliser ces outils serait un gaspillage. Cependant je pense qu’attendre des développeurs utilisateurs d’outils de maîtriser autant de concepts afin de faire fonctionner ces frameworks est sous-optimisé.
Lorsque vous vous documentez sur un nouveau framework, vous tombez rapidement sur la section “Pourquoi ce framework ?”. La plupart de ces outils mettent l’accent sur leur faible poids, leur réactivité, etc. Si ces caractéristiques sont certainement pertinentes pour les moteurs d’applications, les frameworks manquent cruellement, en revanche, de facilité d’utilisation (même si certains prétendent être simples). Ils sont trop bas niveau, ce qui, à mon avis, n’en fait pas de bons candidats comme outils de description d’applications.
Comme nous devrions séparer les outils de description des applications, et les moteurs, nous pouvons imaginer que le même code source de description des applications permettrait de générer des applications de divers types (ou frameworks).
Par exemple, il permettrait de générer des applications en React, Angular, ou Vue. Ou bien encore des applications en Laravel ou Ruby. Tous les frameworks deviendraient des moteurs interchangeables car leur code serait généré en fonction du choix du développeur utilisateur d’outils.
Ce concept est proche des apps hybrides. Par exemple, PhoneGap ou Ionic sont capables, avec presque le même code de base, de générer des applications Android ou iOs.
Pour conclure
Les lois de l’évolution TRIZ expliquent que tout système tend vers un idéal, ce qui signifie moins de coûts. La cinquième loi d’évolution indique également que les systèmes augmentent d’abord en complexité avant de se simplifier.
Le développement d’applications a déjà augmenté en complexité. Il est maintenant temps de le simplifier. Ce que je propose dans cet article est une réponse à ce besoin de simplicité.
Si les rôles des développeurs sont redéfinis, si les applications sont séparées de leurs moteurs, et si nous utilisons un langage très haut-niveau pour décrire les applications, nous obtiendrons une plus grande efficacité.
Et pour chaque nouvelle mise à jour d’un outil ou d’un framework, il n’y aurait plus de coûts d’apprentissage. Juste un pop-up dans l’outil de développement.
, inventeur de TRIZ](https://tech-me-up.com/wp-content/uploads/2020/11/post-2356-5faf8e431ddcd.)
, par Karen Gaad](https://tech-me-up.com/wp-content/uploads/2020/11/post-2356-5faf8e434d06b.png)
](https://tech-me-up.com/wp-content/uploads/2020/11/post-2278-5fa6d1f443725.)
utilise Cordova pour générer des apps Android, iOs, etc. en utilisant HTML/CSS/JS](https://tech-me-up.com/wp-content/uploads/2020/11/post-2278-5fa6d1f4982cd.png)