terça-feira, 12 de novembro de 2013

Boas práticas ao criar testes com Selenium

Olá, pessoal!

Publiquei mais um texto no blog da Dextra: Boas práticas ao criar testes com Selenium:
Testes automatizados são um assunto de suma importância para um sistema. Uma das ferramentas de grande destaque nesta área, quando estamos falando de sistemas web, é o Selenium
É importante ter o entendimento de como usar da melhor maneira o Selenium, evitando trilhar caminhos perigosos no seu uso e extraindo o que há de melhor dele. Sendo assim, este texto segue com algumas dicas de utilização do Selenium que podem poupar o desenvolvedor de alguns problemas. 
Mas, de quais problemas estamos falando?
 Espero que gostem!

quarta-feira, 30 de outubro de 2013

Textos de minha autoria no blog da Dextra!

Olá, pessoal!

Agora também estou publicando textos no blog da Dextra! Já foram 2 publicados!

O primeiro fala de uma característica (ou bug?) do Hibernate ao realizar mapeamentos @OneToOne em determinadas condições. Importante leitura para todo desenvolvedor que usa Hibernate!

O segundo publicado foi o primeiro de uma série de vários textos com dicas de uso do Hibernate, que vão das simples até as mais avançadas. A maioria deles serão publicados no blog da Dextra, mas deixarei o link de cada um deles aqui no blog também.

Espero que gostem!

quarta-feira, 23 de outubro de 2013

Comparando Enumerators no Java

Olá, pessoal!

Estou aqui novamente, agora para falar dos Enumerators no Java.

Trabalhando com Enumerators, é normal precisarmos comparar um Enumerator com outro Enumerator. Existem 2 formas de fazer isto:
  • usando equals();
  • usando == ;

O uso que vejo mais comum é do equals(). Acredito que seja mais usado pelo fato do equals() ser adotado em qualquer comparação de objeto, pois o uso do == realiza a comparação de endereço na memória (que é o que raramente precisamos na aplicação).

Tão raro mas... faz todo sentido no caso dos Enumerators! Com uma vantagem: previne NullPointerException. Como isto é possível? Vamos aos exemplos.

Vamos pensar em um Enumerator chamado TipoDocumento, que contém as seguintes constantes: CPF e CNPJ:

public enum TipoDocumento {
    CPF, CNPJ;
}

Digamos que uma classe Pessoa tenha um atributo TipoDocumento:

public class Pessoa {
     private TipoDocumento tipoDocumento;
     //getters e setters
}




Dado 2 instâncias de Pessoa (vamos chamá-las de pessoa1 e pessoa2), podemos comparar seus tipos de documento com equals():

if(pessoa1.getTipoDocumento().equals(pessoa2.getTipoDocumento()) {
     //...
}

ou usando == :

if(pessoa1.getTipoDocumento() == pessoa2.getTipoDocumento()) {
     //...
}

Reforçando, as 2 soluções são corretas!

Contudo, a segunda solução tem a vantagem de não estar tão sujeita a um NullPointerException quanto na primeira, pois se o getTipoDocumento da pessoa 1 estiver nulo na primeira solução, ocorrerá um NullPointerException.

A segunda solução também funciona pois o CPF e CNPJ são constantes do TipoDocumento, portanto, terão sempre o mesmo endereço na memória da aplicação. Por esta razão, podemos utilizar o operador == para comparação. Uma última vantagem da segunda abordagem é que ela deixa o código mais legível, o que é sempre bem-vindo.

Enfim, uma dica simples, mas útil =).

sábado, 7 de setembro de 2013

10 livros para desenvolvedores Java experientes

Olá pessoal!

Saiu no blog Java Code Geeks um post sobre os melhores 10 livros para desenvolvedores Java experientes. Vale conferir, mesmo que você não se considere tão experiente assim!

Já tive a oportunidade de conferir o Effective Java e Clean Code! Vocês ouvirão eu falar destes livros aqui algumas vezes. Outro livro que também está na lista do blog, e que será minha próxima leitura, é o Refactoring: Improving the Design of Existing Code, do Martin Fowler.

