A

vida de um programador não

é fácil. A tecnologia é algo
que não para de evoluir e a
cada dia surge uma forma diferente de
escrever um código. A carreira de um
profissional de informática é algo de sua proposto;
responsabilidade. O código produzido
por esse profissional também é de sua parte do código já faz;
responsabilidade. Um bom código não
é somente aquele que é funcional, mas códigos;
também aquele que não tem valores -
exorbitantes para ser mantido. A maior cupação em produzir aquele código.
parte dos programadores não gostam de
alterar códigos mal escritos. Isso é algo Antes de falarmos sobre como fazer
que traz muita frustração e muitas vezes para atingir esse nível de qualidade,
um retrabalho desnecessário. vamos falar um pouco sobre testes.

Um código limpo deve ser: Construir um software não é somente

escrever código e vê-lo funcionar, é você
saber que aquele código será manutení-
“voltas” para atingir seu objetivo; vel e que outras pessoas vão alterá-lo.
 Para isso, teste é fundamental! Você tem que ser responsável
por aquilo que escreve e saber que seu sistema tem que con-
tinuar funcionando. Neste contexto, temos a primeira dica
sobre um código limpo:

Muitas empresas veem testes como gastos maiores no pro-

jeto, o que de fato acontece, porém a qualidade do software
produzido é algo significante. Quando não se produz teste
automatizado, a quantidade de testes manuais são maiores e
muitas vezes o custo desses testes também é maior.

Métodos, nomes de variáveis e etc. devem possuir nomes que

significam alguma coisa em relação ao seu objetivo. Os nomes
utilizados devem responder todas as questões a seguir:
Vamos imaginar que um sistema de um motor de um carro
tenha um método com o nome de “run” ao invés de “acelerar”.
Se você pegar um código com esse nome você terá que estudar
todo o método para saber o que ele faz.
Algo muito comum encontrado nos códigos é o tipo de de-
claração apresentado na Listagem 1.
Se um nome de classe, método ou atributo requer um comen-
tário, ele não está revelando sua real intenção.
A notação Húngara visa facilitar o reconhecimento do tipo
de variável em um programa colocando em seu nome um su-
fixo descrevendo seu tipo (ver Listagem 3). Entretanto, com o
advento de novas linguagens, técnicas mostradas aqui e testes
automatizados, a notação húngara se mostra desnecessária.
Existe uma certa tendência para a criação de classes e méto-
dos menores de modo que as pessoas possam ver onde cada
variável que estão usando foi declarada. Além disso, os testes
indicam os tipos e maneiras de usar, validando o comporta-
mento esperado do método.

é
Nome de classes devem ser substantivos e não conter verbos.
Já nomes de métodos devem conter verbos, pois eles indicam
ações.
A regra para métodos é: “A primeira regra dos métodos é que
eles devem ser pequenos. A segunda regra é que eles devem
ser menores ainda.”
Métodos e classes menores são mais fáceis de ler e entender,
além de manter é claro. Segundo o livro, podemos considerar
as seguintes métricas:

Quando colocamos uma linha em nosso código com um co-

mentário ao lado não estamos dando o nome correto ao atributo
ou método. O código quando bem escrito deve ser algo que
seja de fácil leitura, algo que uma pessoa leiga conseguiria ao
menos saber o que o mesmo faz. Os nomes utilizados devem
ser pronunciáveis, algo que você entenda.
Observe no exemplo da Listagem 2 como essa prática torna
o código mais fácil de ser entendido.
Claro que toda regra tem sua exceção. Se você tem uma clas-
se que vai precisar de mais linhas, um método que também
precise de mais linhas, isso não é um problema.
“Métodos e funções devem fazer somente uma coisa, fazê-la
certa e somente fazê-la”.
 Poderíamos analisar essa frase como um princípio da coesão com vários comentários que não serviam para nada e, pior,
no seu código. Muitas vezes não é fácil saber se aquele método confundiam. Se um método ou uma classe estiver bem escrito,
está fazendo somente uma coisa. Uma dica para isso é: você a importância do comentário é minimizada.
deve tentar extrair parte do seu código para um método, se
você conseguir é porque aquele seu método realmente não
está tendo uma função apenas.
Imagine que você tenha um método onde quiséssemos mos-
trar os detalhes de um usuário:

Neste exemplo, as linhas do System.out.print são os detalhes

do usuário. Mas será que isso não ficaria melhor escrito se
estivesse de acordo com o código da Listagem 4?

Outro ponto importante, um comentário não irá esconder

um código ruim. Observe o exemplo a seguir:

Esse código já está ruim, de nada adianta mudarmos para:

Se um dia você quiser apenas listar os dados de um usuário

