YAGNI SOLIDE contre [fermé]

Question

L'un des plus fréquents arguments que j'entends pour ne pas adhérer aux principes SOLIDES dans object- conception orientée est YAGNI (bien que le débatteur ne remet pas souvent que):

« Il est correct que je mets à la fois fonction X et Y fonction dans la même classe. Il est si simple pourquoi la peine d'ajouter une nouvelle classe (à savoir la complexité). »

« Oui, je peux mettre toute ma logique métier directement dans le code de l'interface graphique, il est beaucoup plus facile et plus rapide. Ce sera toujours la seule interface graphique et il est très peu probable que d'importantes nouvelles exigences jamais entrer. »

« Si dans le cas peu probable de nouvelles exigences mon code est trop je peux encore encombrés factoriser pour la nouvelle exigence. Donc, votre « Que faire si vous avez besoin de plus tard ... » argument ne compte pas. »

Quelles seraient vos arguments plus convaincants de contre cette pratique? Comment puis-je vraiment show que c'est une pratique coûteuse, surtout à quelqu'un qui n'a pas trop d'expérience dans le développement logiciel.

Answer 1

Le design est la gestion et de l'équilibre des compromis YAGNI et solide ne sont pas en conflit. L'ancien dit lorsque pour ajouter des fonctionnalités, ce dernier dit comment, mais ils guident à la fois le processus de conception. Mes réponses ci-dessous à chacun de vos citations spécifiques utilisent des principes à la fois YAGNI et solides.

  

  
1. Il est trois fois plus difficile de construire des composants réutilisables comme usage unique   composants.
  
2. Un composant réutilisable devrait être jugé dans trois différents   applications avant d'être suffisamment général pour accepter dans une réutilisation   bibliothèque.
  

     

- Robert Glass règles de trois , Faits et Sophismes de génie logiciel

refactorisation en composants réutilisables est l'élément clé de la première recherche dans le même but en plusieurs endroits, et puis déplacer. Dans ce contexte, YAGNI applique par inline cette fin en cas de besoin, sans se soucier de la duplication possible, au lieu d'ajouter des fonctionnalités génériques ou réutilisables (classes et fonctions).

La meilleure façon, dans la conception initiale, pour montrer quand YAGNI ne s'applique pas est d'identifier les besoins concrets. En d'autres termes, faire un peu de refactoring avant d'écrire du code pour montrer que la duplication est non seulement possible, mais existe déjà. Cela justifie l'effort supplémentaire

---

  

Oui, je peux mettre toute ma logique métier directement dans le code de l'interface graphique, il est beaucoup plus facile et plus rapide. Ce sera toujours la seule interface graphique et il est très peu probable que signifcatifs nouvelles exigences jamais entrer.

Est-ce vraiment la seule interface utilisateur? Y at-il un mode de traitement par lots d'arrière-plan prévu? Y aura-t jamais une interface web?

Quel est votre plan de test, et vous testerez fonctionnalité back-end sans une interface graphique? Que fera l'interface graphique facile pour vous de tester, puisque vous ne voulez pas l'habitude d'être tester le code extérieur (tels que les contrôles de l'interface graphique plate-forme générique) et à la place se concentrer sur votre projet.

  

Il est OK que je mets à la fois fonction X et Y fonction dans la même classe. Il est si simple pourquoi la peine d'ajouter une nouvelle classe (par exemple la complexité).

Pouvez-vous signaler une erreur commune qui doit être évité? Certaines choses sont assez simples, comme la quadrature du nombre (x * x vs squared(x)) pour un exemple excessivement simple, mais si vous pouvez signaler une personne erreur de béton fait surtout dans votre projet ou ceux de votre équipe vous pouvez montrer comment une classe commune ou la fonction éviteront à l'avenir.

  

Si, dans le cas peu probable de nouvelles exigences, mon code est trop encombré je peux encore factoriser pour la nouvelle exigence. Donc, votre « Que faire si vous avez besoin de plus tard ... » argument ne compte pas.

Le problème ici est l'hypothèse de « improbable ». Avez-vous d'accord, il est peu probable? Si oui, vous êtes d'accord avec cette personne. Dans le cas contraire, votre idée de la conception ne sont pas d'accord avec cette person's-résoudre cet écart va résoudre le problème, ou du moins vous montrer où aller. :)

Answer 2

On dirait que vous plaidez avec un mur de briques. Je suis un grand fan de YAGNI, mais en même temps, je pense aussi que mon code toujours être utilisé dans au moins deux endroits: l'application, et les tests. Voilà pourquoi des choses comme la logique métier dans le code interface utilisateur ne fonctionnent pas; vous ne pouvez pas tester la logique métier distinct de l'interface utilisateur du code dans cette circonstance.

