O documento discute os princípios de código limpo, incluindo os custos de ter um código confuso, definições de código limpo de acordo com especialistas, e princípios como nomes significativos, métodos pequenos, tratamento de erros, testes unitários, classes coesas e design emergente.

1. Código limpo
Diego Magalhães Cunha
Gustavo Moreira
Tauan Nascimento Almeida

2. Introdução

3. O custo de ter um código confuso
● Ao longo de um certo tempo de trabalho,
equipes que trabalham rapidamente no
inicio de um projeto podem perceber mais
tarde que estão indo a passos de tartaruga.
● Cada alteração feita no código causa uma
falha em outras duas ou tres partes do
mesmo código.

4. O custo de ter um código confuso
● Mudança alguma é trivial.
● Cada adição ou modificação ao sistema
exige que restaurações, amarrações e
remendos sejam "entendidas" de modo que
outras possam ser incluidas.

5. O custo de ter um código confuso
● Com o tempo, a bagunça se torna tão
grande e profunda que não dá para arrumá-
la.
● Não há absolutamente solução alguma.

7. O grande replanejamento
● No final, a equipe se rebela.
● Todos informam à gerência que não
conseguem mais trabalhar neste irritante
código-fonte e exigem um replanejamento
do projeto.

8. O grande replanejamento
● Apesar de a gerência não querer gastar
recursos em uma nova remodelação, ela
não pode negar que a produtividade está
péssima.
● No final das contas, ela acaba cedendo às
exigências dos desenvolvedores e autoriza
o grande replanejamento desejado.

9. O grande replanejamento
● É, então , formada uma nova equipe
especializada.
● Por ser um projeto inteiramente novo, todos
querem fazer parte dessa equipe.
● Eles desejam começar do zero e criar algo
belo de verdade.

10. O grande replanejamento
● Mas apenas os melhores e mais brilhantes
são selecionados e os outros deverão
continuar na manutenção do sistema atual.
● Agora ambos os times estão numa corrida.

11. O grande replanejamento
● A nova equipe precisa construir um novo
sistema que faça o mesmo que o antigo,
além de ter de ser manter atualizada em
relaçao às mudanças feitas constantemente
no sistema antigo.
● Este, a gerencia não substuirá até que o
novo possa fazer tudo também.

12. O grande replanejamento
● Essa corrida pode durar um bom tempo. Já
vi umas levarem 10 anos.
● E, quando ela termina, os membros originais
da nova equipe já foram embora há muito
tempo, e os atuais exigem o replanejamento
de um novo sistema, pois está tudo uma
zona novamente.

13. O grande replanejamento
● Se você já vivenciou pelo menos um pouco
dessa situação, entao sabe que dedicar
tempo para limpar seu código nao é apenas
eficaz em termos de custo, mas uma
questão de sobrevivencia profissional.

14. O problema do prazo
● Todos os gerentes protegem os prazos e os
requisitos, mas essa é a função deles.
● A sua, é proteger o código.

15. O problema do prazo
● Por mais que os prazos estejam estourados,
preze por um código bem feito, bem escrito.
● Imagine se você fosse um médico e seu
paciente (seu chefe, neste contexto)
exigisse que você não lavasse suas mãos
antes de uma operação devido a perda de
tempo.

16. O problema do prazo
● É óbvio que você não dará ouvidos a este
paciente.
● Da mesma forma, em alguns momentos, o
atraso é aceitável levando em consideração
as consequências.

17. Mas afinal, o que é ou como é um
código limpo?

19. O que é ou como é um código
limpo?
● Existem várias definições.
● Vamos citar algumas definições dadas por
alguns dos pioneiros neste assunto.

20. Bjarne Stroustrup
Gosto do meu código elegante e eficiente. A
lógica deve ser direta para dificultar o
encobrimento de bugs, as dependências
mínimas para facilitar a manutenção, o
tratamento de erros completo de acordo com
uma estratégia clara e o desempenho próximo
do mais eficiente de modo a não incitar as
pessoas a tornarem o código confuso com
otimizações sorrateiras.
O código deve proporcionar uma leitura
natural.

21. Grady Booch
Um codigo limpo é simples e direto. Ele é tão
bem legível quanto uma prosa bem escrita.
Ele jamais torna confuso o objetivo do
desenvolvedor, em vez disso, ele está repleto
de abstrações claras e linhas de controle
objetivas.

22. Dave Thomas
Alem de seu criador, um desenvolvedor pode ler e
melhorar um código limpo.
Ele tem:
- teste de unidade e de aceitação,
- nomes significativos,
- oferece apenas uma maneira, e não várias, de se fazer
uma tarefa;
- possui poucas dependências, as quais são explicitamente
declaradas,
- oferecem uma API mínima e clara.

23. Dave Thomas
O código deve ser inteligivel já que dependendo da
linguagem, nem toda informação necessária pode ser
expressa no código em si.

24. Nomes Significativos
● Nomes são peças chaves em um código
○ Variáveis, classes, métodos, ...
● Devem nos dizer três coisas
○ Porque existem
○ O que fazem
○ Como são usados

25. Dicas para bons nomes
● Distinções significativas
○ Nomes como a1, a2, a3, ..., não dizem nada sobre a
variável, método, etc.
● Não usar trocadilhos ou abreviações
○ O nome deve ser auto-explicativo.

