Você está na página 1de 68

Clean Code

Escrevendo código para seres


humanos

Rodrigo Rosa
@rodrigorosa
Rodrigo Rosa
rodrigo@wonder.com.br
@rodrigorosa
Mas afinal…

O que é “código limpo”?


Elegância e eficiência,
fazer uma coisa bem feita!

Fácil para outro desenvolvedor


entender e melhorar!
Bjarne Stroustrup
criador do C++

Dave Thomas
Legibilidade, código co-autor do The Pragmatic Programmer
como leitura de um livro!

Escrito por alguém que se


Grady Booch importa!
co-criador do UML

Cada rotina faz


exatamente o que você Michael Feathers
espera que ela faça! escritor e coach

Ward Cunningham
co-criador da XP
“Qualquer um consegue escrever código que um computador entende.
Bons programadores escrevem código que humanos
entendem.” (Martin Fowler)
Por que é importante
escrever bom código?

Modelo mental Modelo semântico Modelo sintático


(o problema) (a solução!) (o código)
Três meses depois…
Meu código lindo!
Quem é o culpado?
Deixe uma única janela quebrada e…
Regra do escoteiro

"Deixe o campo mais limpo que


quando você chegou."
Agenda
Nomes

Funções

Comentários

Formatação

Classes

Testes Automatizados
Nomes
Revelar intenção

calcular(int d, int t)

calcularValorDeAtraso(int dias, int taxa)


Evitar desinformação

List pagamentosList = new ArrayList();

Algum tempo depois….

Set pagamentosList = new HashSet();


Fazer distinções
significativas

copy(a, b);

copy(source, destination);
Evitar redundância

Double variableValorPagar;
Double valorPagar;

create table PessoasTable(…)


create table Pessoas(…)
Usar nomes:
Pronunciáveis:

Date genymdhms;

Date generationTimestamp;
Usar nomes:
Procuráveis:
//números mágicos
String a;
total = 7;
int x;

MAX_FILES_PER_STUDENT = 7;
Evitar encoding
Notação húngara
nValor;
sNome;
aCondicoes;

Member prefixes
m_Valor;
_valor;
Usar um termo por
conceito

getPessoas();
fetchPessoas();
retrievePessoas();
Classes e métodos
Classes devem ser substantivos
Pessoa
Conta
Pagamento

Métodos devem ser verbos

totalizar()
excluir()
“Parece simples, mas não deixe isso te enganar”
(Erico Rocha)
Funções
Regras do Clube das Funções:

1 - Devem ser pequenas!

2 - Devem ser menores!


Funções
Fazer uma única coisa!

DRY - Don't Repeat Yourself

SRP - Single Responsibility Principle


Número de linhas?

Número de indentações?
Exemplos de funções
pequenas

Um nível de abstração por função!

http://github.com.br/unclebob/fitnesse
Ler o código de cima para
baixo
Estruturar em níveis

Código como uma narrativa


Cada função é seguida pelas outras no
próximo nível
Código como narrativa
Parâmetros
O ideal é zero!

Um é bom! Dois é tolerável!

Três? Evitar!
Parâmetros do tipo boolean: maybe not

Output Parameter: just don't


Efeitos colaterais

boolean login(String user, String password) {


User user = UserRepository.findByName(user);
if (user != null
&& user.checkPassword(password)) {
Session.initialize();
return true;
}
return false;
}
Command Query
Separation
Função deve FAZER algo ou RETORNAR algo

Use exceções ao invés de códigos de retorno

Não retornar null


Não passar null
Refinamento
Primeira versão da função apenas faz o
código funcionar

Refinamentos para extrair métodos


privados separando responsabilidades,
renomear variáveis e métodos
Por fim, temos funções curtas, bem
nomeadas, organizadas e estruturadas
Comentários

https://acertandooalvo.files.wordpress.com/2012/07/fofoca.jpg
http://vidadeprogramador.com.br/2015/01/21/olha-esse-comentario/
Quando comentários são
ruins?
Quando são redundantes

Quando estão desatualizados


Quando são desnecessários, gerando
sujeira e ruído no código
Quando compensam
“código ruim"
// verifica se o funcionário tem direito
// a todos benefícios
if(employee.flags && HOURLY_FLAG) &&
(employee.age > 65)

