Continue reading »]]> Continuando com o assunto de qualidade de código, um ponto que considero bastante importante é a nomenclatura de variáveis, metodos, classes, arquivos, …

Isto por que os nomes servem para documentar o que aquele código faz, para que serve, o que ele esta modelando.

Eu acredito que o código, escrito em qualquer linguagem, deve ser legível, ou quase, em portugues ou inglês, normalmente prefiro escrever em inglês, mas isto é padrão do projeto ou preferência pessoal, o importante é a legibilidade do código.

Mas do que eu estou falando?

Pegue um exemplo de código em java:

1
2
3
4
5
6
7
8
9
10
11
12

private void writeFile(String fileName){
  PrintWriter pw = new PrintWriter(fileName);
  pw.format("%1$12s%2$015d%3$013d%4$50s%5$2d%6$1d%7$50s\n",v1, v2, v3, v4, v5, v6, v7);
  Long v8=0l, v9=0l;
  for(Long[] val : recs){
    pw.format("%1$010d%2$010d%3$010d%4$010d\n",val[0], val[1], val[2], val[3]);
    v8 += val[0];
    v9 += 1;
  }
  pw.format("%1$010d%2$010d",v8, v9);
  pw.close();
}

É difícil entender o que o código faz.
Ok, é possível inferir que ele esta gravando um arquivo, baseado em algumas variáveis, com uma linha de cabeçalho, uma de rodapé e várias de detalhes, mas o código não ajuda muito a entendermos isto, pelo menos não tanto quanto o próximo exemplo.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

private void writeFile(String fileName){
  PrintWriter pw = openFile(fileName);
  printHeader(pw, name, cashAvailable, totalNumberOfEvents,description,code,activeFlag,address);
  Long[] res = printDetails(pw,events);
  Long sumOfTransfers = res[0],actualNumberOfEvents = res[1];
  printFoter(pw,sumOfTransfers,actualNumberOfEvents);
  closeFile(pw);
}
private PrintWriter openFile(String fileName){ return new PrintWriter(fileName);};
private void printHeader(PrintWriter pw, String name, Long cashAvailable, Long totalNumberOfEvents, String description, Integer code, Integer activeFlag, String address){
  pw.format("%1$12s%2$015d%3$013d%4$50s%5$2d%6$1d%7$50s\n",name, cashAvailable, totalNumberOfEvents,description,code,activeFlag,address);
}
private Long[] printDetails(PrintWriter pw, Long[][] events){
  Long sumOfTransfers=0l, eventCount=0l;
  for(Long[] event : events){
    Long valueToTransfer=event[0],account=event[1],bancCode=event[2], checkNumber=event[3];
    pw.format("%1$010d%2$010d%3$010d%4$010d\n",valueToTransfer, account, bancCode, checkNumber);
    sumOfTransfers += valueToTransfer;
    eventCount += 1;
  }
  return new Long[]{sumOfTransfers, eventCount};
}
private void printFooter(PrintWriter pw, Long sumOfTransfers, Long actualNumberOfEvents){
  pw.format("%1$010d%2$010d",sumOfTransfers,actualNumberOfEvents);
}
private void closeFile(PrintWriter pw){
  pw.close();
}

Se você tentar ler agora só o código do método writeFile da segunda versão, vai perceber como blocos pequenos de código e nomes decentes de variáveis tornam o código bastante fácil de entender.

Sim, eu sei que este foi um exemplo simples, mas isto vale para situações complexas também.

Claro que eu não sou perfeito, e nem todo o código que eu escrevo é tão legível assim, mas eu sigo algumas regras simples que valem para qualquer linguagem que eu estiver trabalhando, claro que com pequenas variações, que me ajudam a definir os nomes para as entidades no código. Coisa que já vi muita gente tendo dificuldades.

Regras:

1. Nomes de métodos são verbos, que dizem o que o método faz, e não como ele faz
2. Nomes de classes e variáveis são substantivos que dizem o que aquela entidade representa, é só pensar um pouco, a classe ou variável sempre foi criada para representar um conceito, se lendo o nome você não sabe qual era o conceito, o nome esta errado
3. Um método deve realizar uma e apenas uma tarefa
4. O código de um método deve ter no máximo 10 linhas, se não for possível seguir esta regra, siga a próxima
5. Se para ler todo o corpo de um método você precisa fazer scroll na tela, ele esta grande demais, precisa de refactoring urgente
6. Uma classe deve obrigatoriamente seguir o principio da única responsabilidade, uma classe nunca deve representar mais de um conceito, nem ter métodos para realizar tarefas que não tenham a ver com este conceito primordial
7. Não sei qual o tamanho máximo para o corpo de uma classe, ou para um arquivo de código fonte, mas com certeza é muito menos de 1k linhas
8. Refatore sempre que uma parte do código não estiver seguindo qualquer um destes conceitos

O que vocês acham destas regras? Alguma regra adicional? Concordam com elas? Acham que não se aplicam a algum caso? Acham um monte de besteiras? Vou ficar bastante feliz de ler comentários sobre legibilidade de código.

PS.: o que acham de um post sobre refactorings?

Continue reading »]]> Bom, como alguns de vocês devem saber, eu apresentei a palestra “Java EE + JRuby + Rails – interfaces rapidas para aplicações Java EE” no Just Java 2013.
Como sempre aprendo algo fazendo a palestra, nesta eu aprendi que estou meio enferrujado com este esquema de palestrar, vários pontos eu poderia ter apresentado melhor, e tenho que melhorar a programação também, passei meio rapido por alguns dos topicos por que tinha o avião marcado de volta e tinha que cuidar o horario do fim, e o final do coffee atrasou por causa dos sorteios, mas acho que mesmo assim a palestra foi legal.

Para quem não conseguiu ir até o evento, mas gostaria de assistir a palestra, eu gravei a apresentação e estou disponibilizando o video aqui no blog (coloquei no vimeo, se alguem quiser baixar ele para assistir offline o download esta disponível por la).

2013 Palestra Just Java – JRuby on Rails – Interfaces ricas para aplicações Java EE from Rodrigo Urubatan on Vimeo.

Para quem quiser acessar o código das apps de exemplo, elas estão bem cruas, mas seguem os links:
- App Rails
- App Java

E os slides estão aqui no SlideShare

Quem tiver perguntas depois de assistir o video, é só deixar a pergunta em um comentário aqui que respondo sem problemas

Continue reading »]]> Eu já participei de mais de um projeto que em algum momento se perdia a capacidade de dizer quanto tempo se levaria para fazer qualquer alteração, normalmente por que uma alteração em qualquer lugar refletia em todos os outros pontos aleatórios do sistema.
Também já participei de projetos em que se olhando para o nome de uma classe, de um método, de uma tabela não se fazia idéia de para que aquilo servia, o nome não dava pista nenhuma de para que o objeto era usado.
Muitas vezes um projeto tinha os dois problemas ao mesmo tempo.
Outros projetos que participei utilizavam soluções “mágicas” para resolver todos os problemas, e rápidamente não se sabia mais o que tinha causado algum efeito no código, se era o próprio código ou alguma das mágicas aplicadas nele.

Acredito que muitos de vocês já passaram por estes problemas também, normalmente chamamos isto de código legado, mas vou dizer algo que muitos não vão gostar de ouvir, muitos destes projetos, eu ou algum dos outros desenvolvedores que estavam ali ainda, participou desde o inicio, ajudamos a definir os padrões, a definir a arquitetura, e pouco tempo depois passamos a ignorar os padrões que nós mesmos haviamos definido.

Mas o que causou isto? o que fez este código deteriorar desta forma? Acho que muitos responderiam algum ou alguns dos seguintes itens:

• Prazos apertados
• Pressão do cliente
• Já estava assim
• Ninguem seguia os padrões eu também não vou seguir
• Vou fazer isto desta forma e depois volto para arrumar, mesmo sabendo que isto não iria acontecer
• Vai ser mais rapido fazer deste jeito mesmo, a qualidade do código aqui não vai fazer diferença
• Outra opção qualquer

Mas pelo menos nas situações em que eu vivi, estas afirmações não eram validas, vou comentar algumas delas, e normalmente os culpados por criar o código feio, dificil de manter, dificil de lêr, eram os próprios desenvolvedores (claro, eu incluido).

