O Programador Pragmático – Capítulo 2 – primeira parte

By Gabriel Rubens

Continuando a leitura e resumo do livro O Programador Pragmático, vai aí o resumo do segundo capítulo que vai ser dividido em alguns pedaços.

Obs.: Esse resumo não substitui de modo algum a leitura do livro!

Duplicação

O segundo capítulo é iniciado abordando o problema da duplicação, não somente a duplicação de código, mas também as especificações e documentações. O problema da duplicação no código já e reduzido quando passamos a trabalhar com Orientação a Objetos (ou não) e isso não significa que só por programar em Java, Ruby ou C# estamos programando OO.

Nesse parte o livro fala sobre os males de se duplicar informações, já que teremos o problema de a cada modificação teremos que procurar todos os locais que a informação está duplicada. E esse problema não é só em código, as informações podem está em documentações excessivas ou comentários exagerados em métodos que deveriam ser refatorados.

A solução para o problema da duplicação está em um conceito chamado de NSR que é o acrônimo de Não Se Repita (DRY, ou Don’t Repeat Yourself). Nessa parte os autores deixam a seguinte dica: “Cada bloco de informação deve ter um representação oficial, exclusiva e sem ambiguidade dentro de um sistema”

Ortogonalidade

A segunda parte do segundo capítulo trata sobre ortogonalidade (veja mais aqui), sobre as vantagens de se desenvolver um sistema onde alterações em um modulo não causam danos a outros, coisas já conhecidas por quem utiliza MVC e sistemas baseados em componente, outro exemplo dado no livro é a utilização de AOP para diminuir o problema de sistemas não ortogonais.

Mais uma vez o livro trata de assuntos que são cobertos pela Orientação a Objetos, como o encapsulamento, onde escondemos a estrutura interna de nossas classes, fazendo com que o cliente apenas conheça a sua API. Um exemplo bem básico é quando encapsulamos o nosso acesso a dados com o DAO, assim a troca de código SQL nativo por JPA fica mais fácil.

Os exercícios dessa parte são bem simples, mais é fantástica a explicação das respostas, principalmente a parte que fala da Orientação a Objetos x Procedural.

Reversibilidade

A frase do Emil-Auguste no início do item reversibilidade já deixa bem clara a abordagem que os autores propõem “Nada é mais perigoso do que uma ideia quando ela é a única que você tem”.

É desse modo que a reversibilidade é iniciada, basicamente falando que soluções simples são mais fáceis de serem alteradas. Uma mensagem que fica é que devemos sempre ter em mente que a solução que nós adotamos para combater determinado problema não é a única. Existem muitas abordagem para o mesmo assunto, por exemplo, podemos ter que alterar o banco de dados que está sendo utilizado no projeto. Os autores dizem que devemos tomar cuidado com cada pequena decisão que tomamos, já que podemos chegar ao ponto em que o bater de asas de uma borboleta em Tóquio pode causar uma série de eventos que encadeiam um furacão no Texas. E para se prevenir desse tipo de problema devemos tomar mais cuidado com as decisões e ter em mente que os requisitos podem mudar (e vão mudar), e como diz no livro “Em vez de tomar decisões esculpidas em pedra, considere-as mais como se tivessem sido escritas na areia da praia”. Mais uma dica dada nessa parte do livro é de sempre encapsular ferramentas e bibliotecas de terceiros, e até mesmo a suas, já que ela pode deixar de ser a melhor solução no futuro.

Gabriel Rubens

Postagens Relacionadas:

• O Programador Pragmático – Capítulo 2 – segunda parte
• O Programador Pragmático – parte 6
• O Programador Pragmático – parte 7
• O Programador Pragmático – Capítulo 1
• O Programador Pragmático – parte 8
• O Programador Pragmático – Resenha do prefácio
• Livro SCJP (guia de bolso)