À peu près à chaque six mois, il me prend de naviguer les intertubes pour prendre des nouvelles de mon vieil ennemi, Visual Basic. Ce que j'aime avec ce langage, c'est la communauté qui y reste attachée et fidèle. Sur tous les sites qui traitent de la mort de VB6, on retrouve inévitablement une tonne de ce genre de commentaires.

Mon nom est <insérer nom ici>. J'ai commencé à programmer en <insérer une année entre 1990 et 2000 ici> en <insérer vieille version de VB ici>. J'ai bâti ma carrière à faire des applications en VB et j'aimerais juste que Microsoft revienne sur sa décision et se décide à créer un VB7.

J'ai peut-être l'air de me moquer un peu, mais je trouve ce genre de comportement dommage et même dangereux. C'est dommage parce que ça démontre la capacité limitée de certains de se mettre à jour avec des technologies récentes et excitantes.

Les limites des outils RAD

Vous l'aurez deviné, je n'aime pas beaucoup les outils de type Rapid Application Development (RAD). Je trouve que ce genre d'outil ne fait qu'acheter des problèmes pour le futur. Ils font généralement effectivement ce pour quoi ils sont vendus: le développement est très rapide. Cependant, les contre-coûts à payer sont nombreux et incluent:

  • Les coins sont souvent coupés ronds. Au revoir performance et maintenabilité du code.
  • Les fonctionnalités sont limitées.
  • Les abstractions sont souvent grossières et trop simplistes.

En toute connaissance de cause, ces contres-coûts valent-ils la peine? Je sais d'expérience que les besoins changent constamment. Je sais aussi que les clients veulent toujours plus de fonctionnalités, de plus en plus avancées et de plus en plus complexe, et c'est normal. C'est notre travail, en tant que développeur de réaliser cette vision (lorsque réaliste). Alors pourquoi se mettre des bâtons dans les roues en utilisant des outils qui nous ralentiront au point de nous mettre au point d'arrêt dans le futur?

Se battre contre le système

Les outils RAD offrent souvent des cadres logiciels assez stricts dont il est difficile de déroger. Si ces outils sont bons pour les cas simples, ils le sont moins quand vient le temps de créer de la vraie valeur. Le meilleur exemple que j'ai à donner est ASP.NET WebForms. L'idée derrière WebForms est d'abstraire les concepts Web autant que possible et d'offrir des vues stateful afin que le développeur qui ne fait pas de web puisse s'y retrouver. Pour y arriver, WebForms offre un ViewState et des contrôles pré-faits qui donnent à leur tour du HTML selon le contexte. Lorsqu'un utilisateur effectue une opération, un form post s'effectue (ce qui s'appelle un postback), et le serveur reçoit un formulaire qui contient l'état de la page tel que vu par l'utilisateur au moment du POST. Il lui suffit alors de consommer les données dans les champs et d'effectuer les modifications nécessaires à la page.

Si vous trouvez que cette solution semble bien, c'est que vous n'avez de toute évidence pas essayer. J'ai passé le clair de mon expérience avec ce framework (un peu plus de 2 ans) à me battre contre lui afin de lui faire cracher le bon HTML, ou à avoir le flow d'évenement auquel je m'attendais (Ah, que vous ne me manquez pas, postbacks). C'est un bon cas pour démontrer que ces outils deviennent vite un encombrement lors des cas plus complexes. Pourquoi alors s'obstiner à utiliser des outils qui fonctionnent bien dans des cas "Hello world", mais qui échouent à répondre à des besoins plus complexes? Qui, dans ce monde, est intéressé à des applications à consommer ou à mettre en production des applications Hello world?

Aujourd'hui, alors que je travaille avec des outils comme ASP.NET MVC Core et React, je me rappelle combien de temps j'ai perdu avec un framework RAD qui devait en théorie me permettre d'aller plus vite. En réalité, il me ralentissait terriblement et m'empêchait de produire de la véritable valeur.

Évoluer des années 90

Le contexte de développement a beaucoup changé depuis les années 90. Dans ce temps ancien (en terme informatique), le développement se faisait beaucoup en mode application native. On créait des applications plus ou moins grosses qui répondaient à des besoins directs des utilisateurs. Ces applications interagissaient peu entre elles et effectuaient des opérations surtout en mode hors ligne. Aujourd'hui, on développe pour toute sorte d'applications. Des applications web, des apps mobiles, des services Web et j'en passe. Ces nouveaux types d'applications sont souvent mal gérés par les RAD, parce qu'elles nécessitent des approches et des techniques plus sophistiquées. On fait encore des applications natives, certes, mais ces applications sont souvent amenées à se connecter à des services internet et à s'intégrer dans des plateformes existantes.

