Falando em Java 2009

Apesar de ainda não ter chegado a confirmação de inscrição, conversei, no início da semana, com a Amanda, atendente da Caelum do RJ, e minha inscrição foi confirmada. A propósito, tenho que elogiar o ótimo atendimento prestado por ela.

O evento será realizado no dia 24/05/2009 no espaço Hakka, em São Paulo.

Minhas expectativas são as melhores possíveis, pois conheço a reputação dos palestrantes nacionais e o renome dos internacionais.

Veja a programação aqui.

Estou ansioso para assistir a palestra das 10h40m (O profissional Java Efetivo - Paulo Silveira e Rafael Cosentino) e das 14h30m (Arquitetura para aplicações Java de médio porte - Guilherme Moreira e Sergio Lopes). Em seguida, no meu medidor de interesse, vem a palestra das 16hs (Para onde vai a Plataforma Java? Linguages dinâmicas, JavaTV, JavaFX e além! - Anderson Leite e Fabio Kung).

Acredito que o evento será muito proveitoso.

Colocarei aqui como foi, sob meu ponto de vista, na semana seguinte ao dia 24/05.

Quem realiza o evento é a Caelum, empresa referência em treinamento em TI no Brasil.

Qualidade na prática - I

Vou iniciar a série prática com um exemplo que está presente na vida de 10 entre 10 desenvolvedores: as estruturas condicionais. Esse exemplo é sobre a estrutura IF. Os códigos estão na linguagem Java.

Vemos if's o tempo todo na nossa vida. Atravessaremos a rua, se o sinal estiver fechado ou não vier carro. O mais interessante é que, normalmente, este teste, está vinculado à uma ação. Sendo assim, definiremos estratégias para as tomadas de decisão. Entretanto, não falarei em termos de OO ainda. Vou mostrar como, proceduralmente, é fácil programar uma estrutura IF mais clara, facilitando a sua vida e de quem vai manter o código.

Os IFs do nosso dia-a-dia estão encapsulados. Quando chegamos na beira de uma rua, não pensamos ou falamos em voz alta: Só vou atravessar quando o sinal fechar ou não vier carros.

Segue um exemplo clássico, ao qual todos os membros da equipe devem ter atenção, e não é nenhuma obra de gênio.

O código inicial, com o desenvolvedor pensando apenas na correção e na robustez:



Abaixo, modularizei as lógicas de teste, melhorando a clareza, facilitando a manutenção. Notem que os comentários desapareceram, pois o código é auto explicativo:


Na próxima fase, eliminei os números mágicos:


A melhora na legibilidade é clara. Possibilitamos, também, o reúso, pois, se algum outro algorítmo precisar testar status, não precisaremos reescrever a lógica. Dessa forma, evitamos a duplicação de código, que muito mal faz para a saúde do desenvolvedor.

Mesmo sem nos preocuparmos com a OO, percebemos, claramente, os benefícios de um código bem escrito. Para desenvolver dessa forma não precisamos ser nenhum doutor de Havard ou consumir muitas horas do projeto.

Esta refatoração mostra a questão do ganho de habilidade com a prática. Será muito difícil codificarmos como na fase 1 novamente, já que este tipo de boa prática é muito fácil implementar de primeira. O que está relacionado ao uso insistente do primeiro código pelos desenvolvedores é a falta da inquietação com os maus cheiros que afloram de sua obra.

Concluindo, esta refatoração não exige horas a mais de projeto, somente vontade do desenvolvedor em sempre codificar melhor.

O livro Refactoring: Improving the Design of Existing Code do Martin Fowler, contribui sobremaneira para este tipo de pensamento no momento de codificar.

O que é qualidade de software? - Introdução

Esta é a pergunta que não quer calar: O que é qualidade de software?

Eric Braude, em Software Design: From Programming to Architecture, definiu que os princípios de um projeto de software são: correção, robustez, flexibilidade, reusabilidade, eficiência, usabilidade e confiabilidade. Acrescento também a legibilidade, pois como diz Martin Fowler:

Any fool can write code that a computer can understand... But only good programmers write code that humans can understand

Em alguns casos, precisamos degradar um dos princípios em prol de outro, como por exemplo a eficiência pela reusabilidade. Mas correção e robustez são princípios básicos, sendo assim, obrigatórios.

A qualidade do código está diretamente ligada a todos estes princípios. Devem estar presentes na cabeça do desenvolvedor desde a primeira linha escrita, desde a modelagem da primeira classe. Tornar realidade nos primeiros esboços, seria o mundo perfeito. Mas não somos máquinas. Entretanto, isso não exime o desenvolvedor de estar com esses princípios em mente desde o nascimento dos primeiros requisitos.

