Article sérialisé DDD
Je pense qu'il y a chaque jour diverses discussions sur le bon et le mauvais du design, mais y a-t-il une définition claire de «bon design» et «mauvais design»? Bien que cela soit vague ou fragmentaire dans l'esprit de chacun, il semble qu'il n'y ait pas beaucoup de définitions du bien ou du mal dans l'équipe.
Je pense que cela vaut la peine de discuter dans chaque projet, mais je pense qu'il est plus facile de discuter s'il y a une norme. Jetons donc un œil à l'une des définitions du «mauvais design» proposée par Robert Cecil Martin, alias Oncle Bob, qui prônait le principe de l'orientation objet.
Avant cela, j'aimerais vous présenter Oncle Bob.
Robert Cecil Martin(wikipedia)
L'auteur du fameux "code propre" est facile à comprendre. D'autres incluent des partisans du principe SOLID, qui est un principe de conception orientée objet, et co-auteur de la Déclaration de développement logiciel agile. , L'impact sur l'industrie du logiciel est incommensurable.
(En passant, je l'ai présenté dans Quelle est l'architecture la plus simple à mettre en œuvre avec une conception axée sur le domaine C'est aussi le promoteur de l'architecture applicative "Clean Architecture". Le site qui est exploité s'appelle aussi Clean Coder, et nous sommes particulièrement attentifs au nom clean. Il semble que oui. Il semble que c'était d'ici quand je me suis demandé d'où venait le "propre" de l'architecture propre.)
Le texte original référencé cette fois est plus loin dans la page de The Principles of OOD de Old UncleBob Site , Article sur le principe d'inversion de dépendance. Ceci est une citation et un résumé du contenu.
Une conception qui a les trois propriétés suivantes sur lesquelles tous les ingénieurs peuvent s'entendre est appelée une «mauvaise conception».
- Rigidity :
It is hard to change because every change affects too many other parts of the system.
Traduisez-le en japonais, puis rédigez une traduction partielle et un résumé des détails décrits par la suite.
Il est difficile de changer parce que chaque changement affecte de nombreuses autres parties du système.
La cause est que vous devez apporter une chaîne de modifications aux modules dépendants pour un changement.
Si le concepteur ne peut pas prédire dans quelle mesure des modifications doivent être apportées, l'impact et le coût seront imprévisibles. Les autorités n'aiment alors pas approuver les changements, ce qui leur impose une pression rigide.
Contre-mesures Vous avez peut-être dit «réduire le nombre de modules dépendants» et «rendre les modules dépendants logiquement inférables».
Une propriété contrastante est la flexibilité.
Faire des modifications interrompt des parties inattendues du système.
Souvent, les changements peuvent créer de nouveaux problèmes dans des domaines qui ne sont pas conceptuellement pertinents. Cela rend l'équipe de maintenance moins fiable. Plus vous continuez de développement, plus les problèmes se produiront dans des endroits qui ne semblent pas pertinents, et chaque fois que vous apportez une correction, un autre problème se produira ... et le travail requis pour la maintenance continuera d'augmenter.
Vous pouvez considérer les contre-mesures comme «le faisant dépendre uniquement des modules qui sont conceptuellement liés» et «faisant des modules dépendants dans la plage qui peut être déduite logiquement» comme dans 1.
Une propriété contrastante est la robustesse.
Fortement couplé à l'application actuelle et difficile à réutiliser dans une autre application.
Si une partie d'une implémentation repose fortement sur quelque chose de spécifique à l'entreprise, la réutilisabilité de cette implémentation est faible. Lorsque les concepteurs étudient la réutilisation des implémentations, ils constatent qu'il y a beaucoup de travail à faire pour séparer et réutiliser les modules, et dans de nombreux cas, ils renoncent à la réutilisation.
La contre-mesure "augmente-t-elle le degré de cohésion du module"?
Une propriété contrastante est la réutilisabilité.
Qu'est-ce que tu penses. Il peut être plus facile d'imaginer en pensant «à l'envers de la définition du mauvais design» plutôt que de la «définition du bon design».
Il peut également être utilisé comme base pour reconsidérer vos propres idées et politiques d'équipe sur cette base.
Recommended Posts