Tudo a ver com qualidade!

sexta-feira, 30 de agosto de 2013

Mão na massa! Como retornar coleções em métodos?

Depois dos primeiros textos sobre qualidade, que focavam mais no aspecto comportamental com relação ao novato, equipe, chefe, cliente e empresa, vamos agora começar a falar de código!

Como estamos começando o assunto no blog, de início não vou partir para nada mais avançado em termos de qualidade de código, como design patterns. Vou começar a demonstrar pequenas práticas, com foco na linguagem Java, que podem ser facilmente incorporadas no código produzido diariamente pelo desenvolvedor. Em princípio, acredito que serão muito úteis para os desenvolvedores novatos.

Um bom programador deve dominar o conhecimento de práticas simples na construção de código. Livros como Code Complete, Clean Code e Effective Java exploram muito bem estas práticas, só que este conteúdo parece não alcançar grande parte dos desenvolvedores, pois observo que pouco se fala e se exercita qualidade de código no Brasil, ainda mais quando falamos da parte de testes. Obviamente, teste é primordial para conquista de qualidade, mas ele sozinho está longe de resolver seu problema de qualidade. Como diria Steve McConnell, no livro Code Complete:

[...] trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often.

Sendo assim, vamos para uma pequena e simples prática:

  • Ao invés de retornar null para métodos que retornam uma coleção (um List, por exemplo), retornar uma coleção vazia;

Vamos a um exemplo. Imagine que você tem o seguinte método:

public List<String> consultarListaDeAlgumaCoisa() {
       //metodo fazendo alguma logica para retornar alguma coisa
       return null;
}

Evite fazer isto! Se ocorre algo na lógica do seu código onde a lista poderá vir sem elementos, retorne uma lista vazia ao invés de null:


public List<String> consultarListaDeAlgumaCoisa() {
       //metodo fazendo alguma logica para retornar alguma coisa
       return Collections.emptyList();
}

Assim, quando alguém chamar este método, não precisará verificar se a lista está nula ou não. Isto significará menos código a ser escrito, lido e chances menores de NullPointerException na aplicação.

É claro, existem raras ocasiões que o retorno de uma lista nula pode significar algo na lógica da aplicação, diferente de uma coleção vazia. Mas temos que admitir que este tipo de situação é exceção, e não regra.

sábado, 24 de agosto de 2013

A empresa e a qualidade de código - Parte Final

Enfim, usei todo este discurso para chegar ao ponto que gostaria. Um software de qualidade vai além do código-fonte, pois envolve também a satisfação do cliente. E se a empresa busca qualidade em seus softwares, ela vai ter que flexibilizar o processo de desenvolvimento de alguma forma e seus empregados precisam estar dispostos e preparados para isto.

Este tipo de movimento começa desde a fase de proposta do projeto pela equipe comercial da empresa. Os clientes em potencial também precisam entender como é o processo de desenvolvimento de software. Alguns deles, infelizmente, entendem que software é um produto simples que você pergunta quanto é, paga e ele atenderá as suas necessidades ao final. Mas a realidade não é esta. O cliente precisa estar envolvido do começo ao fim do desenvolvimento. Só assim ele terá um produto, na visão dele, com qualidade: regras de negócio contempladas, sem bugs preocupantes, com os ajustes que ele gostaria e com a aprovação do usuário final do produto.

E a empresa pode fazer algo com relação a qualidade do código em si? Claro! Se sua empresa incentiva a busca pela qualidade, já temos meio caminho andado, pois este incentivo abrirá portas para que a equipe faça refatorações no código, use de pair programming e code review, dedique tempo para testes e integração contínua, dentre outras ações voltadas a qualidade que poderiam ser barradas em algumas empresas por pura ignorância.

A empresa pode ir um pouco além e capacitar as pessoas, incentivando membros mais experientes a realizarem palestras e workshops sobre qualidade de software, envolvendo assuntos que iremos tratar aqui no blog.

