[OFF-SERIES] Opinião sobre o livro do Braude

Uma das coisas mais sensacionais de estar mantendo um blog, é a possibilidade constante de reciclagem de conhecimento. Quem não quer escrever muita besteira, vai dar uma olhada, inclusive, em obras que já leu.

Isso aconteceu no dia 05/05/2009, quando me preparava para escrever a primeira parte dos princípios de projeto de software, com o livro Software Design: From Programming to Architecture do Eric J. Braude. Quando reli a parte que fala sobre correção e robustez, encontrei tantas falhas que não acredito que não tenha visto na época da leitura.

Após uma breve reflexão, percebi dois motivos:

1. Na época que li a obra, não tinha lido nem um terço dos artigos que li até hoje, isto é, meu conhecimento era mais limitado;
2. Este livro, foi a primeira obra que li sobre engenharia de software. Fiz uma analogia interessante: Quando visitamos um belo lugar pela primeira vez, não percebemos todos os detalhes do local. Na segunda vez que vamos, percebemos mais detalhes. Na terceira, já percebemos os buracos na rua, os prédios que eram históricos passam a ser velhos, etc. Dessa forma, não percebi alguns erros sutis na obra do Braude. Erros esses que me frustaram bastante.

O primeiro erro que considerei relevante foi que Braude, no título que aborda os princípios de correção e robustez, cita a legibilidade, mas nada escreve no desenvolvimento do tópico.

Outro erro, foi ele mencionar na introdução dos princípios citados no parágrafo anterior que existe uma sutil diferença entre correção e suficiência, dizendo que mostraria mais a frente, mas isso não acontece.

Outra falha foi mencionar a refatoração para a correção. Se não atendermos a correção (cumprimento dos requisitos), não teremos aplicação. Se um determinado módulo não atende o requisito para o qual ele foi (está sendo) construído, não teremos uma refatoração, mas continuaremos a construção. Estranho perceber como ele não desenvolve o assunto no corpo do tópico.

Eu sei... eu sei... que devemos comprar obras de autores reconhecidos e, de preferência, recomendados. Eu sei disso... hoje em dia. Sem contar que, na época que comprei, eu não conhecia a trilha de livros do Shoes.

Entretanto, continuo usando essa obra como uma das referências dos princípios de um bom projeto de software. Simplesmente, tenho adaptado as partes onde discordo do autor.

Baseado nessas constatações, não poderei mais recomendar o livro. A partir de hoje, ele sumirá da minha lista de livros recomendados.