Pressão do cliente e prazos apertados não são razões válidas para código ruim, por que o código ruim vai fazer com que tudo demore mais e vai piorar o negócio do cliente, não entregando um produto de qualidade.

Já estava assim é uma desculpa preguiçosa de quem não se importa com a qualidade do seu próprio trabalho, se já estava assim, tente arrumar, reclame com alguem que pode arrumar, ou pelo menos tente descobrir por que estava assim. E mesmo assim, isto não é disculpa para que o código novo que você esta escrevendo siga ruim, o novo pedacinho pode ser melhor do que o espaguete que você encontrou.

Se ninguem estava seguindo os padrões, também não seguir aumenta o problema, o ideal seria falar com a equipe, com algum gerente, lider tecnico, organizar code reviews e mostrar por que aqueles padrões eram importantes. Se ninguem concorda com os padrões definidos, que eles sejam alterados, mas é importante ter padrões.

E por último, pensar que fazer de qualquer jeito vai ser mais rapido é uma armadilha que quase todos já caímos, o problema de codigo ruim é que ele deve vir acompanhado de mais bugs, e vai ser mais difícil de debugar, e de corrigir, ou seja, no final, vai levar mais tempo para entregar a feature para o cliente.

Até aqui acho que todos devem concordar, mesmo não gostando muito, mas agora, o ponto que vai ter mais discussão, inclusive vou dividir o assunto em outros posts, o que é código ruim e o que é código bom?

O “Uncle Bob” tem uma definição interessante, que eu concordo e acho que a maioria vai concordar: a qualidade do código pode ser medida pela quantidade de WTF ouvida durante uma sessão de code review.
(WTF – What the Fuck – que merda é esta – o que esta merda faz – que porcaria é esta – …)

Sei que isto é bastante subjetivo e vai variar do quão dormentes estão os membros da equipe, mas já é uma boa definição para começar.

Eu adicionaria mais alguns itens para considerar um código bom, sendo o principal dele a legibilidade.
O que é legibilidade? Simples, é a qualidade que permite que quando você ler o nome de um método, classe, arquivo, …
Você saiba para que ele serve, o que ele faz.
E quando você ler o corpo de um bloco de código, você vai entender e exatamente para que ele serve, o que ele faz.
– Ahh, mas existem comentários para isto!
Errado!
Comentários existem e são muito bons para que você documente por que fez algo, qual foi a origem do requisito. Se você esta comentando o que o código faz, já é um sinal de que o código deve ser um lixo.

A performance do código tem que ser boa também, e isto é uma outra medida bastante subjetiva.

É necessário também seguir os padrões de codigo da linguagem sendo usada, não adiante o código java parecer ruby, ou o código c++ parecer java, ou o código python parecer código ruby.
Cada linguagem tem um padrão, e normalmente as construções da linguagem funcionam melhor se aquele padrão é seguido, isto vai trazer código mais limpo.

Alem disto gosto de adicionar algumas regrinhas simples para ajudar na legibilidade, seguir alguns principios, mas vou falar disto em um próximo post.

Alguem tem outra opinião sobre este assunto? Alguem tem algum comentário complementar? Todos os comentários são bem vindos

Continue reading »]]>

Bom, como a maioria já deve estar sabendo, no final da próxima semana vai acontecer o Just Java 2013, o evento vai acontecer nos dias 7 e 8 de junho. no SENAC – CAMPUS SANTO AMARO, Avenida Engenheiro Eusébio Stevaux, 823 – São Paulo – SP.

Quem quiser dar uma olhada na grade, pode clicar aqui.

O Just Java é, acredito, o maior evento independente sobre java do Brasil, é organizado pelo SouJava, um dos mais antigos grupos de usuário do brasil, e um dos mais ativos com certeza.

Participo do evento desde 2002 (se não me engano foi o primeiro que participei), já palestrei em várias edições, e acho que só não fui nos últimos 3.

Este ano vou apresentar a palestra “Java EE + JRuby + Rails – interfaces rapidas para aplicações Java EE”, que acho que vai ser bastante útil, farei o máximo para ser divertida, alem de apresentar diversas situações que passei em alguns projetos.

Se quiser se adiantar um pouco e aprender um pouco sobre Rails antes do Just Java, podem comprar meu livro na Novatec

