Princípios, Padrões e Práticas para um Design Ágil na Java Magazine - Parte 2

quinta-feira, 19 de agosto de 2010

Em Julho, saiu a segunda parte do meu artigo Princípios, Padrões e Práticas para um Design Ágil na revista Java Magazine edição 81,  e dando continuidade no artigo publicado na edição 80.

Para esta segunda parte, vamos abordar as diferenças entre a criação de uma arquitetura seguindo métodos tradicionais, como o Waterfall, e a criação de um Design Ágil a partir de ciclos iterativos de duas a três semanas. Além disso, veremos meios de identificar um software mal planejado através de alguns sintomas conhecidos como Design Smells.
Para tratar estes sintomas, abordaremos alguns princípios de Design OO, que são a base de muitos padrões de projeto e que são o produto de várias décadas de experiência com engenharia de software de não apenas um, mas de vários profissionais consagrados no ramo de tecnologia.
Veremos na prática alguns destes princípios, abordando todo o conceito teórico, expondo através de exemplos, sua utilidade e como eles se relacionam com alguns padrões de projeto, e por fim, veremos a aplicabilidade destes princípios nos cenários apropriados para cada um deles.
Para identificar se nosso sistema está com um bom design, Robert C. Martin, popularmente conhecido como Uncle Bob, apresentou alguns sintomas de design ruim, chamado de Design Smells (algo como Odores do Design). Estes sintomas permeiam a estrutura geral do software, e em seu livro Agile Software Development, Uncle Bob chegou a seguinte classificação:



  • Rigidez
  • Fragilidade
  • Imobilidade
  • Viscosidade (Pode ser 2 tipos: Viscosidade do Software e Viscosidade do ambiente)
  • Complexidade Desnecessária
  • Repetição Desnecessária
  • Opacidade

Uma boa técnica para desenvolver um código expressivo é utilizar uma das principais ideias do Domain Driven Design, a Linguagem Ubíqua (ou Onipresente), proposta por Eric Evans. Esta técnica consiste em aplicar uma linguagem comum entre os desenvolvedores e analistas de negócio, utilizando os conceitos do modelo de domínio como forma primária de comunicação, fazendo com que ela seja aplicada tanto nos discursos entre os técnicos e os stakeholders quanto na documentação do sistema. Como consequência, fazemos com que os mesmos termos utilizados no domínio do negócio sejam expressos também no código, o que torna a comunicação mais transparente entre os times durante as discussões sobre o modelo do domínio.


Os sintomas citados acima, podem ser identificados em qualquer parte do sistema e são causados geralmente pela violação de alguns princípios da Programação Orientada a Objetos. Estes princípios, ainda que antigos, são pouco difundidos, mas essenciais para criar um bom Design em qualquer projeto orientado a objetos.
Os princípios que abordaremos no artigo são:

  •  Princípio Aberto-Fechado (OCP – Open-Closed Principle);
  •  Princípio DRY (Don’t Repeat Yourself);
  •  Princípio da Responsabilidade Única (SRP – The Single Responsibility Principle);
  •  Princípio da Substituição de Liskov (LSP – Liskov Substitution Principle);
  •  Princípio do Conhecimento Mínimo (PLK – The Principle of Least Knowledge)

Diversão Garantida!

4 comentários:

Anônimo disse...

Bom dia Wagner,
seu artigo tem realmente um tema muito interessante e, concordando com voce, necessário para o desenvolvimento profissional. Mas seus argumentos sobre o por quê de se utilizar de padrões, principios e boas práticas ainda está muito atrasado. Sinceramente, só vejo estes comentários em livros antigos, nem os atuais "agilistam" discussão com este argumento, ou então, onde você trabalha somente você é bom, ou ainda, e infelizmente, você só conhece empresas ruins (precisa viajar mais e se informar muito mais). Venha a Fortaleza e a Recife e conheça outra realidade! Se você conhece ou mora em um destes, visite as empresas certas. Bom... fora seus argumentos "fracassados", que parecem mais a conversinha de gente mal informada sobre desenvolvimento de grandes sistemas, sobre a ideia de softwares entregues com atraso, falta de qualidade, etc; seus dois artigo são muito educativos. Parabens!

Anônimo disse...

Desculpe-me não me apresentei, no artigo anterior: DSc Carlos Shumam, email: carlosshumam@hotmail.com

Wagner Santos disse...

Olá Carlos!
Agradeço sua visita ao blog, e por ter apreciado o artigo.
Sobre o seus comentários, sinceramente, não entendi os argumentos que você achou "atrasado".
Meus argumentos foram baseados em números do último relatório do Caos (qdo escrevi o artigo no final de 2009), segue o trecho extraído do próprio artigo.
"O estudo apontou que apenas 32% dos projetos de software tiveram sucesso em sua implementação, enquanto 24% dos projetos falharam e nos 44% restantes houve algum tipo de desperdício, como atraso no projeto ou estouro no orçamento.
Entre os grandes vilões responsáveis pelas falhas nos projetos está a falta de definição clara dos requisitos e estimativas inapropriadas por parte dos analistas e arquitetos de software, que estimulados por metodologias de desenvolvimento de software como Waterfall, insistem em definir toda a arquitetura do sistema nas fases preliminares do projeto, resultando no chamado Big Design Upfront."
Gostaria que você me dissesse o que achou de tão arcaico aqui. No artigo falo de DDD e princípios antigos de Orientação a Objetos, que são base para dos Padrões de projeto. Talvez se as faculdades apresentassem mais estes conceitos abordados no artigo, não teríamos tantos profissionais incapacitados no mercado.
Quanto a minha experiência profissional, tenho mais de 10 anos de experiência em todos os segmentos (varejo, indústria, telecom, financeira, startups, etc..), e em todas estas empresas, graças a Deus tenho trabalhado com excelentes profissionais, inclusive fiquei 1 ano em Recife em uma empresa de grande porte. Portanto, conheço um pouco da realidade do seu Estado.
Mas ao contrário de você, sou aqui de São Paulo - Capital, e lhe convido para também para conhecer algumas das empresas que já atuei, atualmente estou na TIM Brasil como arquiteto, fazendo a implantação de um grande projeto, envolvendo NoSQL, Inference Engine, Adobe Flex, integração de sistemas com REST, e tenho aplicado estes conceitos que vc julgou ultrapassado.
Por último, espero que não julgue mal meus comentários, e gostaria que você leia a última parte do meu artigo, que deve sair na próxima Java Magazine, onde vou abordar Arquitetura de Software em um projeto ágil com XP, e vou falar bastante sobre o papel do arquiteto e como algumas práticas do XP auxiliam este profissional.
Abraço e sucesso.

Anônimo disse...

Wagner, não estou questionando a ideia de que projetos não falham e sim os argumentos que usou para provocar a necessidade de estudos. Este tipo de argumento não deve ser usando nunca. Sou educador e diretor de desenvolvimento e seu o quanto é dificil gerir projetos com pessoas que são pouco ou mal instruidas, mas nem por isto o argumento deve ser: "os projetos falharam por isto". Há muitas variáveis envolvidas e com certeza absoluta a maioria não falha devido aos desenvolvedores.
Então "antigo" é esta argumentação!

Carlos