TDC 2013 - Navegando em um mar de novidades

Boa noite.
Hoje tive a oportunidade de participar do meu primeiro The Developers Conference (TDC) que ocorreu aqui em Florianópolis, onde participei de uma trilha de Java (Java University).
Durante todo o dia, vários palestrantes falaram sobre Java, novidades, tendências, enfim, foi um evento muito bacana e que com certeza participarei novamente. Pena que pude ir somente em um dos três dias, mas já foi excelente a experiência.
A primeira palestra foi sensacional. Tratava sobre as siglas do mundo Java. A primeira impressão que tive é que essa palestra iria ser muito básica. Mas foi sensacional! O palestrante conseguiu explicar de uma maneira muito interessante como todas as siglas interagem entre si. Uma das coisas que marcou foi que não é preciso conhecer TODAS as tecnologias envolvidas. É interessante que muitas tecnologias tratam de uma mesma coisa, e que uma é apenas uma variação da outra, de forma melhorada. Por exemplo, JDBC, JPA e Hibernate estão relacionados a persistência. JSP, JSF referem-se a camada WEB. Servlets e Struts também entram na parte WEB mas como controladores. Temos também o EJB (separar a lógica de negócio com camada de estrutura), Tomcat (servidor web), JBoss (servidor de aplicação - entende EJB). Após explicar tudo isso de maneira bem sucinta, falou-se um pouco sobre arquitetura, com exemplos práticos.
A segunda palestra tratou de desenvolvimento de jogos em uma plataforma chamada Greenfoot. Ele utiliza a mesma IDE que o BlueJ, e o Framework é quase Java! Fiquei impressionado com a facilidade de programar jogos divertidos com essa ferramenta, além de ser uma plataforma muito interessante para quem quer aprender Java brincando! Depois de um "almoço" (sim, deu tempo de comer um Subway patrocinado pelo evento), uma das palestras mais bacanas do dia foi uma espécie de "História do Java". Contamos com a ilustre presença de Bruno Souza (o Javaman). Poxa, e que palestra! Foi muito interessante. Nesse meio tempo tivemos também as novidades do Java 8. Uma coisa que chamou a atenção em um dos novos recursos foi a possibilidade de implementação de um método "default" em interfaces Java. Poxa, isso foi sensacional, porque se quisermos sobrescrever o método padrão, tudo bem, se não, ele irá se comportar da maneira "default". Gostei muito desse recurso. Gostei também do assunto sobre Lambda. Tenho que aprender isso inclusive, achei interessante no pouco que vi, mas parece ser bem complexo. Por fim, um pouco (mas pouco mesmo) sobre refatoração e um bate papo legal.
Vamos em frente, e até o próximo TDC Floripa! :)

Refatorar é preciso!

Quantas vezes olhamos para nossos projetos, torcendo o nariz e falando aos quatro ventos "hoje eu faria tudo diferente"? Pois é. Para quem se preocupa com a arquitetura de seus projetos, além da funcionalidade em si, esse parece ser o calcanhar de Aquiles de muitas aplicações que encontramos hoje. Muitos sistemas legados com alta complexidade necessitam de uma atenção especial na refatoração. Porém, tudo na vida tem um limite, e aqui este limite chama-se bom senso. A refatoração muitas vezes é (mal) interpretada como "jogar tudo fora e começar novamente". Nós que trabalhamos com codificações intensas sabemos que isso é inviável. Então, o que fazer, como começar?
Abaixo cito algumas dicas de quais pontos você pode identificar em seu projeto em que poderá fazer uma refatoração:

1) Identifique as fraquezas de seu projeto.
Você sabe. Sempre tem aquele módulo do sistema que não gostamos nem de abrir o fonte, por "medo" de alterar alguma coisa e tudo parar de funcionar de uma hora para outra. Se isso está acontecendo em seu projeto, é um claro sinal de que este módulo foi mal projetado. As alterações não deveriam causar tanto estardalhaço no que já está funcionando, e esse "medo" não deveria existir. Procure separar as partes críticas deste módulo em camada e torne-as coesas. Isso simplifica as coisas. Faça com que cada módulo tenha sua responsabilidade específica e nada mais. Claro, se você está em um ambiente OO isso fica muito mais transparente, mas é possível sim aplicar a mesma coesão e baixo acoplamento em outros tipos de estruturas (funções, procedures, etc).

2) Pense no futuro.
Ok. Aí você vai me dizer que NUNCA esse módulo/funcionalidade vai ser usada em outra situação, que é um problema muito específico. Aí no mês seguinte alguém pede uma coisa muito parecida, com algumas alterações apenas. Já que estamos refatorando nossa aplicação, por que não torná-la um pouco mais "genérica" e menos inútil? Você sabe qual é a única constante no desenvolvimento de Software? Se respondeu ALTERAÇÃO, está no bom caminho. Muitas vezes isso exige mais escrita de código. Mas pense em você, que no futuro não vai querer ter que decifrar o que esse maldito código está fazendo.

3) Faça o uso de boas práticas de programação.
No seu módulo legado você tem variáveis com nomes totalmente insignificantes, como "x" e "y", ou "percentual". Não custa seguirmos as boas práticas de programação. Leia os padrões de projeto que gurus resolveram utilizando a mesma linguagem que você utiliza. É muito recompensador você ler um código depois e ver que ele está organizado e limpo, e que outras pessoas conseguirão compreender com facilidade.

4) O fim.
 Você saberá a hora certa de virar a página. Não tente refatorar o projeto para que se torne "o sistema perfeito". Como já dito, tenha bom senso. A hora que o sistema estiver estável e que novas alterações que possam vir a surgir no futuro não sejam uma terrível dor de cabeça, você está pronto para de uma vez por todas colocar um ponto final, e a partir disso só manter.

Enfim, há com certeza mais de quatro dicas para incentivá-lo a refatorar, mas por hora isso já basta. Lembre-se, quanto menos seu projeto for frágil, mais feliz você será e menos retrabalho terá. Consequentemente, poderá alocar mais tempo em outros projetos.

Por hoje é só, um abraço.