Existem alguns princípios básicos de arquitetura de software que todo desenvolvedor deveria seguir. “Mudança” é uma palavra que pode causar pequenas ou grandes dores de cabeça para toda a equipe envolvida no projeto, a dimensão depende de fatores importantes, como a fase do ciclo de vida da aplicação em que a mudança foi identificada, além de depender diretamente da forma como o software foi projetado, da arquitetura. Certamente uma mudança em um requisito terá um impacto bem menor se este for detectado ainda na fase de análise. Uma modificação em uma especificação, depois de o software já ter passado por deploy, pode causar sérias complicações. Mas mudanças são inevitáveis, não importa o nível de refinamento da análise dos requisitos. Nesse caso, como deixar um software pronto para que, quando uma mudança for necessária, o impacto seja o menor possível? Modularização é um aspecto-chave. O uso de Padrões de Projeto – Design Patterns – também ajuda muito a deixar seu código pronto para as eventuais modificações. O ideal é que se construa preparando para mudança em vez de desenvolver para manter como foi feito. Faça modelagem para analisar e reduzir riscos. Saiba fazer a separação de responsabilidades. Tome muito cuidado em manter o baixo acoplamento entre as classes, cada parte deve fazer o mínimo possível. Mantenha o princípio da responsabilidade por um único aspecto. Cada componente deve ser responsável unicamente por uma funcionalidade ou característica específica. Siga o princípio do mínimo conhecimento. Um componente ou objeto não deve saber nada sobre os detalhes internos de outros componentes ou objetos. Não se repita. Não duplique código ou funcionalidades. Minimize o design, só faça o essencial. Conheça o que são os princípios SOLID, um conjunto de regras que devem ser seguidas para se obter um software de qualidade: princípio da responsabilidade única, o design de classes abertas para extensão e fechadas para modificação, inversão de dependência, programação para interfaces e dependência somente de classes abstratas, são dicas preciosas que você deve ter em mãos quando modelar seu sistema orientado a objetos. Eu diria que em quase todos os casos, dominar o uso de interfaces da POO com C# não é ideal, é obrigatório. A própria equipe de desenvolvimento do Visual Studio entende a importância de uma boa arquitetura de software, tanto que a partir do VS2010, temos um menu chamado Architecture, que contém ferramentas fantásticas como o Layer Diagram, que pode inclusive validar a arquitetura de módulos do projeto, além de Dependency Graph, que gera gráficos e matrizes para identificar frameworks mal projetados, por exemplo, com alto grau de acoplamento entre classes. Aqui na .NET Magazine estamos frequentemente abordando estes temas, pois consideramos de extrema importância que nossos leitores não só construam suas aplicações usando as melhores tecnologias, mas que isso sempre seja feito da forma correta, usando boas práticas.
Boa leitura!
Lista completa de artigos da edição:
Serviço de localização do Bing Maps no Windows Phone
Sidnei Santiago
Programação paralela do .NET Framework 4.0
Acelere a manipulação de coleções
Anderson Santos Gusmão
Diagnósticos de serviços WCF
Explore as formas de monitoramento de seus serviços
Israel Aece
Trabalhando com Styles, Resources e Settings no WPF
Customize a interface de seus aplicativos
Alexandre Tadashi
Arquitetura de projetos
Separe seu projeto em camadas
Vladimir Rech
ASP.NET MVC 3 – Parte 3
Conhecendo as novidades da nova versão do framework MVC para .NET
Vinicius Quaiato
Desnormalização de Banco de Dados
Preparando um banco de dados para Business Intelligence
Igor Alcântara
SQL Server 2008: Policy Based Management
Crie políticas de administração, facilitando seu gerenciamento
Danielle da Silva Monteiro