Les nouvelles applications doivent donc gérer de plus en plus de concepts plus poussés comme l'asynchronisme, le parallélisme, etc. Or, ces nouveaux besoins sont mal gérés par les outils RAD pour une multitude de raisons, la première étant que ces défis ne sont pas simples. Donner le contrôle aux développeurs de créer ce qu'ils veulent d'une manière simple, mais tout aussi expressive est un défi colossal auquel les langages, frameworks et librairies modernes tentent de répondre, ne laissant guère de place aux sursimplifications que sont les RAD.

Je comprends que la situation de l'époque ait poussé certains développeurs vers des solutions RAD. Après tout, si un développeur ne faisait pas de Visual Basic à l'époque, que faisait-il pour développer des applications? Il y avait bien des alternatives sous Windows. L'API win32, ou MFC en C++, mais il est vrai que ces solutions étaient difficiles, bien que très puissantes. Aujourd'hui, ce n'est cependant plus le cas. Des environnements de plus haut niveau, mais beaucoup plus flexibles, expressives et puissantes existent, comme .NET, Java, ou Javascript. Pourquoi vouloir un retour en arrière? Qu'y avait-il de si magique à cette époque?

Le plus grand des dangers

Le plus grand des dangers que représentent les outils RAD est cependant le suivant: À force de sursimplifier les processus et le développement, on fait en sorte que les gens ne comprennent pas les implications de ce qu'ils développent, ils ne comprennent pas ce qui se fait sous le capot. Pis encore, ça ne les intéresse pas.

Cette attitude est très dangereuse. Certes, on peut créer des applications et de la valeur rapidement avec des RAD, mais dès qu'on tappe un noeud, on ne comprend pas pourquoi plus rien ne fonctionne. Il y a déjà une partie de la communauté des développeurs qui agit
de cette manière. Combien de fois voit-on une question de ce genre sur Stack Overflow?

Au secours, j'ai créer une application en <insérer outil RAD ici> et plus rien ne fonctionne. Je dois livrer <insérer requis réaliste, mais pas nécessairement trivial ici>. Pouvez-vous me donner la solution pour l'implémenter?

J'ai souvent vu ce genre de questions où l'auteur de la question exige une réponse clef-en-main. Je suis conscient que certaines personnes n'ont pas l'expérience et aimeraient apprendre, et je suis ouvert à leur donner de l'information pour qu'elles apprennent, mais je ne suis pas moi-même une solution RAD. Il faut briser cette conception que tout est facile et à porter de main, car c'est une utopie.

Il existe bien des solutions pour faciliter les tâches (des librairies, des frameworks), mais aucune n'est vraiment bonne à remplir les besoins exacts que doivent remplir une application moderne ou à remplacer les développeurs. Notre travail consiste à décortiquer les problèmes qui nous sont présentés, découper en morceaux et en étapes ces problèmes et implémenter les solutions que nous avons retenues. À mieux comprendre ce que nos choix impliquent, nous sommes amenés à parfaire nos méthodes et nous apportons de meilleures solutions. Être développeur, c'est embrasser le changement, douter de nos conclusions et chercher à s'améliorer. Or, plusieurs internautes qui demandent un VB7 clament que les outils modernes sont trop difficiles à apprendre et qu'ils ne sont pas intéressés à apprendre les concepts de threads, d'asynchronisme et les design patterns. Pourquoi alors s'encombrer à être développeur?

Voilà pourquoi il est important de comprendre ce qui se passe sous le capot. À force d'aller trop vite, nous manquons ces opportunités de devenir de meilleurs développeurs et de s'améliorer. À force d'utiliser des outils RAD, nous nous entêtons à utiliser ces outils, car c'est ce que nous connaissons (Quand tout ce qu'on a, c'est un marteau, tout ressemble à des clous). À force d'utiliser des outils RAD, nous n'évoluons pas avec la technologie afin de comprendre et d'adresser les besoins de plus en plus complexes des clients. À force d'utiliser des outils RAD, nous devenons des automates qui ne servent qu'à coller des morceaux ensemble. À force de faire tout cela, nous perdons notre expertise, et c'est ça le plus grand danger d'utiliser des RAD. Voilà pourquoi je m'oppose à un retour de Visual Basic pour une version 7.

Un peu de lecture

Voici quelques ressources, articles de blog ou pétitions que j'ai lu et qui m'ont donné l'envie d'écrire cet article. À lire les commentaires, on peut prendre le pouls de la communauté Classic VB. Dommage que les commentaires des articles de David Platt (les articles débutant par Don't Get Me Started) aient été retirés, cependant.