Falando em , gostaria de agradecer a eles por patrocinar a minha ida ao evento!
Para se adiantar um pouco, o que acham de ler alguns livros sobre Java?

E por último, o que estão esperando para se inscrever no Just Java 2013? Daqui a pouco as vagas acabam.

Continue reading »]]> Como alguns devem ter ouvido falar, estou escrevendo um livro sobre BDD, o cucumber não vai ser a única ferramenta usada no livro, mas é uma das principais, até por ser gratuitas, e por eu gostar bastante de Ruby.

Escrevendo o livro, tive a idéia de fazer este curso online, vão ter vagas limitadas, vou usar o Hangout pela possibilidade de vídeo conferência e compartilhamento de telas, fiz alguns testes e a ferramenta pareceu atender bem o que passei para o curso.

O conteúdo do curso vai ser o seguinte:

• Aula 1
  • O que é BDD
  • Como começar a aplicar na empresa ou nos projetos particulares
  • Introdução à Domain Driven Design
  • Introduzindo uma linguagem Ubiqua para negócio, análise, desenvolvimento e testes
  • Como escrever testes usando a linguagem gherkin
  • Como tornar testes escritos em linguagem natural  executaveis
• Aula 2
  • Usando cucumber para testar aplicações rails
  • Usando drivers para teste de Ajax
  • Testando bibliotecas ruby
• Aula 3
  • Cucumber e JRuby para testar bibliotecas Java
  • Cucumber e IronRuby para testar bibliotecas .NET
• Aula 4
  • Melhorando os relatórios, formatadores de saida
  • Usando tags para filtra testes
  • Executando apenas os testes com falha
  • Ganchos de execução

Serão apenas 10 alunos, já que vou fazer o curso via Hangout, e também para dar atenção a todos como se estivessemos em uma sala de aulas, mas cada um vai estar no conforto do lugar que escolher.

Quem fizer o curso vai ganhar apostila em PDF, acesso ao código dos exemplos via um repositório git, um video com a gravação de cada uma das 4 aulas, e se quiser tem a opção de comprar uma copia do meu livro de Rails com 50% de desconto.

Cada uma das aulas deve ter entre 3 e 4 horas, e as aulas acontecerão sempre quinta feira a noite, começando as 19h.

Se o assunto se prolongar mais do que 4 horas, os participantes decidem se continuamos a aula ou se fazemos uma aula extra sobre algum assunto especifico.

Publico Alvo:

O curso foi feito pensando em desenvolvedores, e ou testadores que queiram ter um conhecimento sobre todo o fluxo e todos os requisitos da aplicação. A primeira aula também vai ser extremamente útil para gerentes de projetos, analistas de negocios, alem de ser extremamente útil para product owners. As aulas seguintes incluem bastante desenvolvimento, e serão mais bem aproveitadas por quem tenha algum conhecimento de desenvolvimento. O Ruby vai ser usado como linguagem principal, mas conhecimento em qualquer linguagem de programação vai ser o suficiente, uma das apostilas vai conter uma introdução a linguagem Ruby, que vai ser o suficiente para entender bem todos os exemplos do curso.

Pre requisitos:

Para aproveitar bem o curso e importante conhecer bem alguma linguagem de programação, não é necessário conhecer previamente Ruby, é importante também ter uma noção de como definir regras de negócios de uma aplicação, e ter coragem e vontade de querer implantar uma linguagem única em todo o processo de desenvolvimento, da coleta de requisitos ao desenvolvimento.

Investimento:

O pagamento vai ser feito via paypal ou deposito, como esta é uma primeira experiência, não vou ter um sistema especifico para gerenciar as inscrições, então as inscrições serão feitas enviando um email para cursobdd@urubatan.com.br, enviem o email informando se querem pagar via paypal ou deposito.

O valor do curso vai ser de R$400.

Se quiser comprar o livro com 50% de desconto, basta adicionar R$34,50 no valor da inscrição e o frete (gratuito via PAC, se preferir sedex enviar email para verificar o preço).

Datas do curso:

A previsão inicial é que o curso aconteça nos dias: 13/06, 20/06, 27/06 e 04/07, qualquer alteração os incritos serão visados e consultados.