Normalmente, desenvolvemos pensando apenas na correção e na robustez, preocupados em atender os requisitos e na confiabilidade da aplicação. Nesse momento entra a refatoração e, com ela, o ganho de experiência nas boas práticas. Refatoramos a arquitetura, movemos e criamos atributos e métodos, aplicamos padrões de projeto. Ao ficar inquieto com o que acabei de criar, quero aprender uma forma mais elegante de implementar aquela solução.

Gosto de comparar o desenvolvedor a um artista. Devemos ter tempo para olhar a obra e corrigir as imperfeições. E, infelizmente, tempo é uma peça chave nos processos de negócio. Não podemos menosprezar o problema de prazo do cliente.

Esta questão será peça chave também no blog e espero conseguir mostrar que com um tempo a mais para pensar nas melhores práticas, o cliente ganhará muito mais com o software em produção.

O impacto na implementação

A implementação é a transformação efetiva dos requisitos em código. Assim, esta fase decidirá a sua vida no futuro. Se precisará de dias (noites, fins de semana) para implementar/modificar um requisito. Se a sua vida será um inferno e o desenvolvimento um castigo, ou se você terá uma vida normal e o desenvolvimento será um prazer. Investir algumas horas procurando a melhor solução, pode fazer toda diferença na sua qualidade de vida. Este artigo desenvolve muito bem este assunto.

Acredito que mesmo os profissionais gurus da qualidade de código, identifiquem, vez ou outra, em suas soluções, algoritmos que podem ser melhorados. Dessa forma, a refatoração deve ser companheira de todo desenvolvedor que busque a excelência de suas soluções. O livro Refactoring: Improving the Design of Existing Code será referenciado constantemente nesse blog.

Quanto mais você se preocupa com a qualidade, mais natural ela se torna. Se produzimos um código e concluimos que é de baixa qualidade, devemos tentar a refatoração. O mesmo se dá quando estamos trabalhando com código legado. Este feeling é chamado de "detecção de mau cheiro" por Fowler. Da próxima vez que nos depararmos com a necessidade de um(a) algoritmo/arquitetura parecido(a), lembraremos da melhor prática que foi aplicada anteriormente e o código já terá uma certa qualidade de primeira. Depois de certo tempo, nem acreditaremos que desenvolvíamos aquele algoritmo daquela forma.

A solução refatorada pode ainda não ser uma excelência em qualidade, mas um passo já foi dado. Da próxima vez, refinaremos um pouco mais. Dessa forma, nossas soluções tendem a qualidade total. É uma busca infinita pela excelência. Este é um dos pontos que torna a nossa profissão tão interessante, na minha opnião.

Não ficarei apenas discutindo os princípios da qualidade, o porque ou outras teorias. Será criada uma série Qualidade na Prática, onde vou mostrar exemplos, no estilo passo a passo, de refatorações que fiz em códigos meus e de outros desenvolvedores.

Existe um tópico no GUJ, do Daniel Destro, bem interessante, pois mostra o que não se deve fazer em uma solução Java. Este tópico é mais antigo que o meu registro, é constantemente atualizado e é um dos campeões de visitas do fórum.

Sei que o dito "mundo perfeito" é uma utopia. Mas busca-lo deve ser uma atividade diária.

A importância da manutenção

Vejo a manutenção e a implementação como as fases do processo de software mais afetadas pela questão da qualidade. Isso é bem óbvio.

Primeiramente, vou falar da manutenção que, dependendo do tempo de vida da aplicação, é a fase mais longa do processo.

Manutenção, resumidamente, é qualquer procedimento que leve a alteração do código, durante a implementação e após a release final.

O negócio do cliente muda constantemente. O sistema precisa acompanhar este dinamismo. Requisitos nascem, mudam e morrem a todo instante. A aplicação deve se adaptar. Complexidade de implementação vai depender da complexidade do requisito, dessa forma, é relativa. Mas a questão é: seu código não deveria ser uma pedra no caminho.

Já precisei reconstruir uma aplicação inteira, pois ficou impossível adicionar mais requisitos. Era um monstro quase monolítico, em Delphi 6. As units eram enormes e toda a regra de negócio era programada nos eventos. TODA!

Era o tipo de aplicação que se mudasse ou acrescentasse uma vírgula acontecia um desastre. Usando uma expressão do Page-Jones neste livro, era Conascença de Aplicação. Pelo menos o desenvolvedor criou um tipo de conascença.

Expliquei a situação para o dono da empresa que sabia se tratar de uma aplicação crítica. Depois de algumas negociações de prazo, iniciamos o projeto.

