Aujourd’hui, un ami m’a demandé conseil pour son projet. Il m’a demandé si c’était possible de le faire avec telle technologie. Alors oui, fondamentalement, tu peux tout faire avec tout. Cependant, mon métier c’est avant tout une chose: répondre à des besoins et solutionner des problèmes.
La chose étant que, pour le client (ou n’importe qui ayant l’idée d’un projet), tout est facile. Il y a toujours des choses à penser, des choses qui vont nous prendre du temps mais les choses ne sont guères aussi simples que ça. Depuis plusieurs mois, j’ai l’habitude de dire ceci:
Les bons outils pour les bons besoins.
Ma règle n°1, c’est de réfléchir aux besoins et aux risques qui peuvent apparaître. C’est un sujet pour que les néophytes et les autodidactes ne sont pas forcément habitué·e·s à exécuter, mais c’est un élément important à prendre en compte.
Ma seconde règle, c’est de connaître les forces et les faiblesses des langages que je pratique. Savoir que Node est monothread, que Django permet de créer facilement des interfaces d’administration sans développer (juste de la configuration) ou qu’il faut investir du temps pour mettre en place un design patterns pour architecturer ton projet. Pour des petites choses comme un bot Discord; fais toi zizir.
Malheureusement, on reste souvent dans notre petite zone d’amour alors que d’autres choix existent qui sont potentiellement meilleurs.
Selon les besoins et les risques potentiels, il faut tenter d’utiliser les bons outils. Et même de mélanger les outils, pourquoi pas. Dans mon projet actuel, il y a du Python pour extraire des données de .sql ou .csv afin d’extraire des données parmi d’autres. J’ai aussi eu l’occasion d’utiliser bash dans une CI de Gitlab pour changer des variables d’environnement. Le faire dans le langage utilisé pour le projet n’est pas toujours le meilleur choix; n’ayez pas peur de switcher pour utiliser un langage plus adapté.
Ne pas sortir le tank pour le moustique
Imagine; tu dois coder un petit bot Discord. Exemple ridicule s’il en est, ces cas existent. Il est inutile de sortir l’artillerie lourde comme Laravel, Symfony ou Django pour faire deux ou trois endpoints. Dans ces cas là, tu peux te lancer sur du Python avec Flask ou Lumen.
Un autre cas, ce serait de renvoyer des données simples sans des relations dans tous les sens, ce serait par exemple Node avec Restify. Rapide à mettre en place, performant mais monothread et doit être totalement asynchrone. Conserver la simplicité d’un outil pour le besoin est essentiel tout comme surévaluer les besoins ou une mauvaise réflexion sur la prise de risques.
Chéri ? Sors le Pandur !
Précédemment, j’ai parlé de cet ami qui me demandait des conseils n’avait pas pensé à certaines choses. Il m’a envoyé son cahier des charges et certains problèmes sont révélés directement:
- Gestion de queues;
- Notifications;
- Pas si petit que ça.
Du coup après lecture de ceux-ci, on peut déjà éliminer certains langages ou frameworks. Node peut passer si on gère les queues. Il faudrait investir du temps pour architecturer Flask. Lumen est un peu trop allégé pour ça, comparé à Laravel. Du coup, dans mes connaissances, il reste Django et Laravel. Django n’est pas réellement adapté. À mon humble avis, il permet de développer un CMS complet, facilement mais l’investissement en temps pour mettre en place Django REST Framwork n’est pas forcément des plus adaptés.
Donc il reste Laravel ou Node. Il existe également d’autres frameworks qui pourraient faire l’affaire comme Rails ou Symfony.
Au final, ces outils sont tous très bons. Chacun a ses avantages et ses désavantages. Quand on me demande de faire quelque chose d’assez simple, j’ai tendance à sortir Node, Lumen ou Flask, ça dépend des besoins mais aussi des demandes clients. Lorsqu’il y a une demande d’interface admin, j’ai tendance à proposer Django. Quand c’est une application plus complète avec de la gestion de queues, interface d’administration etc: Laravel. D’autant plus quand il faut ajouter de la logique métier au backoffice.
Il y a aussi l’aspect deadline qui est important. Avec quel outil es-tu læ plus performant·e ? C’est également une chose à prendre en compte. Faire du SOLID avec Laravel prend du temps. Du temps que tu n’as peut-être pas.
Au final, on peut choisir les outils utilisés selon ce qu’on aimerait faire, petit exemple qui ne concerne que moi:
- Interface d’administration: Django, Laravel
- Gestion des queues: Laravel
- Stocker et retourner des résultats: Node (avec GraphQL, c’est bien), Flask ou Lumen
- Mini API: Flask, Lumen
- Serverless chez AWS: Python ou Node
Pour ce qui est des autres besoins comme l’envoi de mail, c’est plus générique et sont faciles sur n’importe quel langage ou framework. Quoi qu’il en soit, notre travail doit rester avant tout qualitatif — sauf dans certains cas. La qualité ne se mesure pas seulement en fonction de la beauté de ton code ou de la maintenabilité du logiciel, il y a également l’aspect overkill de l’outil.
Pour conclure, l’important c’est de se faire plaisir. Une autre chose importante c’est capturer les besoins et les exigences, qu’est ce que la personne en face de toi souhaite ? Est-ce que la plateforme doit être maintenue dans le temps ? Tous ces éléments sont à prendre en compte sur le choix de la technologie de départ.