Y a-t-il des odeurs d'architecture?

Il existe des tonnes de ressources sur le Web qui font référence aux odeurs de code. Cependant, je n'ai jamais vu d'informations sur les odeurs architecturales . Est-ce défini quelque part et y a-t-il une liste disponible? Des recherches officielles ont-elles été menées sur les défauts d'architecture et leur impact sur la vitesse du projet, les défauts, etc.?

Edit: Je ne cherchais pas vraiment une liste dans les réponses, mais une documentation (sur le Web ou dans un livre) sur l’architecture sent.

• Architecture à plusieurs niveaux Lorsque vous avez des calques sur des calques, vous voyez ce que je veux dire ici, dans votre application. Je l'appelle l' architecture par couches
• Sur l'abstraction de telle manière que vous vous perdez dans le code.
• Architecture futuriste Cela se produit lorsque la solution est trop futuriste. En réalité, personne ne peut prédire de nouvelles exigences. Par conséquent, la majeure partie de la mise en œuvre futuriste n’est qu’une perte de temps et de ressources.
• Technologie Architecture enthousiaste L'architecte a aimé la nouvelle technologie et l'a mis en production. Sans savoir si c'était prouvé avant.
• Over Kill Architecture Un problème simple a été résolu par un facteur exponentiel de compétences en architecture et en technologie.
• Architecture en nuage J'appelle architecture en nuage car l'architecture n'a aucun lien avec le réel. Ce ne sont que quelques beaux diagrammes Visio.

L'absence totale du contraire est également vraie.

Voici le lien des dix principales erreurs d’architecture logicielle .

Tout est configurable . Lorsqu'un architecte vous dit que son système est protégé contre les modifications ou hautement personnalisable en raison d'une configurabilité étendue, c'est une odeur d'architecture.

Le problème est que vous ne pouvez réellement fournir que des mécanismes de configuration pour ce que vous pensez devoir être configuré en ce moment, mais une fois que votre application est dans la nature, elle ne sera plus suffisante. Ensuite, les mécanismes de configuration se développent et se développent et vous obtenez finalement l’effet de plate-forme interne.

Et puis vous êtes dans l'enfer du logiciel.

Une base de données conçue par un ORM! Ou une base de données non relationnelle qui devrait être relationnelle. Ou une base de données conçue pour utiliser des vues appelant des vues appelant des vues, non seulement elles sont trop lentes (les bases de données ne doivent pas être conçues pour être performantes dès le début), mais lorsqu'une modification est nécessaire, elles sont horribles à suivre. (Surabstraction, comme @AmirResaei l'a dit, il est facile de se perdre dans le code lorsque vous devez réparer quelque chose qui se trouve au bas de toutes ces couches.)

Les odeurs de code et les odeurs architecturales ne font qu'un. Le code commence à "sentir" à cause d'une architecture non optimale.

Dans son livre phare sur le sujet, Refactoring , Martin Fowler présente une série de codes Smells et identifie un moyen de les refactoriser hors de votre système. Le Refactoring to Patterns de Joshua Kerievsky renforce encore cette idée en donnant des motifs architecturaux spécifiques pour corriger diverses odeurs de code (et comment les reformuler étape par étape).

La plupart des refactorisations sont effectuées pour alléger le code sous-optimal via une architecture améliorée. On pourrait argumenter que la seule "odeur architecturale" née naturellement (autre que Big Ball of Mud) serait l'architecture BDUF (Big Design Up Front). Où vous essayez de gérer tout ce dont vous avez besoin avant que la première ligne de code ne soit écrite. Un projet logiciel agile où la conception est faite en fonction des besoins (même si je considère que le code est traité comme une conception ), son architecture se développera de manière organique.

(Beaucoup de) Coupler - sous quelque forme que ce soit - est ce qui fait sentir les architectures. Plus c'est couplé, plus ça sent.

Cela dit: pas de couplage du tout sent souvent des problèmes de performances.

Voici une odeur concrète d'architecture / conception que je rencontre tout le temps: l'analyse et la création de rapports directement à partir d'une base de données transactionnelle.

Cela convient certainement dans certaines situations (par exemple, des rapports légers), mais dans de nombreux cas, les exigences en matière de rapport et de traitement transactionnel sont en conflit. Cependant, comme il s’agit d’une solution simple et peu coûteuse, les rapports sont directement exécutés à partir de la base de données transactionnelle. Cela provoque toutes sortes de maux de tête des deux côtés de l'équation.

Cela se voit généralement dans les applications Enterprise LOB, entre autres. Je comprends que beaucoup de PME ne disposent pas des ressources ni du savoir-faire pour créer des entrepôts et des datamarts (oubliez les cubes ou les configurations avec réduction de carte), mais de nombreuses grandes organisations avec lesquelles j'ai travaillé ont les mêmes problèmes.

Lors de la conception d'un système, l'architecte doit être conscient du fait que la création de rapports - en particulier les rapports d'analyse - et les exigences transactionnelles sont mieux traitées comme des problèmes distincts et non pas simplement regroupés au niveau de la base de données.

Je ne sais pas si cela correspond légitimement au niveau de l'architecture, mais si je vois un tas de classes / modules de gestionnaires dans ce qui est supposé être une conception orientée objet, alors c'est la garantie que la seule personne qui comprendra l'architecture / la conception est l’architecte / designer lui-même sans beaucoup d’explications / d’apprentissage par les autres.

Il y a beaucoup d'arômes d'architecture documentés par la communauté. Un ensemble courant est le suivant.

• Dépendance cyclique: cette odeur se produit lorsque deux composants d'architecture ou plus dépendent l'un de l'autre directement ou indirectement.
• Dépendance instable: cette odeur survient lorsqu'un composant dépend d'autres composants moins stables que lui-même.
• Composant divin: Cette odeur apparaît lorsqu'un composant est excessivement volumineux, que ce soit en termes de LOC ou de nombre de classes.
• Concentration des entités: cette odeur se produit lorsqu'un composant réalise plus d'un problème / élément architectural.
• Fonctionnalité dispersée: cette odeur se produit lorsque plusieurs composants sont responsables de la réalisation du même problème de haut niveau.
• Structure dense: Cette odeur survient lorsque les composants ont des dépendances excessives et denses sans structure particulière.

J'ai récemment préparé une taxonomie des odeurs . Actuellement, il documente 38 odeurs d'architecture et plus de 260 odeurs de code au total.