Há cheiro de arquitetura?

37

Existem toneladas de recursos na Web referentes a e listando cheiros de código. No entanto, nunca vi informações sobre aromas arquitetônicos . Isso é definido em algum lugar e existe uma lista disponível? Alguma pesquisa formal foi feita em defeitos de arquitetura e seu impacto na velocidade do projeto, defeitos e afins?

Edit: Eu não estava realmente procurando por uma lista nas respostas, mas a documentação (na web ou em um livro) sobre a arquitetura cheira.

    
por C. Ross 18.02.2011 / 14:56
fonte

8 respostas

33
  • Arquitetura multicamada Quando você tem Layers on Layers em Layers on Layers ... você vê o meu ponto aqui, na sua aplicação. Eu chamo de Mais de arquitetura em camadas
  • Sobre abstração de tal forma que você se perde no código.
  • Arquitetura futurista Isso acontece quando a solução é futurista demais. Na realidade, ninguém pode prever novos requisitos. Portanto, a maior parte da implementação futurista é apenas uma perda de tempo e recursos.
  • Tecnologia entusiasta de arquitetura O arquiteto gostou da nova tecnologia e colocou em produção. Sem saber se foi provado antes.
  • Mais de Matar Arquitetura Um problema simples foi resolvido pelo fator exponencial de habilidades e tecnologia de arquitetura.
  • Arquitetura de nuvem Eu chamo de arquitetura de nuvem, já que a arquitetura não tem conexão com a realidade. São apenas alguns diagramas agradáveis do Visio.

A falta total do oposto também é verdadeira.

Este é o link dos Dez principais erros de arquitetura de software .

    
por 18.02.2011 / 15:09
fonte
20

Tudo é configurável . Quando um arquiteto diz que o sistema dele é à prova de mudança ou altamente personalizável devido à extensibilidade de configuração, isso é um cheiro de arquitetura.

O problema é que você pode realmente fornecer apenas mecanismos de configuração para o que você acha que agora precisa ser configurado, mas uma vez que seu aplicativo esteja em estado bruto, não será suficiente. Em seguida, os mecanismos de configuração se expandem e se expandem e, eventualmente, você obtém o efeito de plataforma interna.

E então você está no inferno do software.

    
por 18.02.2011 / 15:30
fonte
9

Um banco de dados projetado por um ORM! Ou um back-end de banco de dados não relacional que deve ser relacional. Ou um banco de dados onde você projeta usar visões que chamam visões que chamam exibições, não apenas elas são muito lentas (os bancos de dados devem ser projetados para desempenho desde o início, não mais tarde), mas quando você precisa fazer uma alteração, eles são horríveis (Acima da abstração, o @AmirResaei disse que é fácil se perder no código quando você precisa consertar algo que está no fundo de todas essas camadas.)

    
por 18.02.2011 / 15:17
fonte
3

Cheiro de código e cheiros arquitetônicos são um e o mesmo. O código começa a "cheirar" por causa da arquitetura sub-ótima.

No livro de Martin Fowler sobre o tópico, Refatoração , ele apresenta uma série de Code Smells e identifica como refatorá-los fora de seu sistema. A Refatoração para Padrões de Joshua Kerievsky enfatiza ainda mais essa idéia, fornecendo padrões arquiteturais específicos para corrigir vários odores de código (e como refatorá-los passo a passo).

A maior parte da refatoração é feita para aliviar o código abaixo do ideal por meio de arquitetura aprimorada. Poder-se-ia argumentar que o único "Cheiro Arquitetural" nascido naturalmente (diferente de Big Ball of Mud) seria a Arquitetura BDUF (Big Design Up Front). Onde você tenta acomodar tudo o que precisa antes que a primeira linha de código seja gravada. Um projeto de software ágil em que o design é feito conforme necessário (até mesmo eu diria que código é tratado as design ), terá sua arquitetura crescer organicamente.

    
por 18.02.2011 / 15:56
fonte
2

(Muita) Acoplamento - em qualquer formato - é o que faz as arquiteturas cheirarem. Quanto mais acoplado, mais cheira.

Dito isto: nenhum acoplamento em geral causa problemas de desempenho.

    
por 18.02.2011 / 15:16
fonte
2

Aqui está um cheiro concreto de arquitetura / design que eu encontro o tempo todo: análise e relatórios diretamente de um banco de dados transacional.

Isso certamente é aceitável em algumas situações (por exemplo, relatórios leves), mas em muitos casos os requisitos de relatórios e processamento transacional estão em conflito. No entanto, como é uma coisa simples / barata, os relatórios são executados diretamente do banco de dados transacional. Isso causa todos os tipos de dores de cabeça em ambos os lados da equação.

Isso é normalmente visto em aplicativos de LOB da empresa, btw. Entendo que muitas PMEs simplesmente não têm os recursos ou o know-how para criar armazéns e datamarts (esqueça sobre cubos ou configurações de redução de mapa), mas muitas organizações maiores com as quais trabalhei têm os mesmos problemas.

Ao projetar um sistema, o arquiteto realmente deve estar ciente de que os relatórios - especialmente os relatórios de análise - e os requisitos transacionais são mais bem tratados como problemas separados e não apenas agrupados no nível do banco de dados.

    
por 18.02.2011 / 20:01
fonte
0

Não tenho certeza se isso se encaixa corretamente no nível de arquitetura, mas se eu vejo um monte de classes / módulos de gerenciador no que deve ser um projeto OO, então isso é uma garantia de que a única pessoa que entenderá o arquitetura / design é o próprio arquiteto / designer sem muita explicação / aprendizagem por outros.

    
por 18.02.2011 / 17:40
fonte
0

Existem muitos aromas arquitetônicos documentados pela comunidade. Um conjunto comumente encontrado é o seguinte.

  • Dependência Cíclica: Esse cheiro surge quando dois ou mais componentes de arquitetura dependem um do outro direta ou indiretamente.
  • Dependência Instável: Esse cheiro surge quando um componente depende de outros componentes que são menos estáveis do que ele.
  • Componente de Deus: Esse cheiro ocorre quando um componente é excessivamente grande, seja nos termos de LOC ou número de classes.
  • Concentração de recursos: Esse cheiro ocorre quando um componente percebe mais de uma preocupação / recurso de arquitetura.
  • Funcionalidade dispersa: Esse cheiro surge quando vários componentes são responsáveis por perceber a mesma preocupação de alto nível.
  • Estrutura Densa: Este cheiro surge quando os componentes têm dependências excessivas e densas, sem qualquer estrutura particular.

Eu recentemente preparei uma taxonomia de cheiros . Atualmente, ele documenta 38 aromas de arquitetura e mais de 260 cheiros totais de código.

    
por 22.03.2018 / 08:05
fonte