Esta situação foi razoavelmente fácil de contornar, pois não havia ninguém (líder, gerente) entre o desenvolvedor e os responsáveis pelo negócio. Compreenderam que a reconstrução era o melhor para o negócio, investiram nela por alguns meses e ainda estão colhendo os frutos. Este fato ocorreu no final de 2005 e a aplicação funciona até hoje, sendo mantida por outra pessoa desde o fim de 2007.

Nem sempre a solução é simples, pois, normalmente, existem pessoas entre o cliente e o desenvolvedor que, muitas vezes, têm interesses que os impedem de pensar na qualidade. O crédito desse parágrafo vai para um diálogo que acabei de ter com Paulo Cereigido, companheiro de embarcação. É um assunto que será abordado em um post futuro.

O ponto é: ficar resmungando com os botões, reclamando do cliente, não resolve nada. Só trará desgostos e mágoa com a profissão. Precisamos fazer algo para mudar esse tipo de mentalidade nociva e imediatista. E é basicamente essa a pretensão deste blog. Buscar caminhos para implantação definitiva da qualidade.

EDIT: Quero deixar claro duas coisas:

1. Estou considerando desenvolvimento = análise + programação + teste unitário;
   
2. Quando falo em qualidade, falo em qualidade de código.
   

Por que pensar em qualidade?

Hoje realizo um antigo projeto. A criação de um blog de tecnologia. Meu primeiro post vai com uma pequena história.

Em dezembro de 1985, quando tinha 8 anos de idade, meu pai me presenteou com um TK2000 II Color. Este computador vinha com dois livros: um fino, com informações técnicas da máquina e outro, mais grosso, com uma excelente explicação sobre a linguagem Basic. Em meados de janeiro de 1986, passadas as primeiras impressões sobre o “ET” que eu tinha ganhado, arrisquei as primeiras linhas de código, por influência de meu pai, que nunca foi desenvolvedor por profissão, “apenas” curioso.

Não demorou muito para a minha irritação aparecer com os inúmeros “goto's” espalhados pelo código. Era quase impossível debugar o monstro monolítico. A vida era um inferno, mas tomei gosto pela coisa. Assim, comecei a me preocupar, intuitivamente, com a qualidade do que estava fazendo, tentando diminuir ao máximo a quantidade dos malditos goto's.

Estudei o dBase III Plus com seu mod com, quando conheci o Clipper Summer'87 (que criava um “exe” para fazer o que o dBase III fazia), como sempre, através do meu pai.

Em 1993 e 1994 trabalhava dando aulas de Windows 3.1 e DOS para iniciantes.

De 1995 a 1999, trabalhando com manutenção de computadores, me afastei do desenvolvimento.

Em 1999, fiz um curso de Delphi 4 com Oracle. Trabalhava com manutenção, mas sempre tentava “forçar” um sistema.

Em 2000 fiz o MCSE+I e trabalhei com redes e manutenção até 2004.

Em 2004, fui mais uma vez contratado para atuar em manutenção. Meu superior ficou sabendo que eu estava desenvolvendo uma ferramenta para controle de OS. Era o momento que a empresa estava querendo contratar um programador Delphi OO.... acontece que eu não sabia nada de OO. Programava toda lógica em procedures e functions e muita coisa nos eventos. Era arrumado, mas era feio. Engoli o livro Delphi 6 OO e consegui a vaga.

Em maio de 2005 fui alocado em um cliente que trabalha com GPS e entrei no Mundo Java de cabeça. A partir desta data, comecei a engatinhar nos conhecimentos que melhoram a qualidade do código.

Em maio de 2006 fui contratado por esse cliente por indicação do meu empregador.

Em novembro de 2007 sai da empresa e fui contratado por uma consultoria que desenvolvia em Delphi. Tentei “forçar” um desenvolvimento OO, inclusive com o conceito de DAO e outros padrões que aprendi com o Java e fui demitido em abril de 2008.

Desde junho de 2008 atuo na mesma consultoria.

Sempre me preocupei com a qualidade. Mas foi só em 2005, quando comecei a estudar o Java, que comecei a adquirir os conhecimentos que ajudam a produzir um código com qualidade.

Como sempre fiz, ataquei de livro e artigo para todos os lados, tentando identificar o fio da meada. Foi quando conheci o GUJ, em 2006. As pessoas do fórum me pegaram pela mão e mostraram o caminho.

Proponho aqui um espaço para colocar as minhas experiências e conversar um pouco sobre esse assunto tão importante para desenvolvedores, consultorias e clientes – Qualidade de Software.