Continue reading »]]> Em um projeto atual estava trabalhando com o VRaptor e precisei fazer deploy da aplicação em um Oracle Weblogic 12c, muitos erros apareceram e algumas coisas meio malucas, tipo dizer que um método não existia em uma classe do guice.

O fix para isto é bastante simples, basta adicionar dentro do diretório WEB-INF da aplicação web, um arquivo de nome weblogic.xml com o seguinte conteúdo:

1
2
3
4
5
6
7
8
9
10
11
12

<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app
	xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
	<wls:weblogic-version>12.1.1</wls:weblogic-version>
	<wls:context-root>seu_contexto</wls:context-root>
	<wls:container-descriptor>
		<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
	</wls:container-descriptor>
 
</wls:weblogic-web-app>

E pronto, depois disto a aplicação vai carregar no WL12c sem problemas

A magica é feita pela tag prefer-web-inf-classes, que faz o WL carregar as classes do WEB-INF/lib em vez de carregar a versão mais velha que veio junto com o weblogic.

O próximo warning foi do SL4J, para resolver o warning de multiplos bindings, simplesmente removi o pacote do SL4J do WEB-INF/lib e tudo passou a funcionar, depois de um restart do servidor, por que neste momento conflito de classloader era o que eu mais tinha

Continue reading »]]>

Ok, e aquela coisa toda sobre automação de browser, …

Aquilo é feito por outras bibliotecas Ruby, que podem ser utilizadas em conjunto com o cucumber.

Ahh, beleza, quer um exemplo?

O cucumber, lê o código abaixo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#language: pt
Funcionalidade: Visualização de progresso atual de um projeto
	Como um cliente do projeto
	Eu quero visualizar o progresso das funcionalidades que solicitei
	Para que eu possa saber quando elas estarão disponiveis para uso
 
	Contexto:
		Dado que existem os seguintes projetos cadastrados:
			|nome         |Descricao           |
			|Projeto 3    |Outro projeto       |
			|Projeto 4    |Outro projeto       |
		E que existem os seguintes usuários cadastrados:
			|login      |nick         |
			|jose       |José Silva   |
		E que os usuários fazem parte da equipe dos projetos:
			|login      |projeto       |
			|jose       |Projeto 3     |
			|jose       |Projeto 4     |
 
	Esquema do Cenário: visualização de progresso em uma tarefa
		Dado que estou na página de dealhes do projeto "<projeto>"
		E que o usuário "<usuario>" reportou progresso "<progresso1>" na tarefa "<tarefa1>"
		E que o usuário "<usuario>" reportou progresso "<progresso2>" na tarefa "<tarefa2>"
		Quando eu clico em "Ver progresso"
		Então devo ver "Progresso Atual" igual a "<progresso>"
 
	Cenários:
		|usuario    |projeto    |progresso1|tarefa1|progresso2|tarefa2|progresso|
		|jose       |Projeto 3  |30        |task1  |100       |task2  |65       |
		|jose       |Projeto 4  |60        |task1  |80        |task2  |70       |

E mapeia para o seguinte código ruby:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

#encoding: utf-8
 
Dado(/^que existem os seguintes projetos cadastrados:$/) do |table|
  # table is a Cucumber::Ast::Table
  pending # express the regexp above with the code you wish you had
end
 
Dado(/^que existem os seguintes usuários cadastrados:$/) do |table|
  # table is a Cucumber::Ast::Table
  pending # express the regexp above with the code you wish you had
end
 
Dado(/^que os usuários fazem parte da equipe dos projetos:$/) do |table|
  # table is a Cucumber::Ast::Table
  pending # express the regexp above with the code you wish you had
end
 
Dado(/^que estou na página de dealhes do projeto "(.*?)"$/) do |arg1|
  pending # express the regexp above with the code you wish you had
end
 
Dado(/^que o usuário "(.*?)" reportou progresso "(.*?)" na tarefa "(.*?)"$/) do |arg1, arg2, arg3|
  pending # express the regexp above with the code you wish you had
end
 
Quando(/^eu clico em "(.*?)"$/) do |arg1|
  pending # express the regexp above with the code you wish you had
end
 
Então(/^devo ver "(.*?)" igual a "(.*?)"$/) do |arg1, arg2|
  pending # express the regexp above with the code you wish you had