26. Métodos e Funções
"A primeira regra dos métodos é que eles
devem ser pequenos, a segunda é que eles
devem ser menores ainda. "

27. Métodos e Funções
● Conter no máximo 20 linhas
● Nível de identação não pode ser maior que
2
● Receber o mínimo de parâmetros possível
○ Receber muitos parâmetros dificulta o Teste Unitário
● Somente uma responsabilidade

28. Métodos e Funções
● Exemplo
public boolean checkPassword(String username, String
password)
{
String passwordStatus = cryptographer.decrypt
(password);
if(passwordStatus.equals(“OK”) ) {
Session.initialize();
return true;
}
return false;
}

29. Comentários
● São úteis quando colocados nos locais
certos
○ Informar uma consequência
○ Explicar uma decisão tomada
● O principal motivo para se escrever um
comentário é um código ilegível
"Explique-se no código."

30. Formatação
● Forma de comunicação do desenvolvedor
● Leitores entenderam o que estão lendo
● Auxilia mudanças futuras

31. Dicas para formatação
● Não escreva classes com mais de 500
linhas
○ Classes menores são mais fáceis de se entender
● Estabeleça um limite sensato para o
tamanho de uma linha
● Faça uma boa identação
○ Não deixe seu código grudado

32. Tratamento de erros
● Não exagerar no tratamento de erros
○ Não é possível enxergar objetivo do código
● Use exceções
○ Linguagens antigas retornavam códigos de erro
● Forneça exceções com contexto
○ Mensagens passadas juntamente com a exceção,
como tipo de falha

33. Testes Unitários (TDD - Test Driven Development)
● É uma técnica de desenvolvimento de software que
baseia em pequenos ciclos de repetições;
● Para cada funcionalidade do sistema é criado um teste
antes;
● Esse teste deverá falhar, pois não temos nenhuma
funcionalidade;
● Logo após fazemos o teste passar implementando a
funcionalidade.

34. Motivos para o uso do TDD
● Feedback rápido sobre a nova funcionalidade e sobre
as outras funcionalidades existentes no sistema;
● Código é mais limpo, já que escrevemos códigos
simples para o teste passar;
● Segurança no Refactoring pois podemos ver o que
estamos ou não afetando;
● Segurança na correção de bugs;
● Maior produtividade já que o desenvolvedor encontra
menos bugs e não desperdiça tempo com depuradores;
● Código da aplicação mais flexível e menos acoplado.

35. Ciclo de Desenvolvimento TDD
● Red, Green, Refactor:
● Escrevemos um Teste que inicialmente não passa (Red) - ele deve falhar;
● Adicionamos a nova funcionalidade do sistema;
● Fazemos o Teste passar (Green);
● Refatoramos o código da nova funcionalidade (Refactoring);
● Escrevemos o próximo Teste.

36. Classes
● O nome da classe deve representar sua
funcionalidade, explicando o que ela faz;
● Não deve conter palavras como “mas”, “e”, ”
ou”, “se”:
○ "AvaliarSePodePromoverParaPremium";
○ "AvaliadorDeClientePremium".
● Ter no máximo 25 palavras.

37. Princípio da responsabilidade única
(SRP) - da Classe
● Segundo Mr. Robert C. Martin, "uma classe só
deve mudar por um único motivo";
● Pergunta a se fazer: esta classe vai ter que
mudar por mais um motivo com esta introdução
que estou fazendo?
● Resultado: Muitos métodos pequenos, com
muitas classes pequenas. Muita modularidade.

38. Princípio da responsabilidade única
(SRP) - da Classe
● Háverá muitas funções, mas cada uma com
uma única responsabilidade, e elas irão fazê-
las direito;
● Os dados e comportamento estão juntos,
porém modularizados;

39. Design Emergente
● É um design que nunca é o final, sempre
está em evolução;
● Kent Beck criou 4 regras básicas para o que
ele chamou Simple Design:
○ Rode todos os testes;
○ Remova Duplicação;
○ Expresse sua intenção;
○ Diminua o número de classes e métodos.

40. Design Emergente
● Rode todos os testes:
○ Fazer um sistema testável é possuir todos os testes
passando;
○ Ele se torna verificável.
● Remova duplicação de código;
○ Exemplo: Se você percebeu que tem um método
que se repete em mais de uma classe, remova-o
das classes e crie uma nova classe, mesmo que
seja só para ter este método.

41. Design Emergente
● Expresse sua intenção:
○ Escolher bons nomes, deixar métodos e classes
pequenas e separar responsabilidades.
● Diminuir o número de classes e métodos:
○ Sempre que possível, mantenha sistemas pequenos
enquanto ao mesmo tempo se mantém métodos e
classes pequenas.

42. Conclusão
● Estes princípios nos ajudam a desenvolver
códigos de maior qualidade;
● Torna o código comunicável entre os
membros das equipes de programação;
● E influencia em uma melhor
manuteniblidade do código.

43. Obrigado!

44. Bibliografia
● MARTIN, ROBERT C. Código Limpo:
Habilidades Práticas do Agile Software. São
Paulo: Bookman, 2009.
● http://blog.bluesoft.com.br/bluesoft-labs-
clean-code-por-bruno-lui/
● http://blog.lambda3.com.
br/2009/02/principio-da-responsabilidade-
unica-srp/
● http://www.k19.com.br/artigos/tdd-simples-e-
pratico-parte-i/