Alberto Leal

Estava desenvolvendo um projeto web utilizando a linguagem PHP. O mesmo encontrava-se bem avançado. Foi então que, no início da semana passada resolvi parar e re-começar o projeto.

Alguns devem estar me chamando de louco! “Como o cara resolve re-começar um projeto  e vai jogar na lata do lixo o que já foi feito?! Esse cara é louco!”.

Eu tenho uma explicação para isso: Primeiramente, trata-se de um projeto particular, o que “não requer” $ de investimento no início. E, relativamente, grande. No início do projeto foi decidido usar um framework - que eu nunca havia usado. Tempo vai, tempo vem e começaram a aparecer algumas dúvidas na utilização do framework. Busquei suporte e não encontrava muita coisa na internet, já que se tratava de uma ferramenta “nova” (nem na versão 1.0 estava) e consequentemente, apareceram alguns POG’s (arghhhh). Sem contar que o framework era lento demais.

Semana passada, no meu “enorme” apartamento, comecei a pensar no bendito projeto( O que irá me render milhões de dólares [rs] ) e decidi refatorar o modelo que tinha em mãos e re-começar o projeto em Java.

Começaram as pesquisas por um framework web MVC. E o escolhido foi……MENTAWAI!

Para persistência, estou utilizando o Hibernate com Annotations..

Hoje o projeto ainda não tem nem 10% do que tinha antes, mas posso garantir que está bem mais estruturado. Os beans já estão mapeados e já tem até alguns CRUD’s [rs]

Aqueles que estão pensando em qual framework MVC utilizar na web, deêm uma olhada no mentawai, é uma ótima ferramenta e o suporte da comunidade é muito bom!!

Como no post anterior eu citei o Annotations do hibernate, pensei em falar um pouco sobre o assunto e, posteriormente, mapear uma aplicação de exemplo.

– –

Afinal, o que é hibernate? Para que serve? Tenho mesmo que aprender mais um framework Java? …

São tantas as perguntas para quem está iniciando em Java, aliás, não somente para os iniciantes. Basta tomar conhecimento de uma nova ferramenta que tem como propósito aumentar a produtividade no desenvolvimento que dúvidas e mais dúvidas parecem “pipocar” na mente.

O Hibernate é um framework de persistência objeto relacional para aplicações Java. Ele faz o mapeamento das classes java para tabelas no banco de dados relacional (por exemplo: mysql, DB2, postgres..). Além de fornecer total liberdade e suporte para programar as classes seguindo as características do paradigma OO ( associação, polimorfismo, herança, coleções..).

O framework não serve apenas para fazer o MOR - Mapeamento Objeto Relacional. Todas as operações que envolvem banco de dados (CRUD, Select) podem ser feitas de forma transparente pelo hibernate.

E onde é que entram os “Annotations ” ?..

Annotations são metadados que aparecem no código fonte e que são ignorados pelo compilador. Este recurso somente foi adicionado na versão Java SE 5.0 e sua utilização agrega significados especiais ao código fonte.

Atualmente, hibernate é um dos frameworks de persistência Java mais utilizados no mercado. Mas, não é o único e você não é obrigado a utilizá-lo se não gostar/desejar.

Durante alguns anos trabalhando com desenvolvimento, tenho observado que enquanto alguns desenvolvedores amam outros, literalmente, odeiam trabalhar com arquivos XML.

Não sou ‘tão extremista’ assim. Tá certo que XML não é uma das 7 maravilhas do mundo, mas acredito que existem casos e casos para se utilizar. Aqueles que odeiam alegam que ele é feio, lento e, às vezes, chato de se escrever.

Realmente, existem situações em que sua utilização deixa o parser lento. Vamos pensar no seguinte ambiente: Quando estamos trabalhando com o hibernate e temos um número elevado de tabelas mapeadas em arquivos xml o tempo de carga dele é maior do que se fosse utilizado annotations. Tá certo que esse tempo de “espera” é apenas na primeira execução do sistema. Eu sei. Apenas citei este exemplo que me veio a cabeça. ([OFF] Aproveitando o exemplo: O que você acha mais rápido: parsear um arquivo XML ou fazer reflection para acessar as annotations? Particularmente, prefiro mapear minhas classes com annotations )

XML, use com moderação e nos lugares certos!

Preparem a pipoca!!

É com muita satisfação que apresento à vocês o primeiro screencast do Blog.

Este é o primeiro de muitos. A idéia é publicar uma série de vídeos com dicas sobre desenvolvimento de software.

Para iniciar a nossa série de screencast, apresento-lhes o primeiro: “Refatoração na Prática”, onde mostro como aplicar técnicas de refactoring com o auxíio de uma IDE.

PS: Não pensava que daria tanto trabalho. Para quem nunca mexeu com edição de vídeo até que está muito bom. Por isso, peço que aliviem o meu lado nos primeiros vídeos.. =D

Espero que gostem…

Link no YouTube: http://www.youtube.com/watch?v=WPF6qriM8wo

Link para Download: http://www.albertoleal.eti.br/Screencast/ScreenCast-Refatoracao_na_Pratica.avi

Vamos ver uma definição de “teste”.

Dicionário:

“acto ou efeito de verificar ou provar alguma coisa (equipamento, sistema), sob certas condições, para verificar e avaliar a sua qualidade, natureza ou comportamento. “

Na nossa área, quando testamos algo ( funcionalmente,unitariamente..) queremos garantir que dada uma entrada o resultado seja uma saída esperada.