end

E apenas isto, fora isto, o cucumber não faz mais nada (ok, tem mais alguns recursos legais, mas nada relacionado diretamente com a interpretação de textos).

E de quebra, este bloco de texto mostra uma funcionalidade escrita em portugues, que inclui quase todos os recursos do gherkin implementados pelo cucumber

Bom, se tiverem comentários sobre uso do cucumber, ou sobre este post, por favor postem nos comentários, ou perguntem diretamente pelo twitter ou facebook, acho que o blog vai identificar qualquer uma das formas de comentário

Continue reading »]]>

Alguem pode ter a idéia de habilitar queries paralelas via uma trigger de logon no oracle, mas se alguem te sugerir isto, depois de bater na pessoa, diga educadamente que você prefere que o resto da aplicação continue funcionando.

Por que eu digo isto?

Um exemplo simples:

1
2

DELETE FROM tabela WHERE id=345;
SELECT COUNT(*) FROM tabela;

Funciona perfeitamente!

Agora habilite as queries paralelas, e o select count só vai funcionar depois de um commit;

Se tentar fazer um delete muito grande com a trigger de parallel habilitada também vai ter problemas, começara a ver a seguinte mensagem de erro:

ERROR at line 1:
ORA-12801: error signaled in parallel query server P117, instance
xxx802:user2 (2)
ORA-00060: deadlock detected while waiting for resource

Se estiver tentando fazer a operação de delete via DBLINK fica ainda mais divertido, a mensagem de erro é:

ERROR at line 1: ORA-20000: # Erro na cópia dos dados:ORA-02049: timeout: distributed
transaction waiting for lock
ORA-02063: preceding line from DBL_NOME
ORA-06512: at “SCHEMA.PROCEDURE”, line 34

E como resolver tudo isto e faze a sua applicação voltar a funcionar?

É só dropar a trigger de logon que fazia as consultas rodarem de forma paralela no oracle!

Ou seja, depois de bater na pessoa que sugerir esta trigger de logon, explique educadamente por que ela esta apanhando, para que ela evite apanhar de outra pessoa menos educada que você.

Continue reading »]]> Em uma situação no trabalho, decidi que seria interessante ter algumas regras básicas de como escrever código legível, seguindo aquele padrão:

Escreva seu código como se quem vai dar manutenção nele fosse um maniaco homicida que sabe seu endereço

E como utilizamos mais de uma linguagem no projeto, achei que seria possível definir regras básicas para todas as linguagens (depois criar itens especificos de cada uma), e a lista de itens genéricos que me veio a cabeça foi esta listinha abaixo:

• Nomes de classes:
  • 1. devem usar CamelCase
  • 2. Devem dizer claramente o que a classe representa
  • 3. De preferência devem ser um substantivo, um objeto, com o nome facilmente mapeável para uma entidade de negocio no domínio da aplicação
  • Nomes de métodos:
    • 1. Devem ser um verbo, que faça sentido dentro do dominio da classe onde ele se encontra ou no máximo seja um verbo auxiliar válido para uma das ações válidas da classe
    • 2. Seguem o padrão da linguagem:
    • java camelCase
    • python/ruby snake_case
  • 3. De preferência não tenham mais de 10 linhas de código, exceções avaliadas independentemente
    • Caso o método tenha mais de 10 linhas, avaliar refatorar parte do código em um método auxiliar
• Nomes de variáveis:
  • Seguem o padrão da linguagem:
    • java camelCase
    • python/ruby snake_case
  • O nome deve indicar o que a variável representa, sem prefixos indicando o tipo
    • notação hungara só é aceitável em linguagens que usam explicitamente este padrão nas bibliotecas core
  • Variáveis indexadoras (i, j, k, idx, …) são exceção a estas regras de nomenclatura

O que vocês acham destes itens, e tem alguma sugestão de melhora deste padrão genérico? a idéia é ter código fácil de ler e entender independente da plataforma/linguagem, e ter um padrão que profissionais de diversas senioridades possam seguir.

Agradeço quaisquer comentários!

Continue reading »]]> Escrevendo um pouco sobre BDD, comecei um rascunho de artigo sobre doman driven design, claro que vou elaborar mais ainda, mas acho que a versão inicial ficou decente, e como o livro de BDD ainda vai demorar bastante, vou postando alguns artigos e tutoriais por aqui de vez en quando