Cependant, à partir des réponses que vous décrivez, il semble que la personne est tout simplement pas intéressé à faire un meilleur travail. À ce moment-là, aucun principe va les aider; ils veulent seulement faire le minimum possible. J'irais jusqu'à dire que ce n'est pas YAGNI conduire leurs actions, mais plutôt la paresse, et vous seul ne vont pas à la paresse de battement (peut presque rien, sauf un gestionnaire menaçant ou la perte d'un emploi).

Answer 3

J'aime penser à YAGNI en termes de « la moitié, pas foireux », pour reprendre l'expression de 37signals ( https://gettingreal.37signals.com/ch05_Half_Not_Half_Assed.php ). Il est de limiter votre portée afin que vous puissiez vous concentrer sur bien faire les choses les plus importantes. Ce n'est pas une excuse pour obtenir bâclée.

logique d'entreprise dans l'interface graphique se sent foireux pour moi. À moins que votre système est trivial, je serais surpris si votre logique métier et l'interface graphique n'ont pas déjà changé de façon indépendante, plusieurs fois. Donc, vous devez suivre la SRP ( « S » dans SOLID) et refactor -. YAGNI ne joue pas, parce que vous devez déjà

L'argument de YAGNI et de la complexité inutile applique absolument si vous faites aujourd'hui un travail supplémentaire pour répondre aux besoins futurs hypothétiques. Lorsque les « si plus tard, nous devons ... » scénarios ne se matérialisent pas, vous êtes coincé avec des coûts d'entretien plus élevés des abstractions qui obtiennent maintenant de la manière des changements que vous avez fait. Dans ce cas, nous parlons de simplifier la conception en limitant la portée -. Faire la moitié, au lieu d'être foireux

Answer 4

Il n'y a pas de réponse, ou plutôt, il y a une réponse ni vous ni votre interlocuteur pourrait comme:. Les deux YAGNI et solides peuvent être mauvaises approches

Tenter d'aller SOLID avec une équipe sans expérience, ou une équipe avec des objectifs de livraison serrés à peu près garantie, vous finirez avec un cher, tas de code sur-ingénierie ... qui ne sera pas SOLIDE, un peu plus-ingénierie (aka bienvenue au monde réel).

Tentative de YAGNI aller pour un projet à long terme et nous espérons que vous pouvez factoriser fonctionne plus tard que dans une certaine mesure (aka bienvenue au monde réel). YAGNI excelle preuve de concepts et manifestants, obtenir le marché / contrat et être en mesure d'investir dans quelque chose de plus solide.

Vous avez besoin des deux, à différents moments.

Answer 5

L'application correcte de ces principes est souvent pas très évidente et dépend beaucoup de l'expérience. Ce qui est difficile à obtenir si vous ne l'avez pas vous-même. Chaque programmeur aurait eu des expériences des conséquences de le faire mal, mais bien sûr, il devrait toujours être « pas mon » projet.

Expliquez-leur quel est le problème, si elles ne l'écoutent pas et vous n'êtes pas en mesure de les faire écouter, laissez-les faire des erreurs. Si vous êtes trop souvent celui d'avoir à résoudre le problème, vous devez polir votre curriculum vitae.

Answer 6

Dans mon expérience, il est toujours un jugement. Oui, vous ne devriez pas vous soucier de tous les petits détails de votre mise en œuvre, et parfois coller une méthode dans une classe existante est un niveau acceptable, bien que la solution laide.

Il est vrai que vous pouvez factoriser plus tard. Le point important est de fait faire le refactoring . Je crois que le vrai problème n'est pas le compromis de conception occasionnelle, mais une fois la mise hors refactorisation il devient clair qu'il ya un problème. En fait, en passant par avec elle est la partie difficile (comme beaucoup de choses dans la vie ...).

En ce qui concerne vos points individuels:

  

Il est OK que je mets à la fois fonction X   et disposent Y dans la même classe. Il   est si simple Pourquoi prendre la peine d'ajouter un nouveau   classe (à savoir la complexité).

Je rappelle que tout avoir dans une classe est plus complexe (parce que la relation entre les méthodes est plus intime et plus difficile à comprendre). Avoir beaucoup de petites classes n'est pas complexe. Si vous vous sentez la liste devient à long, il suffit de les organiser en paquets, et vous serez bien :-). Personnellement, j'ai trouvé que juste diviser une classe en deux ou trois classes peut aider beaucoup avec la lisibilité, sans autre changement.

Ne pas avoir peur des petites classes, ils ne mordent pas; -).

  

Oui, je peux mettre toute ma logique métier   directement dans le code de l'interface graphique, il est beaucoup   plus facile et plus rapide. Ce sera toujours   être la seule interface graphique et il est très   peu probable que signifcant nouveau   exigences ne viendra jamais dans.

Si quelqu'un peut dire « il est très peu probable que signifcatifs nouvelles exigences jamais entrer. » avec un visage impassible, je crois que personne vraiment, vraiment a besoin d'une vérification de la réalité. Soyez franc, mais doux ...

  