Bem, chega ao fim esta "série" sobre qualidade. Meu intuito foi demonstrar o envolvimento na qualidade do software pelos diferentes papéis na empresa. Como podem ter notado, gosto de conversar sobre assuntos comportamentais e organizacionais, então creio que vamos ver com alguma frequência este tipo de texto por aqui, mas o foco daqui em diante será código e mais código!

quinta-feira, 6 de junho de 2013

A empresa e a qualidade de código - Parte 1

Depois de falarmos do papel do novato, da equipe, do chefe e do cliente com relação a qualidade de código, vamos falar finalmente do papel da empresa.

Não sou exatamente um empresário do ramo de software, então deem uma aliviada no que vou dizer agora. Pelo que consigo observar nos meus anos de experiência, os principais objetivos de uma empresa de desenvolvimento de software incluem: ver seus clientes utilizarem o software o mais cedo possível, ficarem satisfeitos com o produto entregue, procurarem a empresa novamente para novos projetos e sempre cobrarem um preço justo do cliente, o suficiente para gerar lucro para a empresa.

Para estes 4 objetivos serem alcançados, todos eles passam pela qualidade do software:

  1. utilizarem o software o mais cedo possível: o software precisa estar nas mãos dos usuários do cliente o quanto antes. De preferência, se assim for possível, o software deve estar o quanto antes em ambiente de produção.
  2. satisfeitos com o produto entregue: o software faz exatamente o que o cliente quer. Foi o produto que o cliente imaginou e que foi entregue
  3. procurarem a empresa novamente: o software não só atendeu perfeitamente os anseios do cliente, como o mesmo gostou da experiência e preço da empresa, procurando-a novamente em projetos futuros.
  4. lucro para a empresa: a empresa conseguiu atender a demanda do cliente e conseguiu lucrar conforme o planejado.

Para conquistar estes objetivos, podemos descartar de início algum processo de desenvolvimento "travado", pouco ágil, que comumente encaixa-se no termo "fábrica de  software". Embora processos não-ágeis possam garantir a qualidade do código gerado, são processos muito caros (indo contra o item 4), demorados pela burocracia envolvida que agrega pouco ou nenhum valor (indo contra o item 1) e que tem um risco alto da entrega não atender o que o cliente deseja (indo contra o item 2). No final disto, o item 3 dificilmente pode ser alcançado.

Em geral, uma metodologia ágil acaba sendo a escolha mais natural, pois consegue contemplar melhor os objetivos acima e manter a qualidade do código. Contudo, a empresa precisa permitir que os softwares sejam construídos desta maneira.

É muito comum encontrar empresas com cultura de anos atrás, de "fábrica de software", onde os empregados são chamados de "recursos" e os seus gestores acreditam que este modelo é o único que funciona. Aliás, não só gestores podem ser resistentes a mudanças nesta cultura dentro da empresa, mas também os desenvolvedores, que se acomodaram com o que sabem e não vão em busca de atualizar seus conhecimentos. Este desconhecimento de outras metodologias e tecnologias por estes profissionais são praticamente um reflexo do atraso da empresa na área de desenvolvimento de software.

No próximo texto vou explicar a relação do que foi escrito acima com qualidade, encerrando (finalmente!) a "série"!

terça-feira, 28 de maio de 2013

Seu chefe, o cliente e a qualidade

Na área de desenvolvimento, muitos desenvolvedores são abençoados em ter gerentes que já foram desenvolvedores ou compreendem os processos envolvidos na construção de um software. Mas não raro é possível encontrar chefes que não entendem o trabalho que a equipe de desenvolvimento realiza.

Um desenvolvedor já precisa lidar no dia-a-dia com a pressão do cliente. Este não tem a obrigação de entender nos detalhes como é o processo de desenvolvimento de um software, mas estará sempre de prontidão para pressionar a equipe de desenvolvimento para realizar as entregas de funcionalidade. É comum que esta pressão passe antes pelo gerente da equipe. Se o seu gerente tem consciência de como é o processo de desenvolvimento de um software com qualidade, que exige algumas tarefas "incompreensíveis", como refatoração e testes, ele defenderá a equipe e irá absorver este pressão adequadamente.