if(employee.isEligibleForFullBenefits())
Melhor refatorar
// módulo da lista global depende
// do subsistema do qual fazemos parte?
if(module.getDependSystems()
.contains(subSysMod.getSubSystem())){}

List dependees = module.getDependSystem();


String ourSubSystem = subSysMod.getSubSystem();
if(dependees.contains(ourSubSystem)){}
Quando comentários são
benéficos
Intenção ao invés de explicação

Alerta sobre consequências

TODO
Destacar a importância de algo
Lembrem-se!

Autor e data ficam no controle de versão

Documentação somente em APIs públicas


Código comentado é código morto!
Formatação
The Open Closed Principle - Uncle Bob 12 May 2014 Craftsmanship
In 1988 Bertrand Meyer defined one of the most important principles of
software engineering. The Open Closed Principle (OCP). In his book
Object Oriented Software Construction[1] he said:
A satisfactory modular decomposition technique must satisfy one more
requirement: It should yield modules that are both open and closed.
A module will be said to be open if it is available for extension. For
example, it should be possible to add fields to the data structures it
contains, or new elements to the set of functions it performs.
A module will be said to be closed if is available for use by other
modules. This assumes that the module has been given a well-defined,
stable description (the interface in the sense of information hiding).
In the case of a programming language module, a closed module is one
that may be compiled and stored in a library, for others to use. In
the case of a design or specification module, closing a module simply
means having it approved by management, adding it to the project's
official repository of accepted software items (often called the
project baseline), and publishing its interface for the benefit of
other module designers.
This definition is obviously dated. Nowadays many languages don't
require that modules be compiled. And getting module specifications
approved by management smacks of a waterfall mentality. Still, the
essence of a great principle still shines through those old words. To
wit:
You should be able to extend the behavior of a system without having
to modify that system.
http://blog.8thlight.com/uncle-bob/2014/05/12/TheOpenClosedPrinciple.html
Metáfora do
jornal
Lido verticalmente
Manchete no topo
Sinopse
Detalhes

http://capituloportoalegre.blogspot.com.br/2011/06/demolay-e-capa-do-jornal-zero-hora-e.html
Ordenação vertical (de cima para baixo)

Espaçamento vertical (parágrafos)

Continuidade vertical (associação íntima)


Distância vertical (não separar conceitos)
Formatação

https://github.com/caelum/caelum-stella/blob/master/stella-boleto/src/main/java/br/com/caelum/stella/boleto/utils/StellaStringUtils.java
Padrões internos

Padrões da equipe

Recursos da IDE
Respeito!
Classes
SOLID
Single Responsibility Principle (SRP)

Open Closed Principle (OCP)

Liskov Substitution Principle (LSP)


Interface Segregation Principle (ISP)

Dependency Inversion Principle (DIP)


Classes

Devem ser pequenas!

Responsabilidade única
Acoplamento

"É o grau em que um módulo depende


de outro módulo de programação.”

http://pt.wikipedia.org/wiki/Acoplamento_%28programa%C3%A7%C3%A3o_de_computadores%29
Coesão

"É a medida da força relativa de um módulo"


http://pt.wikipedia.org/wiki/Coes%C3%A3o
Regras do Clube das Classes:

1. Devem ter baixo


acoplamento

2. Devem ter alta coesão


Testes
Três leis
1. Não se deve escrever testes de produção
até ter um teste falhando;

2. Não se deve escrever mais que o


suficiente para falhar o teste
3. Não se deve escrever mais código de
produção que o suficiente para o teste
passar
Manter os códigos dos testes limpos
(padrão construir-operar-verificar)

Minimizar o numero de asserts por teste


(não necessariamente apenas um)
Testar um único conceito por teste
Formas de medir a
qualidade
Testes automatizados

Peer review

Avaliadores estáticos de código


FindBugs, CheckStyle, PMD

CodeClimate, RubyCritic
“Reconhecer bom código de mau código não significa que você saiba
fazer bom código.” (Uncle Bob)
Leituras complementares
Fontes e referências
http://blog.cleancoder.com/

http://aestheticio.com/why-your-code-is-hard-to-understand/

http://www.cs.colostate.edu/TechReports/Reports/1994/tr-120.pdf

https://github.com/caelum/caelum-stella/

http://blog.caelum.com.br/principios-do-codigo-solido-na-orientacao-a-
objetos/

https://github.com/unclebob

Você também pode gostar