CAELUM

Como sabemos, a segunda edição do Effective Java foi publicada. O autor é Joshua Bloch, um dos principais responsáveis pelo generics do Java, e atualmente chief java architect no Google. Esse livro é dividido em 78 itens, cada um com cerca de 3 páginas, atacando um ponto específico do java e orientação a objetos, explicando uma boa ou má prática. Simplesmente incrível, durante a leitura você sempre reconhece muita coisa que já aprendeu durante sua experiência de desenvolvimento.

Essa nova edição está estendida e revista, para cobrir as grandes mudanças do Java 5. Esse, juntamente com outros dois livros (e atualmente incluiríamos também o The Mythical Man-month), são de extrema importância para todo desenvolvedor na nossa opinião.

O Fernando Boaglio tem um resumo em seu blog, sobre todos os itens dessa nova versão. A Vanessa Sabino publicou anos atrás um resumo completo sobre a primeira edição, que você pode conferir na coluna da direita do seu blog.

O Fernando também postou no GUJ um link para uma excelente entrevista do Joshua Bloch, onde ele tenta resumir as más práticas, o java inefetivo: otimização prematura, e escrever o próprio código quando bibliotecas boas já existem. Além disso, Joshua Bloch é categório sobre a grande importância dos testes unitários: “Unit testing is key. And writing your tests first is a great thing.”

Lendo essa nova edição e relembrando muito da edição anterior, escolhi aqui quatro itens que considero vitais, e vou falar sucintamente sobre cada um deles. Curiosamente todos os selecionados aqui já existiam na edição anterior, e estão mais relacionados a design que a idiomismos da linguagem, mas isso não tira a importância dos outros aqui não citados. Esses itens são muito debatidos no capítulo de Tópicos em Orientação a Objetos no nosso trienamento de Design e Arquitetura de projetos Java. Vamos a eles:

Item 15: Minimize mutabilidade

Classes imutáveis possuem uma série de vantagens: fáceis de manter, não possuem efeitos colaterais e acima de tudo são thread safe. Uma classe deve ser imutável a não ser que você tenha muito bons motivos para isso. Mesmo se não for possível tornar sua classe imutável, minimize a quantidade de métodos que alteram o estado do objeto. Um objeto previsível é muito mais simples de manter. Joshua Bloch cita String, BigInteger e diz que java.util.Date e java.awt.Point deveriam ter sido criadas imutáveis! Muitas APIs novas abusam da imutabilidade, como a Joda Time, classes wrapper, Money and Time do Eric Evans, etc. Aliás, é com o slogan da imutabilidade que linguagens como clojure e erlang tem chamado tanta atenção. Leia também essa citação no blog do Renato Lucindo.

Item 16: Favoreça composição em vez de herança

Esse é um tópico que já foi discutido anteriormente nesse post. O fato é o seguinte: é muito fácil usar herança de maneira errada, como é o caso de Stack extends Vector e Properties extends Hashtable. Mesmo quando usada corretamente, herança pode causar efeitos colaterais com muita facilidade, sendo que utilizar interfaces e composição pode substitui-la por completo, com o pequeno acréscimo de algumas linhas de delegação. Esse item também é citado no livro Design Patterns como um dos dois princípios básicos do bom design orientado a objetos.

Item 47: Conheça e use as bibliotecas!

Você conhece a ArrayDeque do java 6? Sabia que a java.util.Scanner pode ler facilmente arquivos com formatos caseiros, e já trazer para você doubles, Strings e até mesmo BigDecimals? Que JAXB e JAXWS podem agora ser usados apenas com Java SE? Sabia que a Collections possui hoje métodos para calcular a frequência de um elemento e inverter a ordem de um Comparator?. Conhecer bem a biblioteca padrão do Java pode te salvar de escrever muito código já existente, testado e de qualidade. java.io, java.lang e java.util são APIs que funcionam como base para todo desenvolvedor e merecem um estudo aprofundado.

Item 52: Refira a objetos pelas suas interfaces
Sem dúvida uma boa prática mais que necessária. Através dela conseguimos diminuir muito o acoplamento entre classes, deixando apenas uma fina camada entre elas: as interfaces. Sempre usar InputStream em vez de se acoplar em FileInputStream, sempre usar List em vez de se acoplar a ArrayList. Muitas vezes podemos ir mais longe, nesse último caso Collection pode ser o suficiente, ou até mesmo Iterable! Algumas pessoas levam isso tão a sério que nunca criam uma única classe concreta que não implemente uma interface. Esse item também é citado no livro Design Patterns, e é o outro princípio básico do bom design orientado a objetos desta forma: “Programe voltado a interface, e não a implementação“.

Ainda existem itens fundamentais sobre Enums, Exceptions, Concorrência e Generics. Esse livro é realmente importante na sua cabeceira. Boa leitura!

Muitas pessoas costumam me perguntar se o livro X é bom, se o livro Y cobre bem Java EE, assim por diante. Alguns desses livros são super específicos de uma determinada tecnologia Java, como por exemplo Struts in Action que só aborda a versão 1.x.y do Struts. Em um curto espaço de tempo você vai acabar reciclando as folhas desses livros: ficarão desatualizados.