Mas se o seu chefe não entende, a equipe ganha mais uma dor-de-cabeça.

Todos sabemos como funciona: "Isto precisa entrar amanhã!", "Precisamos disto para ontem!", "Por que ainda não terminamos?", "é pouca coisa, dá para fazer rapidinho e entregar"...

O recomendado é tentar fazer com que o seu chefe e cliente entendam o trabalho de desenvolvimento. É o desenvolvedor que é o profissional que vai construir o software, e ele deveria saber mais do que ninguém como fazer isto da melhor maneira possível.

Se alguém (gerente ou cliente) pedir a entrada de uma funcionalidade Y para amanhã, converse antes para saber o motivo. Em uma conversa, muitas coisas podem ser reveladas:

  • O seu chefe, ou cliente, não tem total consciência das consequências no sistema do pedido;
  • Deixe claro que as atividades que estão sendo realizadas neste momento serão atrasadas; alguns clientes tem a ilusão que ao pedir mais alguma coisa para determinada data, as que já estão em desenvolvimento não terão qualquer impacto.
  • Enfim, muitas coisas são urgentes quando, depois de uma boa conversa, deixam de ser;

 Se o consenso é que este pedido é importante, e que a data na qual esta funcionalidade precisa entrar não vai encaixar-se no processo adequado de desenvolvimento, deixe claro:

  • A funcionalidade Y será entregue na data prometida, mas no próximo dia um dos desenvolvedores deixará de continuar a trabalhar na funcionalidade X para refatorar o código ruim, escrito às pressas, deixado pela funcionalidade Y.
  • Se a conversa chegou no assunto "horas extras", seja prudente; nenhum ser humano é uma máquina que pode trabalhar por longas horas.

Agindo assim, tanto o seu chefe quanto o cliente não criarão a ilusão que podem realizar qualquer pedido para a equipe sem compartilhar as consequências negativas deste caminho. Até porque, se a equipe de desenvolvimento não corrigir o código ruim deixado, ou tomar qualquer outra ação para preservar a qualidade do software, as consequências serão muito piores para todos no futuro. É importante fazê-los entender que um código ruim hoje, fica pior ainda amanhã. Já dizia o Uncle Bob (Robert Martin):

No matter who. No matter what. No matter when. Short term. Long term. Any term. Writing good code is always faster than writing bad code.

No próximo texto vou falar do papel da empresa. Depois, podemos ir para a parte divertida: o código!

segunda-feira, 20 de maio de 2013

A equipe e a qualidade de código

A equipe é, com toda certeza, a que mais tem responsabilidade e controle sobre a qualidade do código. É a equipe que tem consciência da qualidade geral do código e de técnicas que visam a melhoria ou manutenção da mesma.

Das principais técnicas disponíveis, podemos citar:

  • Pair programming: 2 desenvolvedores trabalham em um mesmo computador. Comumente usado para tarefas mais complexas, também é muito útil para compartilhar conhecimento quando um dos membros do par tem menos experiência que o outro.
  • Code review: seja durante ou ao final do desenvolvimento de uma funcionalidade, um membro da equipe olha o código desenvolvido pelo outro membro. Embora hajam diferentes maneiras de fazer um code review, a que vejo como mais produtiva é quando o desenvolvedor da funcionalidade explica o código para o outro membro. Apenas neste simples processo, é possível enxergar erros e melhorias, que podem vir tanto por parte do autor do código quanto pelo desenvolvedor que faz o papel de revisor.

Muita pessoas citam estas 2 técnicas de desenvolvimento como se fossem opostas. No meu entendimento e experiência, a cada momento uma delas é mais interessante que a outra. Conforme mencionei anteriormente, se a atividade for mais complexa (seja tecnicamente ou pelas regras de negócio), o pair programming mostra sua força, pois atividades complexas abrem margem para um código com grande potencial de bugs e confuso. Com 2 desenvolvedores trabalhando no mesmo código, este risco é atenuado e mais para frente a tendência é economizar tempo, caso este código precise de correções ou evoluções.

