Monthly Archives: June 2010

Retrospectiva ~ Agile Brazil 2010

Nos dias 24 e 25 de Junho estive presente no Agile Brazil 2010, a maior conferência de agilidade do Brasil. Gostei bastante do evento, muito bem organizado para um evento tão barato e sem fins lucrativos. Tivemos a presença de várias estrelas internacionais como Martin Fowler, Philippe Kruchten, David Hussman entre outros.

Não vou falar passo-a-passo como foi o evento porque não faz muito sentido já que muita gente estava lá. E quem não estava é só pesquisar no Twitter pela hashtag #agilebrazil.

Achei muito bom o workshop sobre modelagem ágil do Rodrigo Yoshima e do Phillip Calçado. Pelo o que eu vi e entendi, modelagem é tudo aquilo que ajuda a entender um problema, desde uma frase, um desenho ou um fluxograma. É engraçado saber que aquilo eu faço na empresa é modelar, eu não sabia disso.

Quando iniciamos o projeto do Greenbi, estabelecemos uma meta de 3 dias para finalizar. Não havia tempo para criar documentos e muito menos criar diagramas UML ou esboço das telas em HTML. O que fizemos? Pegamos algumas folha A4, algumas canetas e colocamos no papel tudo aquilo que vinha em nossa mente em forma de desenho. Aquele papel serviu de base para todo o projeto. E como disse o Phillip Calçado durante o workshop: “O mais legal desse tipo de modelagem é que, se em algum momento você perceber que fez errado, você simplesmente rasga e joga fora.”.

Durante a palestra do Giovanni Bassi deu para entender de fato a diferença entre ser Ágil e ser Rápido. Acho que essa imagem que o Giovanni colocou no slide diz tudo:

O coiote é rápido,  o papa-léguas é ágil. Preciso explicar algo? :)

Algumas outras palestras e keynotes também chamaram atenção, principalmente a do Fowler falando da importância do Software Design. Além disso, foi apresentado sobre Continous Integration e Deployment, apesar de já ter lido muito sobre o assunto consegui aprender muita coisa.

Não foi um evento onde consegui aprender muitas coisas novas, foi uma oportunidade para lapidar o que já conheço e corrigir algumas definições erradas que eu tinha. Em geral, nota 10, espero poder ir no Agile Brazil 2011. Aliás, tem a presença confirmado do Ken Schwaber.

http://en.wikipedia.org/wiki/Ken_Schwaber

Evitando o excesso de ‘null check’

Que atire uma pedra aquele que ainda não está cansado de ver/escrever código assim:

public Departamento insere(Integer codigo, String descricao) {
    if (descricao == null) || (descricao.equals("")) {
        //faz alguma coisa
    }
}

Poxa, é impossível. Cada desenvolvedor deve escrever isso no mínimo umas 10 vezes por dia. Se você faz isso todo dia, acha um saco e nunca achou uma maneira para resolver esse ‘problema’, eis a solução:

public Departamento insere(Integer codigo, String descricao) {
    //faz alguma coisa
}

Simples não? Problema resolvido.

A documentação deve deixar bem claro que este método não aceita nulo ou vazio no parâmetro ‘descricao’.

NOOOOOOOO! Null Pointer Exception.

NOOOOOOOO! Null Pointer Exception.

Se este método for interno à sua aplicação, fica fácil, você sabe que as classes que irão chamar este método precisam estar escritas de tal maneira que não passe nenhum valor nulo ou vazio, caso contrário, haverá algumas excessões não esperadas.
Se você prestar atenção, ao remover essas verificações de toda a hierarquia de classes, as únicas classes que realmente irão precisar da verificação são as classes que interajem com a interface do usuário.

Agora se seu método estiver exposto em um WebService, isso significa que outros desenvolvedores poderão chamar este método e você não tem controle sobre o que estes desenvolvedores irão passar para o método. Neste caso, ainda assim, deixe o método sem as verificações e faça-as nas interfaces do WebService. Crie pré-condições para seus serviços, deixe claro que o parâmetro descrição deve conter algum valor. Se a condição estiver válida, você pode chamar o método tendo a garantia de que não haverá excessões.

É comum que quando nos deparamos com um erro de NullReferenceException (C#) ou NullPointerException (Java) no log da aplicação, a primeira coisa que fazemos é ir direto na linha que deu erro e adicionar a verificação se é nula apenas para que não ocorra tais erros. Se um valor nulo chegou até ali é porque ele deveria ter parado em algum lugar antes, geralmente na camada entre a interface do cliente e o código de negócio.

Lembre-se do princípio da responsabilidade exclusiva! Não é responsabilidade do método ‘insere’ garantir que os parâmetros estejam válidos.

Além deste caso onde você pode ter problemas com parâmetros nulo, existem lugares em que você faz a verificação de nulo com o retorno de um método, ficando mais ou menos assim:

Departamento depto = dao.insere(1, "Compras");
if (depto != null) {
    //Faz algo
}

E nesses caso, como se comportar? Isso vai ficar para o próximo post, lá eu falo sobre isso e um pattern relacionado, chamado de Null Object Pattern. Até mais!

Edit #1: O post sobre Null Object Pattern é este aqui.

Sharing Buttons by Linksku