Bad Smell

- 4 características que eu considero essenciais, presentes em um código ruim:

Código duplicado: Esse smell geralmente acontece quando temos uma classe god, e acabamos escrevendo duas ou mais vezes a mesma lógica, que poderia ser escrita uma vez só, caso aplicássemos as regras de orientação a objetos e polimorfismo.  Nesse caso é gerado código muito grande e desnecessário.

Lista de parâmetros longa: Essa regra é muito utilizada quando começamos a programar, mas pode causar um transtorno quando não vamos utilizar todos os parâmetros, bem como dificulta o entendimento do código. A ideia de passar um objeto ao invés de parâmetros.

Classes alternativas com diferentes interfaces: Esse smell é gerado quando temos duas ou mais classes que fazem (ou fazem quase) a mesma coisa, porém com nomes diferentes.

Classe de dados: São classes que só contem atributos (getters e setters), que geralmente são acessadas e manipuladas por outras classes. Geralmente são nada mais que depósitos de dados

- 4 características que eu considero essenciais, presentes em um código bom:

Nomes significativos: Usar nomes nos atributos e métodos que transcrevam o modelo de design ajuda na manutenção e no entendimento do código por outros desenvolvedores.

Indentação de código: Deixar o código bem organizado e ter um padrão a ser seguido pelo time é essencial para o bom entendimento da estrutura lógica do código.

Uso de Exceções: Além de deixar o código mais legível, previne o código contra falhas nos tratamentos de arquivos, entradas de dados inválidas, erros de consultas à base de dados, entre outras.

Test Driven Development:  Ajuda a focar no resultado final, e nos garante uma refatoração mais segura das classes, garantindo que ao alterar um método, todos os requisitos do software serão atendidos, sem a necessidade de testar os mesmos a cada mudança, deixando essa parte automatizada.

Domain Driven Design 3

Este é o ultimo post sobre DDD, onde farei o resumo do capítulo 3 do livro Domain Driven Design Quickly, que pode ser baixado gratuitamente na InfoQ:

http://www.infoq.com/minibooks/domain-driven-design-quickly

Para a criação de um modelo correto, que venha realmente a capturar as regras do domínio, os analistas de software e os peritos no domínio se reúnem por meses, para descobrir os elementos fundamentais do domínio, enfatizando os relacionamentos. Os desenvolvedores podem vir a se juntar ao time para verificar a possibilidade de expressar no código esses conceitos e relacionamentos desenhados no modelo. Assim começa a criação de um modelo, com inspiração no modelo original, adicionando algumas ideias da equipe técnica.

Uma técnica muito utilizada é a criação do modelo de análise, que é separado do código e feito por pessoas diferentes. Neste modelo temos ênfase na regra de negocio, e nenhuma ênfase na codificação a ser implementada no software. É gerado certo nível de conhecimento a respeito do software a ser desenvolvido. Com base nesse modelo, os desenvolvedores irão adapta-lo para um modelo que irá guiar a equipe de desenvolvimento.

Um dos principais problemas dessa técnica é que como os analistas não conseguem enxergar além das regras de negócios, o modelo pode se aprofundar em determinadas questões que não irão ser tão pertinentes para a regra de desenvolvimento. E podem esquecer outros pontos, que podem vir a ser importante para elucidação da equipe de desenvolvimento.

Em razão desta falta de documentação, os desenvolvedores terão que tomar algumas decisões por sua conta, que visarão resolver ou solucionar algum problema real que não foi considerado no modelo criado e acabam criando um modelo que foge um pouco do modelo original.

Normalmente os analistas têm reuniões fechadas, onde discutem a respeito do modelo a ser desenvolvido, e neste momento muita informação valiosa é compartilhada nessas reuniões. Eles criam um modelo que supostamente contem toda informação de uma maneira condensada, e os desenvolvedores deverão assimilar essa informação lendo a documentação que lhes foi dada. Uma sugestão é que seria muito mais produtivo que os desenvolvedores participassem dessas reuniões com os analistas para conseguir capturar um melhor conhecimento da regra negocio e poderem desenhar um modelo mais completo.

