L'agence nationale de la sécurité des SI sort enfin du bois ! Ses recommandations en matière de GenAI étaient attendues. Pas de surprise, mais un ensemble pertinent, à garder en tête.
Voici mes convictions pour la conception de logiciels afin d'éviter toute complexité inutile et de construire des systèmes plus simples, plus faciles à maintenir et plus évolutifs.
J'aimerais partager avec vous mon approche des principes de conception de l'architecture logicielle. Au début de tout projet logiciel, nous tombons souvent dans le piège de concevoir des systèmes plus complexes que nécessaire. Ma conviction est qu'il faut rester simple, éviter toute complexité inutile et ne créer que les fonctionnalités nécessaires. En suivant ces principes, nous pouvons construire des systèmes plus simples, maintenables et évolutifs, faciles à comprendre et à modifier.
Plongeons dans les détails de ces principes.
Principe DRY
DRY est l'abréviation de "Don't Repeat Yourself" (ne pas se répéter). L'idée derrière ce principe est de maintenir le comportement d'une fonctionnalité du système dans un seul morceau de code ou de système. Il est plus facile de maintenir un code ou un système qui existe à un seul endroit, car nous n'avons besoin de le modifier qu'à un seul endroit. D'un autre côté, la duplication du code crée une complexité inutile et rend le code plus volumineux, ce qui entraîne davantage de bogues dans le système.
Principe KISS
KISS est l'abréviation de "Keep It Simple, Stupid" (rester simple, stupide). Ce principe souligne l'importance de rendre votre code ou votre système simple, en évitant toute complexité inutile. Un code simple est plus facile à maintenir et à comprendre. Vous pouvez appliquer ce principe à la conception et à la mise en œuvre de votre code en supprimant les fonctionnalités inutiles et le code dupliqué. Vous devez également utiliser des noms pour les API et les méthodes qui ont un sens et qui correspondent à leurs responsabilités.
Principe YAGNI
YAGNI est l'abréviation de "You Ain't Gonna Need It" (vous n'en aurez pas besoin). Ce principe souligne l'importance de ne pas créer des fonctionnalités qui ne sont pas nécessaires. Parfois, nous essayons de penser à l'avenir, au futur du projet, en ajoutant des fonctionnalités supplémentaires "juste au cas où nous en aurions besoin". Cependant, la plupart du temps, nous n'en avons pas besoin et elles ajoutent une complexité inutile au système. En suivant ce principe, nous pouvons gagner du temps et faire avancer les projets efficacement.
Garder l'esprit ouvert
En suivant ces principes, vous pouvez construire un système propre, plus simple et facile à maintenir. Cependant, il existe toujours de nouvelles approches de l'architecture logicielle qui peuvent améliorer notre travail. Par exemple, Kelsey Hightower recommande l'architecture monolithique modulaire et la construction de composants sans serveur et entièrement gérés pour la plupart des projets logiciels. Bien que je sois d'accord avec l'idée de Kelsey pour la plupart des cas, les microservices sont parfois des choix inévitables pour les applications à grande échelle. Par conséquent, le choix de la meilleure architecture pour chaque projet est crucial.
Si nous concevons une application de commerce électronique avec une architecture monolithique, il y a un seul grand serveur d'application monolithique et une seule grande base de données relationnelle. Cependant, si nous la concevons avec une architecture microservice, nous pouvons utiliser une base de données documentaire NoSQL pour le microservice produit, une base de données NoSQL à paires clé-valeur pour le microservice panier d'achat et une base de données relationnelle pour le microservice commande. En fonction des besoins de stockage de données de chaque microservice, nous pouvons choisir la base de données la plus appropriée.
