Principes SOLIDES vs YAGNI

Quand les principes SOLID deviennent-ils YAGNI?

En tant que programmeurs, nous faisons constamment des compromis entre complexité, maintenabilité, temps de construction, etc. Entre autres, deux des directives les plus intelligentes pour faire des choix sont dans mon esprit les principes SOLID et YAGNI. Si vous n'en avez pas besoin ne le construisez pas, et gardez-le propre.

Maintenant, par exemple, lorsque je regarde la série dimecast sur SOLID , je vois qu’il s’agit d’un programme assez simple et qu’il aboutit à un programme assez complexe (la complexité finale est également à la charge du spectateur), mais cela reste Je me demande: quand les principes SOLID se transforment-ils en quelque chose dont vous n’avez pas besoin? Tous les principes solides sont des méthodes de travail permettant à l’utilisateur d’apporter des modifications à un stade ultérieur. Mais que se passe-t-il si le problème à résoudre est assez simple et qu’il s’agit d’une application jetable, alors quoi? Ou les principes SOLID sont-ils toujours applicables?

Comme demandé dans les commentaires:

• Principes SOLID
• YAGNI

Il est toujours difficile de juger une approche basée sur un screencast, car les problèmes choisis pour les démos sont généralement si minimes que l'application de principes tels que SOLID donne rapidement l'impression que la solution est complètement conçue.

Je dirais que les principes SOLID sont presque toujours utiles. Une fois que vous maîtrisez ces outils, leur utilisation ne semble pas être une chose à laquelle vous devez délibérément réfléchir. Cela devient naturel. J'ai vu beaucoup d'applications uniques jetables devenir plus que cela, alors j'ai maintenant peur de dire que je vais jeter quelque chose, parce que vous ne savez jamais.

L’approche que j’adopte habituellement est que, si j’écris une application simple pour une tâche particulière, je vais parfois renoncer aux grands principes de noms au profit de quelques lignes de code qui fonctionnent. Si je constate que je reviens sur cette application pour y apporter d'autres modifications, je prendrai le temps de la rendre SOLIDE (au moins un peu, car une application à 100% des principes est rarement réalisable).

Dans les grandes applications, je commence petit et au fur et à mesure que le programme évolue, j'applique les principes SOLID autant que possible. De cette façon, je n'essaie pas de tout concevoir du début à la fin. C’est là, à mes yeux, le lieu idéal où YAGNI et SOLID coexistent.

Pensez d'abord au problème à résoudre. Si vous appliquez à l'aveuglette les principes de YAGNI ou de SOLID, vous pouvez vous faire du mal plus tard. J'espère que nous pourrons tous comprendre, à mon avis, qu’il n’existe pas d’approche «unique» en matière de conception qui réponde à tous les problèmes. Vous pouvez en voir la preuve lorsqu'un magasin vend un chapeau annoncé comme étant "une taille unique", mais cela ne vous va pas. C'est trop grand ou trop petit.

Au lieu de cela, il vaut mieux comprendre les principes et les problèmes que SOLID tente de résoudre; ainsi que les principes et les problèmes que YAGNI tente de résoudre. Vous constaterez que l’un s’intéresse à l’architecture de votre application et l’autre au processus de développement dans son ensemble. Il peut y avoir des chevauchements dans certains cas, mais ce sont des problèmes nettement différents.

YAGNI (vous en aurez besoin [pittoresque acronyme américain]) est soucieux de gagner du temps de développeur grâce à l'ajout de fondations en béton armé renforcé d'acier à un pont destiné uniquement à couvrir une crique de 3 pieds de large lorsqu'un simple pont en bois suffira bien. Si nous couvrons une rivière large et avons besoin de supporter plusieurs remorques de semi-remorques, nous aurions besoin de ce travail de fondation supplémentaire. En gros, YAGNI vous dit d’examiner la situation dans son ensemble et de concevoir les besoins actuels . Il s'agit de résoudre le problème de la complexité, car nous anticipons un certain nombre de besoins potentiels que le client n'a pas encore identifiés.

