Principes SOLIDES vs YAGNI

43

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:

KeesDijk
la source
Le titre ne devrait-il pas être aussi SOLID principle vs YAGNI?
Wolf
2
@Wolf: c'est un pluriel "SOLID (responsabilité unique, Open-fermé, substitution de Liskov, ségrégation des interfaces et inversion de dépendance) est un acronyme mnémonique introduit par Michael Feathers pour les" cinq premiers principes "nommés par Robert C. Martin au début Années 2000, cela représente cinq principes de base de la programmation et de la conception orientées objet. "
logc

Réponses:

55

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.

Adam Lear
la source
C'est à peu près ce que je pense aussi. En tant que remarque, je ne juge pas par le screencast, je pense simplement que c’est un bel exemple de la croissance des logiciels lors de l’application de SOLID.
KeesDijk
Bon point. Toute démonstration sera faussée pour démontrer ou aggraver le problème. Essentiellement, c’est l’idée même de prendre une idée à son terme pour prouver qu’elle est une fausse. Une prémisse qui en soi peut être abusée.
Berin Loritsch
YAGNI and SOLID coexistbonne conclusion. Bien que cela puisse être un bon point de départ
Wolf
Il semble que peut-être un pressentiment est parfois nécessaire. Vous devez savoir où vous pourriez commencer à voir de nombreux changements pour savoir où vos niveaux d'abstraction par rapport à la plomberie s'arrêtent et commencent.
johnny
19

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.

Berin Loritsch
la source
Oui, d'accord. Aucune approche miracle ne convient à tous les scénarios.
EL Yusubov
Votre make sure the pieces of the bridge fit togetherest de loin pas aussi évident que can be maintained over time.
Wolf
En gros, SOLID vous permettra de transformer ce pont de bois en un pont en acier de 1 mile de long capable de supporter un peloton blindé sans faire de réécriture complète ou simplement en collant mot après mot.
Sara
@ Kai, c'est une fausse prémisse. Si vous avez besoin d’un pont d’une longueur de 1 mille, vous devez concevoir un pont d’une longueur de 1 mille. Si vous avez besoin d'un pont de 5 pieds, vous construisez un pont de 5 pieds. Ne vous méprenez pas, les principes SOLID sont très utiles, mais il faut mieux les comprendre pour savoir quels principes ne sont pas nécessaires pour résoudre le problème. 9 fois sur 10, ce kilomètre supplémentaire n'est jamais nécessaire.
Berin Loritsch
@BerinLoritsch c'est pourquoi je conviens que si vous avez besoin de 5 pieds, vous construisez 5 pieds, mais vous ne construisez pas 5 pieds en fixant un conduit de 2x4 au sol. vous faites ce dont vous avez besoin et vous le faites bien. (bien que l'analogie soit un peu en train de s'effondrer)
sara le
9

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.

George Stocker
la source
1
N'est-ce pas mélangé? Qu'en est-il de ceci: Appliquez correctement les principes SOLID pour gérer la complexité des voitures à auto-guérison, ou appliquez YAGNI tant que vos voitures sont encore si simples qu'elles ne se briseront jamais (ou - si c'est possible - qu'elles pourraient être simplement jetées) .
Wolf
2
@ Wolf, les principes SOLID ne disent pas CE QUE vous devriez faire, seulement COMMENT. si vous avez déjà décidé que vous souhaitiez des voitures autoréparantes, vous pouvez appliquer les principes SOLID à ce code. SOLID ne dit cependant pas si une voiture à auto-guérison est une bonne idée. YAGNI entre en jeu.
Sara
Souvent, les applications à jeter ne le sont pas.
Tulains Córdova
"Se soigner soi-même", c'est bien. «Avant que le client ne le demande», c’est également une bonne idée car, si vous écoutez Oncle Bob, l’idée même est d’être pour les lieux qui génèrent des bénéfices et qui anticipent les besoins du client et qui ont une entreprise viable qui puisse répondre à ces besoins. parce qu'ils changent. Beaucoup de gens s'énervent contre Oncle Bob parce qu'il ne s'adresse pas à la programmation, mais il vous dit, la plupart du temps, pourquoi il est important d'utiliser SOLID et pas seulement comment.
johnny
"Les principes SOLID ne sont pas nécessaires lorsqu'il s'agit d'une application jetable" . Je pense que les principes SOLID sont une bonne habitude. Par conséquent, même s’il s’agit d’une application jetable, vous vous entraînez vous-même lorsque vous avez besoin d’écrire une application volumineuse. Il est donc avantageux de suivre les principes SOLID.
icc97
4

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!

Brandon
la source
2

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.

logc
la source
Bon point: you never know if a program is 'throw-away' code- eh bien, je pense que l' idée alternative n'est pas si bonne.
Wolf
@Wolf: oui, j'élargissais l'ordre des étapes que je pense être le mieux (résumé dans le slogan «Tout d'abord, rendons possible, puis rendons-le beau, puis faites-le vite»), mais j'ai alors pensé ... YAGNI :)
logc
1

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.

Doval
la source
0

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.

Binyamin
la source
Hm, je vois que vous voulez que le message soit redondant, je le supprimerais mais il semble que je n’ai pas les privilèges pour le faire (ou que je ne vois pas le bouton). De toute façon, je vais le modifier pour qu'il soit plus clair.
Binyamin