O code review funciona bem quando um desenvolvedor com menos experiência termina uma funcionalidade e outro desenvolvedor com mais experiência olha o código. Neste processo, não só erros de lógica e regras de negócio podem ser detectadas, como também ocorre uma transferência de experiência e conhecimento.

Outra coisa interessante do pair programming e do code review, é que temos também um reforço contínuo do que precisa ser feito no desenvolvimento para a qualidade de código ser mantida ou conquistada. Como diria Samuel Johnson:

People need to be reminded more often than they need to be instructed

Voltando ao código, enquanto desenvolvedor, podemos dar o exemplo da checklist, do Code Complete:

  • Are all the inputs to the system specified, including their source, accuracy, range of values, and frequency?
  • Are all the outputs from the system specified, including their destination, accuracy, range of values, frequency, and format?
  • Are all output formats specified for Web pages, reports, and so on?
  • [...]

Enquanto equipe, podemos reforçar outros aspectos, também do Code Complete:

  • Have you defined how much design will be done up front and how much will be done at the keyboard, while the code is being written?
  • Have you defined coding conventions for names, comments, and layout?
  • Have you defined specific coding practices that are implied by the architecture, such as how error conditions will be handled, how security will be addressed, what conventions will be used for class interfaces, what standards will apply to reused code, how much to consider performance while coding, and so on?
  • [...]

Estes são apenas partes de diversas ações que precisam ser consideradas se a equipe realmente está preocupada com qualidade. Irei futuramente detalhar no blog estes e muitos outros aspectos.

segunda-feira, 13 de maio de 2013

O novato e a qualidade de código


Todos já fomos, um dia, um novato de desenvolvimento de software. Isto não é vergonha alguma. É natural, e até esperado, que os novatos cometam mais erros com frequência e encontrem mais dificuldades nas atividades diárias de desenvolvimento.

Muitos deles chegam nas empresas vindo de bons colégios técnicos, já sabendo programar em alguma linguagem, normalmente Java. O porém é que conhecer a linguagem de programação não é garantia que aquela pessoa saiba escrever um bom código. Não estou falando que ela vai precisar de anos para aprender isto também. Existe uma série de ações que poderiam ser feitas para/por esta pessoa recém-chegada na empresa, e que não é feito, que alteraria significativamente a qualidade do código escrito por ela.

Mas o que poderia ser feito? Estava eu outro dia na Amazon, olhando alguns comentários sobre um dos melhores livros de desenvolvimento de software já escritos, o Code Complete, livro este que citarei várias vezes neste blog. Foi quando me deparei com este comentário, e este trecho me chamou a atenção:
The most common criticism one hears about this book is that any decent software developer should already know the material covered in it. Ironically enough, this is true
Em uma tradução livre: "A crítica mais comum ouvida sobre este livro é que qualquer desenvolvedor decente de software deveria já saber do conteúdo coberto pelo livro. Ironicamente, isto é verdade".

Sim, é verdade. Há muito conhecimento que poderia ser facilmente passado para um desenvolvedor em início de carreira sem exigir necessidade de experiência para adquirir este conhecimento. Mas o que ocorre com frequência é que ele começa no projeto sem preparo e, dependendo da dinâmica do desenvolvimento, começa a cometer com frequência diversos erros. As consequências alguns já imaginam:
  • Código de difícil leitura;
  • Nomes ruins para variáveis, métodos, classes, etc;
  • Uso de variáveis globais;
  • "Reinvenção da roda";
  • Necessidade de refatoração posterior;
  • Estresse por parte de alguns membros mais experientes da equipe;
  • Bugs que poderiam ser facilmente evitados;