Mas como eu disse, é um rascunho, agradeço quaisquer comentários sobre coisas a melhorar, coisas que eu possa ter interpretado errado e qualquer coisa que vocês acharem que precisa de correção neste texto.

Sem mais delongas …

Domain Driven Design (DDD)

Domain Driven Design, ou design guiado pelo dominio do negocio, é um conjunto de boas praticas e regras, que definem que todos os artefatos gerados durante o desenvolvimento, devem ter a mesma nomenclatura utilizada para definir o dominio do negócio.

Para tornar o DDD possível, é necessário definir um dicionário de negócio com as palavras e conceitos principais ordenados de forma hierarquica, isto vai tornar bem mais fácil escolher nomes e decidir quais as propriedades de um artefato qualquer a ser criado.

Isto também elimina a necessidade de se criar padrões complexos de nomes para objetos, já que o nome para um artefato qualquer deve ser uma das palavras do dicionário de negócio, isto vai facilitar bastante quando um desenvolvedor for perguntar ou explicar algo para um cliente, por exemplo, imagine o seguinte dialogo:

• Cliente: pode por favor me explicar qual problema esta ocorrendo no cadastro de clientes?
• Desenvolvedor: o problema é que o entity manager esta retornando um erro InvalidValueException quando chamo o metodo persist passando um objeto do tipo EntityCliData
• Cliente: entity o que? o que é persist?

Agora imagine a mesma conversa com estas palavras:

• Cliente: pode por favor me explicar qual problema esta ocorrendo no cadastro de clientes?
• Desenvolvedor: o problema parece ser na implementação do método cadastrar da classe Cliente que esta retornando um erro de parâmetro inválido.
• Cliente: a, obrigado, o erro informa qual parâmetro esta com problemas?

Ou seja, utilizando as mesmas terminologias, é bem mais fácil a comunicação, claro que isto também altera a forma de implementar algumas coisas, mas o esforço é minimo perto dos beneficios que isto vai trazer para o projeto.

O termo “Domain Driven Design” foi usado pela primeira vez por Eric Evans no livro de mesmo nome escrito por ele. Segundo este livro, a abordagem possui 3 pilares básicos:

1. Colocar o foco primário do projeto no dominio central da aplicação e na lógica do dominio
2. Basear designs complexos em um modelo do dominio
3. Iniciar uma interação colaborativa entre pessoas técnicas e especialistas do dominio para interativamente refinar um modelo conceitual que enderece problemas especificos do dominio da aplicação.

Definições básicas

• Dominio: é um dominio de conhecimento, influencia ou atividade. O assunto no qual o usuário usa o programa é o dominio da aplicação.
• Modelo: Um sistema de abstrações que descreve aspectos selecionados de um dominio e pode ser utilizado para resolver problemas naquele dominio.
• Linguagem Ubiqua: Uma linguagem estruturada a volta do dominio e utilizada por todos os membros da equipe para conectar todas as atividades relacionadas ao desenvolvimento de software.
• Contexto: a situação em que uma palavra aparece que define o significado da mesma.

Blocos básicos do DDD

• Entity – objetos com dados e significado de negócio
• Value Object – objetos com dados mas sem sifnificado proprio para o negocio
• Aggregate – uma coleção de objetos unidos por uma raiz comum, esta raiz comum é responsável por garantir a integridade dos objetos agregados.
• Service – Quando uma operação conceitualmente não pertence a nenhum objeto, esta pode ser modelada como um serviço.
• Repository – metodos para buscar objetos devem ser delegados para um repositório especializado
• Factory – métodos para criar objetos devem ser delegados para fabricas especializadas

Com estes blocos básicos, a maior parte dos sistemas DDD podem ser implementados sem maiores problemas.

O objetivo principal é tornar a linguagem utilizada pelo negocio para definir o dominio do problema, ubiqua dentro de todo o projeto, utilizando a mesma linguagem na analise de negocio, na documentação da aplicação e no código da aplicação, facilitando assim a comunicação e o entendimento, e o melhor de tudo, diminuindo bastante a probabilidade de ser implementado algo diferente do que foi solicitado.