Un facteur de pourrissement de l'architecture est le compromis sur le coût de développement
Categories:
Les caractéristiques d’une architecture pourrie sont : de nombreux traitements spéciaux, traitements de compatibilité, couplage sévère, fardeau accumulé difficile à renverser. Toutes les architectures se dégradent lentement. Une architecture pourrie rend difficile le développement de nouvelles fonctionnalités, la correction des bugs, tout changement affecte l’ensemble, ce qui rend aussi les tests et le QA difficiles à faire. J’ai vu un amateur de développement interdisciplinaire poster que limiter le comportement d’abstraction du modèle lors de l’écriture de code rend le code plus facile à comprendre. Le code que les humains comprennent plus facilement, les LLM le comprennent aussi plus facilement, permettant ainsi un développement rapide et moins d’erreurs. Je pense que les développeurs interdisciplinaires ont probablement de petits volumes de travail, habitués à une logique de ligne d’assemblage, s’il y a une attente d’expansion, la façon de penser ne doit pas se limiter à la ligne d’assemblage, mais adopter l’esprit d’un ouvrier du bâtiment. Prévoir un immeuble de 30 étages, il faut creuser des fondations de 10 mètres, prévoir l’eau et l’électricité, il faut réserver des puits d’eau et d’électricité. C’est une conception à objectif clair, il y a aussi des conceptions à objectif flou, comme réserver une prise là où on mettra un appareil électrique plus tard dans la maison, sans savoir lequel, il suffit de réserver une prise. L’ingénierie logicielle dispose déjà des principes SOLID pour guider la conception. Souvent en apparence, suivre les principes SOLID pour réaliser la même fonctionnalité implique de traverser plus de fichiers et d’écrire plus de code. À court terme, la conception et l’absence de conception semblent presque identiques aux yeux du patron, des testeurs et des utilisateurs ; les avantages de la conception ne se manifestent qu’à long terme. Une bonne architecture facilite l’ajout de fonctionnalités, la modification de fonctionnalités, la correction de bugs, et introduit moins de problèmes. La réflexion nécessaire à la conception est souvent plus importante que de commencer directement à développer des fonctionnalités. La conception exige de considérer la granularité ; coller des panneaux de prises partout comme des carreaux de céramique dans toute la maison est une autre absurdité. Par le passé, en considérant le cycle de développement, je faisais des compromis : quand le temps pressait, je ne concevais même pas, j’ajoutais quelques fonctions et c’est tout, on verrait le futur plus tard. Aujourd’hui avec l’IA, nous pouvons rendre la granularité de conception plus fine, le code généré est plus difficile à lire pour l’humain, mais le projet est plus facile à maintenir. Avec plus d’abstraction, les modèles médiocres ont en effet du mal à gérer, il vaut mieux utiliser le meilleur modèle actuel. Si l’on écrit seulement des scripts, la différence de capacité entre modèles peut ne pas être très marquée. Quant à savoir si l’IA a abaissé le seuil d’entrée des développeurs ? J’en doute, car le parcours d’apprentissage des nouveaux développeurs est désormais très différent de celui d’autrefois, discuter si le seuil est haut ou bas n’a probablement pas de sens, car nous ne savons pas où le seuil a été déplacé.