Boa parte destes problemas seriam evitados se ele tivesse uma boa comunicação com o restante da equipe. Mas estamos falando de alguém com sua primeira experiência de empresa, recém-chegado, querendo mostrar serviço, precisando lidar com outros estagiários "prodígio", com medo de fazer uma pergunta considerada "boba" por ele, recebendo pressão de entrega e até recebendo mais responsabilidade do que deveria... Devemos dar o braço a torcer e reconhecer que vários destes problemas acima citados são de responsabilidade da equipe também.

No próximo post, vou falar da equipe e o seu envolvimento na qualidade de código. Até mais!

quarta-feira, 8 de maio de 2013

Somos amadores chamados de profissionais?

O título é propositalmente provocativo. Embora somos considerados profissionais desenvolvedores de software (analista, engenheiro, etc...), eu observo, dia após dia, como somos ainda amadores no que fazemos.

Vamos, antes, a definição do termo amador (grifo meu):

Amadorismo é o nome dado ao desempenho de uma atividade profissional por pessoas sem conhecimento avançado do assunto e utilizando equipamentos e técnicas não-profissionais.

Se você utiliza-se de algum método ágil de desenvolvimento (Scrum, Kanbam, XP, etc), a equipe de desenvolvimento ganha uma grande (e necessária) liberdade. Liberdade esta essencial para a construção de um software que atenda as necessidades dos usuários, com o risco compartilhado entre o cliente e a empresa de desenvolvimento. Sendo a área de programação uma criança aprendendo a andar, os métodos ágeis já provaram ser o que temos de melhor para construção de um software atualmente.

Só que toda esta liberdade é confundida com libertinagem, e fazemos isto de uma forma inconsciente. Não é porque o desenvolvimento está livre de processos rígidos e desnecessários que devemos abandonar uma mínima organização e preparação.

Deixar de usar ferramentas que:

  • auxiliam no controle das versões;
  • controlam quais funcionalidades foram e estão sendo desenvolvidas;
  • procuram bugs;
  • executam automaticamente os testes;
  • etc;

Ou deixar de lado uma organização que poderia:

  • definir um padrão de nomenclatura para nomes de classes, métodos, ações do sistema;
  • crie um glossário dos termos mais comuns a serem utilizados;
  • centralizar as dúvidas e soluções para problemas comuns de ambiente ou tecnologia;
  • etc;

Estaremos abrindo mão da qualidade, não tenha dúvida. Abordaremos cada um destes itens aqui no blog no futuro.

Você pode estar irritado em eu levantar a possibilidade que fazemos um trabalho amador e nem nos darmos conta disto. Com experiência e maturidade, naturalmente aprendemos muito e passamos por diversas situações. Você, pode não ser amador e saber o tamanho da responsabilidade do seu código dentro do sistema. Mas e o programador novato ao seu lado? O restante da sua equipe? Sua empresa? E o seu chefe?

Nos próximos posts, vou comentar como cada um destes papéis citados anteriormente contribuem com a construção de um software de forma amadora, onde a qualidade certamente ficará aquém da desejada. Assim que terminar esta espécie de panorama da situação que muitas equipes estão com relação a qualidade do software que desenvolvem, partiremos para a parte técnica.

Agora vai!

Olá pessoal!

Bem-vindo a este blog recém inaugurado. Ele é fruto de uma ideia que tenho faz algum tempo, que é de ajudar os desenvolvedores brasileiros a produzirem software com mais qualidade. O foco será em divulgar boas práticas no código (inicialmente em Java, linguagem que mais domino), maneiras de organizar sua equipe para produzir código com qualidade, ferramentas, etc. Tudo muito direto e fácil de digerir, sem enrolação.

Esta motivação de criar um blog para falar de qualidade vem muito bem amparada. Sou desenvolvedor de software voltado para a área web já faz alguns anos e, a cada ano que passa, eu fico mais pasmo de como somos amadores no que nós fazemos e deixamos margem para cometer sempre os mesmos erros.

No próximo post já detalharei porque estou tão espantado na maneira como conduzimos a construção de um software... aguardem!