testes que atuem como uma rede de segurança prevenindo que o comportamento
do software perca a consistência. Por isso, escrever testes e refatorar são técnicas que, geralmente, são utilizadas em conjunto e é exatamente por isso que ambas são
utilizadas no desenvolvimento guiado por testes, conforme estudaremos a seguir.
Um bom design evolui ao longo da vida de um sistema, mas Poppendieck afirma
que um bom design não acontece por acidente. Por isso, ao encontrar algo errado
na base do código, é preciso parar de incluir novos comportamentos ao software e
resolver o problema.
Para garantir uma boa qualidade de código é preciso refatorar. À medida que
novos comportamentos são incluídos no software, por consequência aumentando a
complexidade, existe uma grande tendência de se escrever código duplicado e torná-
lo mais difícil de compreender e de dar manutenção.
Por outro lado, é preciso tomar cuidado para não cair em um perfeccionismo
extremo e gastar tempo tentando aperfeiçoar detalhes sem importância. Para facili-
tar a identificação do momento correto para realizar a refatoração, Poppendieck cita cinco características de um sistema íntegro. Se qualquer uma destas estiver faltando, é sinal de que é hora de refatorar. São elas:
1. Simplicidade: Na maioria das vezes um design simples é o melhor design.
75
4.3. Código Limpo
Casa do Código
Design Patterns, quando bem aplicados, são uma ótima ferramenta para aplicar so-
luções simples a problemas complexos;
2. Clareza: O código fonte deve ser facilmente compreendido por todos os mem-
bros da equipe. Todos os elementos do código devem ser devidamente nomeados
para que sejam facilmente compreendidos por todos;
3. Eficácia: Um bom design deve produzir o resultado correto, isto é, deve atingir
o objetivo pelo qual foi criado;
4. Sem repetição: O mesmo código não deve existir em dois lugares diferentes.
Quando uma mudança precisa ser feita em muitos lugares o risco de defeitos cresce
exponencialmente;
5. Utilidade: Toda funcionalidade de um sistema precisa ser útil para seus usuá-
rios. Quando uma funcionalidade deixa de ser necessária, cria-se desperdício em
mantê-la; em muitos casos é melhor eliminá-la.
4.3
Código Limpo
Robert C. Martin, um dos criadores do Manifesto Ágil, conhecido na comunidade
como Uncle Bob, defende com afinco a ideia de que, ao longo do tempo, a base de
código de um projeto vai se tornando mais bagunçada, e difícil de se entender, im-
pactando fortemente na produtividade da equipe, que tende a zero, ou seja, a ponto
de em um determinado momento a equipe não conseguir mais evoluir e incluir no-
vas funcionalidades no software [41].
De fato, muitos softwares, chegam a um tal ponto que precisam ser reescritos do
zero para que possam continuar a ser evoluídos.
Algumas características de código limpo são:
Elegante, fácil de se compreender, e agradável de se ler.
Simples e direto.
Segue princípios de programação.
Sem duplicidade.
Bem testado.
Parâmetros, Métodos, Funções, Classes e Variáveis possuem nomes significa-
tivos.
76
Casa do Código
Capítulo 4. Entregando Valor
Código é autoexplicativo (sem necessidade de comentários para compreender
o código).
Código bem formatado (é possível ler o código sem precisar utilizar a barra
de rolagem).
Métodos e Classes devem ter uma única responsabilidade (princípio da res-
ponsabilidade única).
Trabalhar para manter o código sempre limpo é, além de uma atitude profissional
do desenvolvedor, muito eficiente em termos de custos para a organização, uma vez
que a mantenabilidade do software será sustentável a médio e longo prazo.
Para Uncle Bob, desenvolvedores profissionais escrevem código como profissio-
nais, e código escrito por profissionais é código limpo!
4.4
Propriedade Coletiva do Código
A Propriedade Coletiva do Código é uma das práticas de XP e consiste na ideia de
que o time é responsável por todo o repositório de código em vez de os indivíduos
serem responsáveis apenas pelo código que eles mesmos escreveram.
Essa prática faz com que manter e garantir a qualidade do código seja responsa-
bilidade de todos os membros do time. Qualquer um pode realizar as alterações que
forem necessárias em qualquer parte do sistema [66].
Nessa abordagem, quando um desenvolvedor precisar alterar determinada parte
do código, não precisará pedir permissão para o desenvolvedor que o escreveu e terá total autonomia de fazer o que precisa ser feito.
Essa prática funciona muito melhor quando em conjunto com revisões de có-
digo, programação em par e integração contínua. Além de melhorar a qualidade,
também ajuda na eliminação de ilhas de conhecimento.
Você já viu uma situação em que determinada parte de um projeto precisa ser
alterada mas a única pessoa do time que escreveu, compreende e conhece aquele
código está de férias? Esta pessoa é um ilha de conhecimento, e essa situação é nociva para o projeto, porque se cria uma dependência muito grande em uma única pessoa,