SOLID s'intéresse à la manière dont nous nous assurons que les pièces du pont s'emboîtent bien et peuvent être entretenues au fil du temps. Vous pouvez appliquer les principes SOLID au pont en bois ainsi qu’au pont en béton armé d’acier.

En bref, ces deux concepts ne sont pas nécessairement en conflit. Lorsque vous vous trouvez dans une situation où vous croyez en être un, il est temps de jeter un coup d'œil sur la situation dans son ensemble. Selon votre conclusion, vous pouvez décider de supprimer une partie des principes SOLID ou de décider que vous en avez vraiment besoin.

Les principes SOLID ne sont pas nécessaires lorsqu'il s'agit d'une application jetable; sinon, ils sont toujours nécessaires.

SOLID et YAGNI ne sont pas en contradiction: une bonne conception de classe facilite la maintenance de l'application. YAGNI indique simplement que vous ne devez pas ajouter à votre application la possibilité d'être cette monstruosité configurable qui peut tout faire sous le soleil - à moins qu'elle n'en ait réellement besoin.

C'est la différence entre une classe de voiture qui a des limites bien définies (SOLID) et une classe de voiture qui a la capacité de se soigner elle-même (YAGNI) avant que le client ne le demande.

Rien ne s'applique toujours! Ne laissez pas les astronautes de l'architecture vous faire peur! L'important est d'essayer de comprendre les problèmes que ces principes tentent de résoudre afin que vous puissiez prendre une décision éclairée quant à leur application.

Récemment, j’essayais de comprendre quand je devais utiliser le principe de responsabilité unique ( voici ce que j’ai proposé.)

J'espère que cela t'aides!

Il y a une citation attribuée à Einstein (probablement une variation par rapport à une vraie ):

"Tout devrait être rendu aussi simple que possible, mais pas plus simple."

Et c’est plus ou moins l’approche que j’adopte lorsque je suis confronté au compromis SOLID vs YAGNI: appliquez-les alternativement, car vous ne savez jamais si un programme est un code «jetable» ou non. Donc, ajoutez simplement une couche de saleté qui fonctionne, puis polissez-la pour une interface plus propre ... et répétez jusqu'à ce que vous convergiez vers le bon niveau d'entropie. J'espère.

Il existe de nombreuses façons de concevoir un programme pour un problème donné. SOLID est une tentative pour identifier les propriétés d'un bon design. Une utilisation correcte de SOLID est supposée générer un programme plus facile à raisonner et à modifier.

YAGNI et KISS s'intéressent à la fonctionnalité. Un programme qui résout plusieurs types de problèmes est plus complexe et abstrait. Si vous n'avez pas besoin de cette généralité, vous avez consacré du temps et des efforts à la création d'un code plus difficile à comprendre et à gérer, mais n'apportant aucune valeur ajoutée.

Un programme bien conçu ne se concentre pas uniquement sur les fonctionnalités dont il a besoin. Un programme qui se concentre uniquement sur les fonctionnalités dont il a besoin n’est pas nécessairement bien conçu. Il n'y a pas de compromis, seulement deux axes orthogonaux dans l'espace décisionnel. Un programme idéal est à la fois modulaire et ne comporte que des fonctionnalités essentielles.

Je pense que vous devriez commencer YAGNI et chaque fois que vous en avez besoin, SOLIDify le.

Ce que je veux dire, c'est que SOLID est là, donc lorsque vous ajoutez une nouvelle classe, vous n'avez pas à refactoriser, il vous suffit de basculer une implémentation (par exemple), eh bien, écrivez votre code simplement, et lorsque vous voyez que vous changez trucs - changez-le avec SOLID (c’est-à-dire que la redistribution redoutée du SOLID est censée vous sauver de la situation - ce n’est pas si grave lorsque vous débutez seulement).

Vous ne perdez pas de temps, car vous auriez quand même du travail à faire (au début) et partout où vous en aurez besoin, votre code sera beau et ordonné.

Je suppose que vous pourriez appeler cela une évaluation paresseuse de SOLID.