Dicas e Truques para aumentar sua produtividade no Visual Studio
Arquitetura evolutiva e design emergente
1. 2011 Praticando a Arquitetura Evolucionária Leandro Daniel @leandronet
2. Leandro Daniel @leandronet Comunidade .net Magazine Autor de artigos Consultoria Desenvolvimento de software Editor Técnico .NET Easy.net Magazine ClubeDelphi SQL Server Business Intelligence Arquitetura de Software Várias certificações...
17. Espectro do Design Waterfall clássico Some DUF Agile XGH Design Emergente BDUF #qconsp @leandronet
18. Arquitetura Evolucionária e Design Emergente #Simples #Adaptativa #Foco do cliente #Agile #YAGNI #Iterativa #Flexível #qconsp @leandronet
19. Design Emergente "Não existe nenhum design no início. Você começa codificando uma pequena quantidade de funcionalidades, e vai acrescentando outras gradativamente, deixando que o design tome forma!” Martin Fowler @leandronet #qconsp
20. Sim, a entropia existe em software... Manter as coisas como estão, exige trabalho! #qconsp @leandronet
21.
22. Quanto mais tempo você adiar suas decisões... ...Mais contextualizadas elas serão! @leandronet #qconsp
26. Quadrante da dívida técnica “Nós não temos tempo para design” “Nós vamos lidar com as consequências” Prudente e De propósito Irresponsável e De propósito “O que são camadas?” “Agora nós sabemos que deveríamos ter feito isso” Prudente e Sem querer Irresponsável e Sem querer #qconsp @leandronet
42. É necessário tomar essa decisão agora? Posso adiar essa decisão com segurança? O que posso fazer para tornar essa decisão reversível? @leandronet
43. Toda e qualquer atividade dentro do desenvolvimento de software é importante. Pense sempre em flexibilidade. Não lute contra as “mudanças”. @leandronet
44. Tenha ciência do seu conhecimento (e da sua ignorância, se possível...) “A simplicidade consiste em subtrair o óbvio e acrescentar o significativo.” (John Maeda) Quando em dúvida, erre pela simplicidade. @leandronet
LOC: Lines of CodeLOCM: Lack of cohesion of methods (falta de coesão entre métodos)NOC: Number of ChildrenILCC: IL cyclomatic complexityABC: Association between methods
O Princípio da responsabilidade única (SRP) está ficando popular entre a Comunidade de arquitetos de software hoje em dia. O princípio afirma que: uma classe não deve ter mais de uma razão para mudar. Outra maneira de interpretar o SRP é que uma classe não deve usar também muitos diferentes tipos de outras classes. Se nós estendemos a ideia a outro nível (módulos (assemblies, namespaces e métodos), certamente, se um elemento de código está usando dezenas de outros elementos de código diferente (no mesmo nível), significa que ele tem muitas responsabilidades. Muitas vezes o termo classe Deusou componente Deusé usado para qualificar esse pedaço de código. DSM pode ajudar a identificar elementos de código com muitas responsabilidades. Esse elemento de código é representado por colunas com muitas células azuis e linhas com muitas células verdes.
Um padrão que é óbvio por um DSM é a estrutura de camadas (ou seja, acíclicos estruturais). Quando a matriz é triangular, com todas as células azuis no triângulo inferior esquerdo e todas as células verdes o triângulo superior direito e, em seguida, ele mostra que a estrutura é perfeitamente em camadas. Em outras palavras, a estrutura não contém qualquer ciclo de dependência.
Ciclo de dependência: Se uma estrutura contém um ciclo, o ciclo será exibido por um quadrado vermelho sobre o DSM. Podemos ver que dentro do quadrado vermelho, verdes e azuis de células são misturadas em diagonal. Existem também algumas células pretas que representam mútuo uso direto (ou seja a está usando b e b é utilizando A).
Alta coesão e baixoacoplamentoAideia de alta-coesão (dentro de um componente) / baixo acoplamento (entre componentes) é popular nos dias de hoje. Mas se alguém não é possível medir e visualizar as dependências, é difícil de obter uma avaliação concreta de coesão e acoplamento. DSM é bom em apresentando alta coesão. No DSM abaixo, um agregado ao quadrado óbvio em torno a diagonal é exibido. Isso significa que os elementos envolvidos na Praça tem uma alta coesão: eles são fortemente dependentes entre si embora. Além disso, podemos ver que eles ficam em camadas como não há nenhum ciclo. Eles certamente são candidatos a ser agrupados em um artefato de pai (como um namespace ou um assembly). Por outro lado, o fato da maioria das células ao redor da Praça vazia advogar para baixo acoplamento entre elementos do quadrado e outros elementos.
Elemento popular: Um elemento de código popular é usado por muitos outros elementos de código. Elementos de código populares são inevitáveis (pense na classe String, por exemplo) mas um código popular não é uma falha. Isso apenas significa que em cada base de código, existem alguns conceitos centrais representados com as classes populares.Um elemento de código popular é representado por colunas com muitas células verdes e linhas com muitas células azuis.