Si dans le cas improbable d'une nouvelle   exigences mon code est trop   Je peux encore encombrés factoriser pour la   nouvelle exigence. Donc, votre « Que faire si vous   plus tard besoin de ... » argument ne saurait être   nombre

qui a un certain mérite, mais seulement si elles font réellement refactoring plus tard. Alors l'accepter, et les tenir à leur promesse: -.)

Answer 7

principes semi-rigides permettent un logiciel d'adaptation au changement - dans les deux exigences et les changements techical (nouveaux composants, etc.), deux de vos arguments sont pour les besoins immuables:

• « il est très peu probable que signifcatifs nouvelles exigences jamais entrer. »
• « Si dans le cas peu probable de nouvelles exigences »

Cela pourrait vraiment être vrai?

Il n'y a pas de substitut à l'expérience en ce qui concerne les diverses dépenses de développement. Pour beaucoup de pratiquants que je pense faire les choses dans le mauvais, façon difficile de maintenir n'a jamais donné lieu à des problèmes pour eux (hey! La sécurité d'emploi). À long terme d'un produit, je pense que ces dépenses deviennent claires, mais faire quelque chose à leur sujet à l'avance est quelqu'un d'autre le travail.

Il y a quelques autres grandes réponses ici.

Answer 8

Compréhensible, flexible et capable de corrections et améliorations sont toujours des choses que vous sont va avoir besoin. En effet, YAGNI suppose que vous pouvez revenir et ajouter de nouvelles fonctionnalités quand ils se révèlent nécessaires avec une relative facilité, parce que personne ne va faire quelque chose de fou comme bunging fonctionnalité hors de propos dans une classe (YAGNI dans cette classe!) Ou pousser la logique métier à la logique interface utilisateur .

Il peut y avoir des moments où ce qui semble fou maintenant était raisonnable dans le passé - parfois les lignes de démarcation de l'interface utilisateur vs entreprise ou entre les différents ensembles de responsabilités qui devraient être dans une autre classe ne sont pas que claires, ou même se déplacer. Il peut y avoir des moments où trois heures de travail est absolument nécessaire dans le temps de 2 heures. Il y a des moments où les gens ne font pas le bon choix. Pour ces raisons pauses occasionnelles à cet égard se produira, mais ils vont se faire de la manière d'utiliser le principe YAGNI, ne pas être une cause.

Answer 9

tests unitaires qualité, et je veux dire des tests unitaires non tests d'intégration, le code nécessaire qui adhère à SOLIDES. Pas nécessairement 100%, en fait rarement, mais dans votre exemple bourrer deux fonctions dans une classe fera les tests unitaires plus dur, rompt le principe de responsabilité unique et fait la maintenance du code par les débutants de l'équipe beaucoup plus difficile (car il est beaucoup plus difficile à comprendre) .

Avec les tests unitaires (en supposant une bonne couverture de code), vous serez en mesure de fonction Refactoriser 1 sûr et sécurisé ne cassera pas fonctionnalité 2, mais sans les tests unitaires et les caractéristiques dans la même classe (simplement être paresseux votre exemple) refactoring est au mieux, désastreux au mieux.

Bottom line: suivre le principe KIS (keep it simple), ou pour le principe KISS intellectuel (kis stupide). Prenez chaque cas au mérite, il n'y a pas de réponse globale, mais toujours considérer si d'autres codeurs doivent lire / maintenir le code à l'avenir et au profit des tests unitaires dans chaque scénario.

Answer 10

tldr;

SOLID suppose, vous comprenez (un peu atleast), les futurs changements au code, SRP WRT. Je dirai qui est la capacité d'optimisme au sujet de prédire. YAGNI d'autre part, assume la plupart du temps vous ne connaissez pas la direction future du changement, qui est pessimiste quant à la capacité de prédire.

D'où il suit que SOLIDE / SRP vous demande de former des classes pour le code tel qu'il aura raison unique pour le changement. Par exemple. un petit changement de l'interface graphique ou changement ServiceCall.

YAGNI dit (si vous voulez forcer l'appliquer dans ce scénario), puisque vous ne savez pas ce qui va changer, et si un changement de GUI provoquera un changement GUI + ServiceCall (De même, un changement de back-end causant GUI + SeviceCall changement), il suffit de mettre tout ce code dans une seule classe.

Réponse longue:

Lire le livre 'Agile Software Development, principes, modèles et pratiques'

Je suis en train de court extrait de ce sur Solid / SRP: « Si, [...] l'application ne change pas de manière à l'origine les deux responsabilités aux changements à différents moments, il n'y a pas besoin de les séparer. En effet, en les séparant sentiraient la complexité inutile.

Il y a un corrolaire ici. Un axe de changement est un axe de changement que si les changements se produisent. Il est sage de ne pas appliquer SRP ou tout autre principe, d'ailleurs, s'il n'y a aucun symptôme. "