Uma melhor abordagem é relacionar o domínio de modelo com o design. O modelo deve ser desenhado com foco no desenvolvimento do software e nas considerações de design. Os desenvolvedores devem ser incluídos no processo de modelagem. A ideia principal é escrever um modelo que melhor expressa o software a ser desenvolvido, deixando ele fortemente relacionado com a codificação a ser escrita, e consequentemente tornando o modelo mais relevante.

Manter os desenvolvedores envolvidos neste processo ocasiona feedback por parte dos mesmos. Acaba gerando uma segurança de que o modelo poderá ser implementado no software. Se algo estiver errado, poderá ser identificado logo, e o problema será facilmente corrigido.

É importante que todo time técnico, responsável por desenvolver e manter o código tenha algum contato com o modelo. Todos tem ter algum nível de contato e discussão a respeito do modelo e com os especialistas na regra de negocio.  Esse envolvimento entre todas as partes interessados ajudaram a criar a Ubiquitous Language.

Programação Orientada a Objetos é a mais adequada e que mais combina com a implementação de modelo. Ambas se baseiam nos mesmos paradigmas. O desenvolvimento OO trabalha com classes de objetos, associações entre as classes e instancias de objetos. Linguagens OO torna possível a criação de mapeamentos diretos entre objetos do modelo com seus relacionamentos.

Domain Driven Design 2

Neste post farei o resumo do capítulo 2 do livro Domain Driven Design Quickly, que pode ser baixado gratuitamente na InfoQ:

http://www.infoq.com/minibooks/domain-driven-design-quickly

Existe uma grande diferença entre a mentalidade de desenvolvedores e analistas de negocio. Os desenvolvedores costumam pensar e imaginar o sistema na forma de classes, métodos, algoritmos, e tendem sempre a fazer uma ligação entre os conceitos do mundo real com os conceitos de relações e modelagens. Eles pensam em termos de herança, polimorfismo, Orientação a Objetos, etc,... Já os especialistas no negocio não entendem nada a respeito de bibliotecas, frameworks, persistências, e, em muitos casos, não conhecem até mesmo banco de dados. Eles sabem somente a respeito das regras do negócio.

Um dos princípios fundamentais do DDD é usar uma linguagem focada no modelo, e é sugerido que esta linguagem seja adotada em comum tanto para documentação quanto para programação. Este princípio é essencial para integração entre os especialistas de negocio e desenvolvedores.

Quando o time como um todo começa a usar essa linguagem comum em todas as partes do projeto, tanto para se comunicar, como documentar e desenvolver, acabam gerando uma linguagem conhecida no DDD como Ubiquitous Language.

Essa linguagem em comum cria a premissa de que toda a equipe, ao usar a mesma linguagem, irá descobrir ao longo dos meses, como o sistema deverá funcionar e ajudará a descobrir inconsistências e conceitos inadequados no design.

Para tanto, os especialistas no negócio deverão se opor a termos técnicos ou difíceis de entender no modelo de negocio. Se no modelo tiver algum termo que eles não consigam entender, então provavelmente algo está errado. Assim como os desenvolvedores devem ficar atentos a inconsistências ou ambiguidades no modelo.

Ao escrever o código usando a Ubiquitous Language para criação de classes, métodos e atributos estará sendo feita uma ligação entre o modelo e código. Esta prática vem a ser de extrema utilidade, visto que torna o código muito mais legível, e auxiliará, posteriormente, nas alterações do código conforme o crescimento do projeto.

Uma maneira eficaz para expressar classes, atributos e relacionamentos é através da UML, entretanto, o comportamento entre as classes não é tão facilmente expressado através desta documentação. Entretanto, pode-se utilizar de notações no diagrama para tentar explicar o comportamento esperado dos objetos. Esta documentação explicativa pode vir através de pequenos diagramas de uma parte do modelo contendo a explicação necessária. Nestes diagramas podem aparecer diversas classes e seus respectivos relacionamentos.

Esta documentação é de caráter temporário, podendo ser feita, inclusive, a mão, significando pode ser mudada em um futuro próximo, assim como o modelo pode ser alterado diversas vezes até ficar estável. De acordo com as práticas da comunidade de Extreme Programming pode-se incluir o código na documentação, pois um código bem escrito, utilizando as praticas de TDD (Test Driven Development) e a Ubiquitous Language nas classes e atributos pode deixar a codificação muito comunicativa.