Côté client, on entend souvent le même discours : les développements avancent au ralenti, on a l'impression de ne pas maîtriser la technique, d'être freiné par elle. Tout semble compliqué, et ce n'est pas acceptable.
Quand on doit chiffrer une prestation de TMA (Tierce Maintenance Applicative) là-dessus, c'est un cauchemar : comment calculer un coût de maintenance réaliste quand le projet est un véritable oignon, que chaque couche en cache une autre, à n'en plus finir ?
Il nous arrive de plus en plus fréquemment de tomber sur ces situations plus complexes que nécessaire, à tel point qu'on a décidé de se pencher sur le pourquoi.
Trois causes fréquentes de projets enlisés
1. Le code dégueulasse
Imparable. Il faut qu'on se débarrasse de ce cas. Le code dégueulasse, comme un projet de 1500 fichiers mal rangés, avec du code procédural à n'en plus finir, qui n'utilise aucun système de contrôle de version (enfin, on pousse le code sur Github, mais on ne sait pas trop pourquoi) : ça arrive.
Le PHP a adopté la programmation orientée objet en 2004. Des frameworks comme Symfony (né en 2005) ou Laravel (en 2011) aident à appliquer les bonnes pratiques, pour avoir un code facile à maintenir, et qui suit l'état de l'art.
Évidemment, on va toujours tomber, de temps en temps, sur un "gaulois réfractaire" qui refuse de faire comme tout le monde, et qui préfère réinventer la roue. Celui-là va redévelopper un framework ou un CMS (système de gestion de contenu) maison, pensant faire mieux - seul et dans son coin - que les dizaines, voire centaines de milliers de développeurs qui, au fil des ans, ont contribué à des projets open source comme Laravel ou Wordpress.
Dans ces cas-là, le constat est souvent sans appel : il faut réécrire la quasi-totalité du code, et on parle alors d'une refonte technique. Même si on a gagné en expérience, puisqu'on cerne mieux les besoins qu'en partant d'une feuille blanche, il faut tout reprendre. C'est long, c'est pénible, et ça coûte cher.
C'est le cas le plus visible, mais paradoxalement, pas le plus dangereux : au moins, on sait qu'il faut tout jeter. Le vrai poison, c'est quand le code est propre, mais inutilement complexe.
2. L'over-engineering
La sur-ingénierie, c'est la maladie des bons élèves. Pour construire une cabane, on a posé les fondations d'un château-fort.
Ça part d'une bonne volonté : si je découple le front et le back-office, je peux utiliser la "brique" la plus adaptée à chaque besoin. En codant dès aujourd'hui une API entière, je serai prêt si, demain, le client veut une application mobile native. Si le trafic fait x100, on pourra scaler horizontalement.
Tout découpler, c'est souvent "tout prévoir", mais à moins d'avoir une boule de cristal, vous ne me ferez pas croire que vous êtes capables d'imaginer les besoins métier qui émergeront dans 2 ans et qui viendront impacter votre code. En tout cas, ça fait 30 ans que je code, et j'en suis bien incapable.
Par contre, ce qui est sûr, c'est que votre projet est plus compliqué que nécessaire, dès aujourd'hui. On fait exploser les coûts de maintenance, pour une complexité qui n'est pas utilisée.
3. CV-driven-development
Le CV-driven-dev, c'est encore un autre cas, mais qui provoque souvent de l'over-engineering. C'est ce qui se passe quand un développeur choisit d'embarquer "une techno de plus" : parce qu'elle est à la mode et qu'il ne veut pas rater la hype (on nage en plein FOMO - Fear Of Missing Out), ou parce qu'elle fera bien sur son CV.
Sauf que, utiliser tout ce qui sort, en plus d'être impossible, ne te rendra pas plus employable. Je préfèrerais 100x embaucher un profil avec des lacunes dans une des technos qu'on utilise (on te fera monter en compétence) plutôt qu'un dev qui va nous faire installer les 300 librairies à la mode avant de poser sa démission, nous laissant avec un spaghetti de code impossible à maintenir sans chopper des migraines.
Ajouter React + Redux + GraphQL + TypeScript sur un formulaire de contact, c'est du gaspillage pur.
Comment faire mieux : coder simple, dès maintenant
Après avoir vu pourquoi tant de projets s’enlisent, parlons de ce qu’on peut faire pour éviter de sombrer.
Commencez simple
Saint-Exupery disait "La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer". Avant d'ajouter la moindre complexité à un projet, on doit passer le filtre YAGNI (You Ain't Gonna Need It) : si je n'en ai pas besoin, tout de suite, ça n'a rien à faire dans mon code. Ça rejoint le fameux "Less is more".
Notre boulot, en tant que concepteurs d'applications, c'est de trouver le moyen le plus simple de répondre au besoin.
Contrairement au bâtiment, quand on code, on n’est que rarement impacté par la taille des fondations - tant qu’elles sont propres. Profitons-en !
Faites évoluer selon le besoin
Dans 6 mois, le besoin aura évolué, le projet se sera complexifié : parfait, on aura encore du boulot à ce moment. Et il sera peut-être temps de sortir l'artillerie lourde, celle qui répondra aux nouveaux enjeux.
Peut-être qu'on devra compliquer l'infrastructure d'hébergement, en ajoutant des serveurs frontaux, ou en basculant sur une solution cloud. Peut-être que la librairie toute simple qu'on utilise pour les deux pie-charts sur le dashboard atteindra ses limites, et qu'on devra envoyer D3JS partout (c'est une lib ultra-puissante mais qui a une courbe d'apprentissage assez raide). Peut-être qu'il faudra implémenter une couche de cache plus solide pour mieux encaisser la charge. Peut-être qu'on devra dénormaliser la base de données pour gagner en vitesse d'exécution des requêtes. Peut-être.
Par contre, aujourd'hui, un VPS à 10 € par mois chez Scaleway suffira, et les fonctionnalités de base de ChartJS ravieront le client fan d'histogrammes.
Pour le reste, on verra plus tard, si et seulement si le besoin est réel !
Faites-vous confiance
En général, je comprends la sur-complexification comme une réponse à l'anxiété des développeurs, qui veulent bien faire et anticiper la croissance. Mais faites-vous confiance : vous saurez réagir, quand le temps sera venu.
J'entends des justifications comme "oui, mais si on fait X et s'il se passe Y, on aura le problème Z". Parfait : le goulot d'étranglement est déjà identifié. Il ne reste plus qu'à surveiller Y, et se tenir prêt à déployer la parade.
Livrez petit
N'oublions pas qu'un client ne s'est jamais pavané en expliquant à ses actionnaires qu'il utilisait NuxtJS, ou qu'il était hébergé sur Vercel.
Faites au plus simple. Livrez vite. Livrez petit.
Ce qu'on vous demande, c'est de produire une techno qui fonctionne, et qui se fait oublier. Le vrai talent en développement, c'est de résister à la tentation de sur-ingénierie. Et ça, ça vient avec l'expérience... et les projets ratés.