Na Caelum começamos a debater sobre quais livros importantes havíamos lidos e que ainda eram úteis, e queríamos muito que os outros que participavam da discussão também tivessem lido. A lista estava ficando muito grande quando resolvemos corta-la para apenas 3. Separamos então a trindade do desenvolvedor Java. O critério da escolha foi tentar achar uma intersecção dos livros considerados importantes por nós que todos saíssem satisfeitos. Repare que já são bem velhinhos:

• Refactoring, Martin Fowler

Livro do cientista chefe da ThoughtWorks, a famosa empresa onde nosso amigo Carlos Villela trabalha. Um excelente catálogo das gambiarras (smells, mal cheiro) que acabam aparecendo no seu código e como você pode fazer para conserta-las de maneira sensata. Ok, você já sabia disso. Exemplos clássicos são o uso de herança apenas por preguiça, uso do switch em vez de polimorfismo, entre milhares. Uma pena o código não usar a conveção da Sun e estar lotado de underscores…

• Effective Java, Joshua Bloch

Livro do ex bambambam da Sun (você pode encontrar o nome dele como @author das principais classes do Java SE), agora no Google. Aqui ele mostra como enfrentar os principais problemas e limitações da linguagem. Se você já programa a algum tempo sem dúvida alguma já passou por boa parte dos casos catalogados. Uma excelente leitura, além de simples pois cada caso é relatado em um texto bem curto. Entre os casos interessantes está o uso de factory methods, os problemas da herança e do protected, uso de coleções, objetos imutáveis e serialização.

• Design Patterns, Erich Gamma et al

O clichê dos clichês não poderia estar fora da lista! Livro do atual líder do projeto Eclipse, entre outros. Compre! E ao contrário do que muitos fazem não saia lendo o catálogo dos patterns decorando-os, concentre-se em ler toda a primeira parte onde eles revelam duas regras de ouro da programação orientada a objetos: “Evite herança, prefira composição” e “Programe voltado a interfaces e não à implementação“. Infelizmente perdi minha cópia hard-cover em inglês, faz uma falta imensa na empresa.

Apesar disso, todos eles revelam sinais de sua idade. No Design Patterns, muita gente já considera Singleton como um antipattern (como discutido neste post). Mais ainda, alguns vão além, dizendo que se você precisou utilizar um design pattern, é provável que a sua linguagem não tenha um nível de abstração suficiente para suprir as suas necessidades. Na minha opinião, uma crítica válida.

No Refactoring e no Effective Java, muita coisa já não ocorre mais das formas descritas devido ao Java 5 (em especial com o uso de generics e enumerações), além de que vários códigos podem ser escritos de uma forma mais elegante.

Claro que eu não deixo de ler alguns livros bem técnicos. Os últimos dois que gostei muito foram Lucene in Action e Enterprise Java Beans 5th edition (este último é excelente). Ao contrário dos livros JSF in action e do Core JSF, livros os quais não achei que foram escritos de maneira a prender a atenção do leitor: joga-se muita especificação e conceitos, além de que não há uma ordem de aprendizado, parece mais um guia de referência. Sinceramente, não faz sentido algum explicar todos os passos de uma requisição JSF sem antes mostrar concretamente o objetivo e uso da tecnologia.

Ficaram de fora da lista Programming Pearls, Practices of an Agile Developer, The Pragmatic Programmer, The Practice of Programming entre outros gigantes. E você, tem algum livro que considere imprescindível para os desenvolvedores Java? Tem uma outra formação para a sua trindade?

Ontem fui almoçar com alguns desenvolvedores da Nextel e da 2RP Informática, no Súbito da avenida Paulista (creio que as palavras que mais se ouvem naquele restaurante são Lasagna, Oracle, .NET e Java).

Durante a digestão das massas conversamos sobre os assuntos que estão na boca do desenvolvedor: frameworks, servidores de aplicação antigos, as brigas com o DBA, o super aquecimento do mercado Java e atrasos nos projetos.

A questão girou em torno de adicionar mais pessoas em um projeto que já está atrasado. Lembro-me de anos atrás o Michael ter conversado comigo sobre esse assunto, e só depois vim a ler The Mythical Man-Month, um livro com diversos ensaios sobre engenharia de software e gerenciamento de projetos.

Em um dos principais ensaios, o qual o entitula, Fred Brooks disserta a respeito do mito do homem-hora (em inglês homem-mês, mas aqui no Brasil o termo usual das consultorias é medido em horas, por isso escolhi essa tradução).

Desse livro cunharam a lei de Brooks:

Adicionar desenvolvedores para um software atrasado deixa-o mais atrasado ainda.

Não vou entrar em detalhes, apesar do ensaio ser bem curto, mas o autor critica severamente o hábito de mensurar projetos através da quantidade de homens-horas que este irá levar. Ele começa com um exemplo de um projeto com cronograma de 4 meses e 3 programadores, e que depois de um mês de trabalho, percebe-se que há a necessidade de mais um mês. As opções então são mostradas: atrasar o projeto ou segurar o projeto e colocar mais pessoas (e você vai ficar surpreso de quantas pessoas a mais serão necessárias para isso). Fortemente indicado, o livro já tem 25 anos e há uma edição comemorativa com alguns ensaios reescritos.