Testar um sistema de software não é simplesmente sentar na frente do computador e iniciar um processo exaustivo de entrada de informações e aguardar a sua resposta. Existem diversas maneiras de se testar um software - estrutrados, OO… A melhor forma de se testar uma aplicação é elaborando um conjunto de testes e automatizando-o. Existem enumeras ferramentas que nos auxiliam na criação de testes (jUnit, por exemplo), o que torna mais simples utilizar os testes como um artefato de apoio na construção de sistemas de software.

Até mesmo para elaborar testes, deve haver um planejamento (menor valor absoluto, maior valor absoluto, métricas..). Para isso existem técnicas, como por exemplo:

• Teste Caixa Branca;
• Teste Caixa Preta;
• Teste Funcional;
• Teste de Confiabilidade;
• etc…

Teste bem elaborados podem preservar a semântica do programa. Alguns desenvolvedores pregam que os testes devam ser planejados antes mesmo que uma linha de código tenha sido implementada. Dessa forma, o desenvolvedor se questiona sobre a necessidade de se alterar alguma coisa no requisito.

O artefato “TESTES” de um projeto não tem como objetivo único e exclusivamente verificar se uma funcionalidade retorna uma saída esperada. Quando estamos planejando um conjunto sólido de testes, estamos verificando se todos os requisitos foram atendidos, se o objetivo da aplicação está claro para todos os envolvidos, ou seja, além de se testar um software, a organização do projeto estará sendo sempre validada e confirmada.

Dando continuidade ao post anterior, veremos: bad smells, vantagens/desvantagens da utilização de refatoração ..

Read the rest of this entry »

Foi durante a graduação que eu tive o primeiro contato com “Refactoring”. Este seria o tema do meu projeto de conclusão de curso(TCC). Então, comprei o livro do Martin Fowler e comecei a estudá-lo e escrever sobre o assunto. Tentarei falar um pouco sobre o assunto.

Caso o seu interesse seja aprofundar no assunto, aconselho a ler o livro citado acima. Agora, se você não tem idéia, ou tem vaga noção sobre o que é refatoração, onde e como aplicá-la, seria legal acompanhar os próximos posts..

É de praxe que desenvolvedores de sistema possuam a necessidade de fazer alterações em projetos que em andamento. Em muitos casos, essas alterações são realizadas sem qualquer formalismo, elevando, assim, o índice de complexidade do código-fonte do sistema. Código complexo, difícil de ser compreendido e modificado pode levar um projeto de software ao fracasso. Alterações mal executadas podem mudar totalmente o comportamento inicial de um sistema.

Neste contexto, a refatoração auxilia no aperfeiçoamento do código-fonte minimizando as chances de novas falhas serem introduzidas no projeto.

As técnicas de refatoração, quando utilizadas corretamente, aumentam consideravelmente o tempo de vida útil do software.

Seguindo como referência o livro do Fowler(2004), temos a seguinte definição:

“A refatoração é um processo de alteração de código-fonte de um sistema de software de modo que o comportamento observável não mude, mas que sua estrutura interna seja aperfeiçoada. Em essência, quando se usa esse processo, tende-se a melhorar o código-fonte, mesmo após este já ter sido escrito.”

Você deve está se perguntando, “Mas, como eu vou ter certeza de que todo o meu sistema continuará funcionando perfeitamente, isto é, como garantir a integridade do comportamento observável do software?”. A resposta para a sua pergunta é: “Testes”.

Quando falo “Testes” não me refiro pedir ao estagiário que teste todo o software e veja se encontra algum comportamento estranho - após a refatoração, estou falando de “Testes Automatizados”.

Imagine se a cada técnica aplicada você tivesse que aguardar uma resposta do estagiário: “Ok Programador, pode continuar com suas refatorações”. Seu SW não ficaria pronto tão cedo!

A pré-condição essencial parar refatorar é a existência de testes sólidos!!! E, programadores profissionais escrevem testes!

No próximo post falaremos sobre “Bad Smells”, vantagens e desvantagens da refatoração, e, aplicaremos alguns técnicas com o auxílio de uma IDE (Eclipse).

Leia também: Improve It

É impressionante!!

A cada dia que passa, eu vejo que existem, no mercado, mais e mais ferramentas que se propõem a desenvolver códigos de qualidade para nós - programadores. Há um tempo atrás, ocorreu uma thread no GUJ - não consegui encontrá-la, postarei se encontrar - onde se discutia que dentro de alguns anos os próprios clientes estariam criando suas próprias soluções. Isso, devido ao avanço das milagrosas ferramentas que escrevem códigos de qualidade, apenas com meia dúzia de cliques.

Tá bom. Pode até ser que algumas dessas ferramentas escrevam códigos de qualidade, mas, agora, será que escrevem um sw inteiro com qualidade? Será que essas ferramentas estão preparadas para receber um documento de requisitos, por exemplo, e destrinchá-lo, de modo que ao final o resultado seja SOFTWARE de QUALIDADE?

O papel fundamental das ferramentas é auxiliar o programador no desenvolvimento de uma aplicação, e não desenvolver a aplicação toda por si só, ainda mais através de poucos cliques. Desenvolver sw não é meramente escrever linhas de códigos - querendo ou não, existem muitas etapas antes de se chegar ao ponto de “vamos colocar a mão na massa”. E, não me refiro apenas a parte de análise de negócio. O que falar sobre performance e escalabilidade?!

Acredito sim, que as ferramentas estão ficando cada vez mais sofisticadas e auxiliando, cada vez mais, aos desenvolvedores.

Agora, quando chegar o dia em que um IDE interpretar todo um documento de requisitos, diagramas e afins, e no final sair SW DE QUALIDADE, temos que procurar outra profissão.