ficará mais fácil. Agora temos os métodos separados. Essa
prática também é um bom exemplo do tipo de refatoração
chamada “Extract Method”.
Um outro item que deve ser observado é a quantidade de pa-
râmetros de um método. Você deve ter uma justificativa muito
boa para ter uma quantidade tão grande de parâmetros em um
método. Um agravante de um método com vários parâmetros
é a dificuldade de se testar uma vez que você deverá testar
todas as combinações possíveis.
Outra situação a que você deve estar atento é com um método
que informa que irá fazer uma determinada ação e faz outra.
Observe a Listagem 5.
O objetivo do método é verificar a senha, porém, se a
senha estiver correta o mesmo inicia uma sessão, ou seja,
o método já não tem a coesão esperada, pois possui duas
responsabilidades.
Uma solução melhor para esse cenário pode ser observada
na Listagem 6.
Comentários, apesar de importantes, podem trazer desin-
formação. Por que podemos afirmar isso? Alguém conhece
programadores que atualizam comentários? Há vários códigos
Esse comentário não irá se propagar para todo o código e sem-
pre que você se deparar com uma linha como “d1.after(d2);”
você vai continuar não entendendo o propósito do código.
Podemos tentar colocar uma regra nisso. Muitas vezes quan-
do se comenta um código, pode ser que o mesmo precise ser
refatorado. Lembra dos exemplos anteriores onde “d1” passou
a ser “dataCompra”? Com essa mudança seu código pode ser
entendido por todos e se fizermos essa refatoração o código
passa a não precisar mais de comentário.
Observe agora o exemplo a seguir:
Observe agora o exemplo ajustado na Listagem 7.
Note que tiramos o comentário, melhoramos o código e o
tornamos mais legível. Agora a leitura do código é suficiente
para saber o que ele realmente faz.
Outro tipo de comentário que deve ser evitado é apresentado
no exemplo a seguir:

O return do método é lógico, não há necessidade de indicar
o que o mesmo está retornando.
Em relação a comentários, podemos dizer que:
comentário que faça você olhar para outras partes do seu código para
Por outro lado, existem momentos em que o comentário
é importante. Digamos que você tenha um trecho em seu
código que vai demandar um tempo de processamento alto
ou a disponibilidade de um recurso. Nesses casos, comen-
tários acabam sendo úteis. Algumas vezes também não se
consegue colocar um nome em um método que explique o
porquê o desenvolvedor tomou aquela decisão.
“Formatação é importante, pois se trata de comunicação.”
Temos que considerar que o código é a maneira que a equipe
de desenvolvimento vai se comunicar. Uma pessoa não gostaria
de receber uma carta cifrada onde tivesse que interpretar o que
está escrito nela, podemos pensar assim na hora de escrever
um código.
Outra ponto importante é que se você pega um código
bem estruturado, você vai querer mantê-lo bem estruturado.
É ruim para qualquer desenvolvedor ter acesso a um código
sem formatação, sem endentação e ter que fazer sua leitura
como se fosse um texto sem qualquer pontuação.
Além disso, métodos com conceitos relacionados devem ficar
verticalmente próximos e a ordem dos métodos deve criar um
fluxo de leitura melhorando a legibilidade do código.
Uma boa endentação é fundamental, mas não podemos ter
muitos níveis. Observe como o trecho a seguir poderia se tornar
confuso caso a lógica implementada fosse complexa:
 Os testes devem considerar as características F.I.R.S.T:

dos profissionais responsáveis por sua execução;

um falha o outro vai falhar também;

retornar sempre o mesmo resultado;

“Quando estamos programando devemos tratar os possíveis

erros que nossa aplicação poderá lançar, as coisas podem dar
errado e temos que estar certos que nosso código fará o que Escrever um bom código muitas vezes pode não parecer uma
deve fazer.” missão tão simples. Considere o trecho de código a seguir:
Tratamento de erro é de responsabilidade do desenvolvedor.
É preciso garantir que o código vai ter um tratamento para
cada situação. Prefira lançar uma exception ao invés de retornar
um código de erro. Estes retornos desorganizam a chamada do
método e pode-se facilmente esquecer de verificá-los.
Dentro do seu método você já pode ver o erro que está sendo
retornado e tratá-lo ali. Defina o fluxo do método separando Concorda que o “!texto.equals(“”)” não serve para nada? Se fi-
as regras de negócio de erros ou outras situações. Para seus zermos a refatoração a seguir obteremos o mesmo resultado:
erros, crie mensagens informativas mencionando a operação
que falhou e o tipo de falha.
Procure utilizar exceptions para situações inesperadas, por
exemplo: seu código está lendo um arquivo e a rede se tornou
indisponível.

Agora, digamos que ainda assim estivéssemos com receio

TDD nada mais é que o desenvolvimento guiado por testes. de fazer essa refatoração. Neste caso, a presença de um sim-
As três regras do TDD são: ples teste unitário poderia eliminar a dúvida referente ao
fato da funcionalidade continuar desempenhando seu papel
teste falhando; corretamente.
A refatoração é uma das melhores práticas para melhorarmos
para falhar; nosso código. Seu código pode ser eficaz, ou seja, fazer o que
se deseja, mas também pode ser eficiente, fazer o que se deseja
passar no teste que está falhando. da melhor maneira possível.

Assim, se você tiver que testar se um CPF é válido, por exem-

plo, você deve criar alguns testes tais como: