Un document de description d'architecture constitue-t-il une violation du principe DRY?

11

Le principe DRY (Don't Repeat Yourself) stipule que «chaque élément de connaissance doit avoir une représentation unique, non ambiguë et faisant autorité au sein d'un système». La plupart du temps, cela fait référence au code, mais il est souvent étendu à la documentation également.

On dit que chaque système logiciel a une architecture que vous le choisissiez ou non. En d'autres termes, le logiciel que vous créez a une structure et cette structure "telle que construite" est l'architecture du logiciel. Puisqu'un système logiciel intégré est livré avec une architecture, la création d'une description de l'architecture de ce système est-elle une violation du principe DRY? Après tout, si vous avez besoin de connaître l'architecture, vous pouvez toujours simplement regarder le code ...

agile documentation architecture dry Michael
la source
Croyez-vous réellement que vous pouvez discerner l'architecture en regardant le code? Le code vous indiquera toutes les exigences fonctionnelles et non fonctionnelles, les compromis architecturaux, les problèmes de déploiement, le contexte commercial, les scénarios de cas d'utilisation, etc., etc.? Si votre code peut vraiment vous le dire, c'est un enfer d'un système trivial.
luis.espinal
@ luis.espinal, Il est possible de distinguer respectivement les structures statiques et dynamiques du code et du système en cours d'exécution. Que ces structures soient équivalentes à l'architecture d'un système dépendra de votre école de pensée. Comme vous l'avez souligné, il vous manquerait encore quelques gros morceaux, y compris les pilotes architecturaux et la justification des décisions de conception.
Michael
Quelle véritable école de pensée assimile les structures dérivées de code à l'architecture d'un système? Si nous savons que nous manquerons de gros morceaux, y compris les pilotes architecturaux, alors il nous manque l'architecture entière. Cela prouve trivialement que les structures statiques et dynamiques qui peuvent être discernées à partir du code seul ne représentent pas l'ensemble d'une architecture (indépendamment de l'école de pensée.) INCOSE), ils sont clairs dans la mesure où le code n'est qu'une fraction d'une architecture.
luis.espinal
cas d'espèce. L'architecture d'un système peut nécessiter que je déploie sur un nombre spécifique de machines, les interfaces externes étant désactivées et activées dans un ordre spécifique. Les structures statiques et dynamiques dérivées du code seul ne le captureront pas (le cas échéant). Cependant, elles font clairement partie des aspects opérationnels et de déploiement d'une architecture système. Et toute structure dérivée de code ne concernera que les réalisations d'aspects statiques d'une architecture d'application logicielle (ou de composant). Cela ne peut jamais être pour une architecture de systèmes .
luis.espinal
1
@ luis.espinal, je vous invite à soumettre une réponse à cette question! Il semble que vous apportiez une excellente perspective qui, je pense, ajouterait une réelle valeur à ce sujet. Vous prêchez au chœur à ce sujet, alors pourquoi ne pas créer une réponse qui explique pleinement votre pensée afin que tout le monde puisse en bénéficier? C'est pourquoi j'ai posé la question en premier lieu.
Michael

Réponses:

11

La duplication de vos pensées dans le code viole-t-elle le principe DRY?

Décidément, si vous pouviez simplement connaître l'architecture en regardant dans le code, il n'y aurait pas de choses comme des "documents de description d'architecture" en premier lieu. Ce n'est pas une répétition, c'est un autre niveau de description du système , qui ne peut pas être déduit trivialement du code, et vice versa. Il a donc son plein droit d'exister même si vous adoptez DRY.

P Shved
la source
7

Ne prenez pas DRY comme une règle dure et rapide. C'est une bonne chose, mais vous ne pouvez l'approcher qu'en pratique.

Je pense aussi que ce n'est pas bien écrit. "Ne vous répétez pas" ne semble pas couvrir le cas tout aussi important que pour effectuer un changement sémantique ou fonctionnel, vous devrez modifier le texte source à plusieurs endroits, en disant des choses différentes mais coordonnées.

Plutôt que de le considérer comme un commandement à ne pas violer, il vaut mieux comprendre pourquoi c'est une bonne idée et faire des choix judicieux à ce sujet. La raison pour laquelle il est mauvais de devoir effectuer des modifications coordonnées à plusieurs endroits est que vous, l'éditeur, faites des erreurs. Vous n'êtes pas fiable à 100% pour effectuer les modifications sans erreur. Si vous devez apporter 10 modifications différentes au texte source, et que vous n'en obtenez que 9 correctement, vous avez mis un bogue . C'est pourquoi organiser le texte source pour minimiser le nombre de changements coordonnés est une bonne chose. Il minimise les bugs.

Nous n'appartenons pas à une religion dans laquelle DRY est l'un des commandements. C'est juste un moyen pratique, quoique légèrement trompeur, d'encapsuler un peu de bon sens.

Mike Dunlavey
la source
4

Une description d' architecture ou de conception Description du logiciel ne violent DRY. Cependant, dans une grande organisation, où les projets ont eu lieu ces dernières années, les développeurs vont et viennent, et le système est trop volumineux pour qu'une seule personne puisse garder tous les détails dans sa tête, c'est un document essentiel. La quantité de «répétition» nécessaire pour le garder synchronisé en vaut la peine pour l'effort qu'il économise lors de la prochaine mise à jour ou maintenance.

AShelly
la source
1
C'est une incompréhension ou une application aveugle de DRY. Une description architecturale n'en est pas une violation. Si l'on appliquait aveuglément DRY de cette manière, alors tout sauf le code en est une violation ... et clairement ce n'était pas l'intention de ceux qui en ont eu l'idée.
luis.espinal
2

Une description d'architecture ne viole pas le principe DRY.

Votre système logiciel est livré avec une architecture, bien sûr. Et il est réparti sur de nombreux fichiers, dans de nombreuses classes, avec de nombreux détails superflus et inutiles pour une vue d'ensemble.

Votre document d'architecture doit être comme le premier paragraphe d'un reportage: c'est un aperçu, un résumé, une feuille de route du projet.

Frank Shearar
la source
1

Si vous datez le document, il décrit alors l'architecture au moment de la rédaction.

Alors que le code représente l'architecture à l'heure actuelle.

Deux choses distinctes - pas la même connaissance.

Tant que vous déclarez que le document représente l'architecture au moment de la rédaction, vous ne dupliquez pas les connaissances OMI parce que ses connaissances différentes concernent le système à un autre moment.

Personne
la source
Le code ne représente jamais l'architecture. C'est juste une manifestation de l'architecture. Le code qui a été modifié aujourd'hui pourrait toujours représenter l'architecture d'hier. En outre, il peut ne pas représenter l'architecture prévue (ou contractuellement requise), ce qui vous inquiète le plus. Le code ne vous dit pas si c'est bien ou mal, mais seulement qu'il fonctionne. Pour savoir si elle est bonne ou mauvaise, vous devez regarder l' architecture prévue et les exigences qui ont conduit le système pour commencer.
luis.espinal