Embed Size (px)
DESCRIPTION
Minha palestra sobre Clean Code no Tech Day da Ticket.
Citation preview
O que é “bonito”?
Qual é o mais bonito?
Qual é o mais bonito?
Qual é o mais bonito?
simples??flexív
el?fácil de ler?
sem duplicaçõ
es?curto?
enxuto?
O que é código bonito?
Qual é o menos feio?
É mais fácil identificaro feio! :)
E isso pode ser útil!
métodos
longos sem padrã
o
classes
gigantes código
repetidomuitos
parâmetros
muitos if’s
“As feias que me
perdoem, mas beleza
é fundamenta
l!”
Agora vai ficar técnico!
Pensar nos nomes é importante!
Deve dizer o que ele faz, e como deve ser usado!
Tira a necessidade de lera implementação do método.
Deve ser fácil de ser entendidopor todos da equipe.
int kkk; // dias da semanaWTF?
Use nomes que
façam sentido!
public List<int[]> getThem() { List<int[]> list1 = new ArrayList<int[]>(); for (int[] x : theList) if(x[0] == 4) list1.add(x); return list1;}
public List<int[]> getFlaggedCells() { List<int[]> flaggedCells = new ArrayList<int[]>(); for (int[] cell : gameBoard) if(cell.isFlagged()) flaggedCells.add(cell); return flaggedCells;}
for(int i = 0; ...) { int a1 = i * 8; int a2 = a1 / 2; int a3 = (a1 + a2) * 3;}
Não crie variáveis com nomes similares!
List<Conta> contasAbertas;
@Testpublic void deve_testar_x(){}
Tenha um padrão!
List<Conta> scherobles;
Pense na língua que vai escrever.
Use nomes pronunciáveis!
E em relação aosmétodos?!
Deve ser enxuto.
Deve ter apenas umaresponsabilidade.
Deve deixar claro sua intenção.
Quantas linhas? 20? 100?
Uma página de impressora?Uma tela?
Tamanho dosmétodos
Qual o tamanho máximo?4? 8? 20?2 ifs? 3 ifs?
ComplexidadeCiclomática
Ou o método faz alguma coisa,ou ele devolve alguma coisa.
Nunca os dois.
Command QuerySeparation
O menor possível.
Mais que 3? Pense pra fazer isso.
Quantidade de parâmetros?
Evite passar “boolean” pros seus métodos.
Método faz coisa demais?
Usar flags?
Evite retornar null.
A ideia do bom vizinho.
Não retorne null!
Evite repetir código. - Extraia o que há de comum para outros métodos.
Código repetido?
Comentário de código
Somente quando necessário.
O comentário não é “código”!
Raramente são atualizados.
Comentário não é “maquiagem” de código.- Código está feio, refatora.
Código feio precisa de
comentário?
if(aluno.getQtdCursos()>10 && aluno.getMeses() > 24) { // ...}
E aquela condição
complicada?
if(aluno.isImportante()) { // ...}
O melhor é não ter.- Explicar algoritmo matemático?-Explicar alguma decisão de negócio?
Quando um comentário é
bom?
E minhas classes?
Devem ter uma única responsabilidade.
Quanto mais enxuta,mais fácil de manter e
reutilizar.
Não deve dependerde muitas outras classes.
Objetos devem ter atributos e métodos que manipulam esses atributos.
Isso é diferente de uma simples estrutura de dados.
OO from the Trenches
Pense em abstrações.
Abstrações possibilitam a evolução mais natural do código.
Estude padrões de projeto.
Abstrações são do bem
A classe deve esconder COMO ela faz sua tarefa.
Intimidade inapropriada.
Encapsule direito!
Quando bem utilizados, ajudam a flexibilizar o sistema.
“Todo mundo” conhece a solução.
Estude padrões de projeto
Tratamento de erros
Deve ser feito de maneira elegante.
Use exceções para casos excepcionais.
Não use o retorno do método para indicar se houve uma exceção.
Não use o retorno do método!
Dê contexto para sua exceção.
Se você está encapsulando a exceção, passe-a como a “causa” da sua exceção.
Exceptions caprichadas
Arquitetura?
Arquitetura vira código...
Não saia criando EJBs pra lá e pra cá...
Não tenha 200 camadas, só porque fica bonito no diagrama.
Evite arquiteturascomplicadas
demais
Não me diga que o Spring MVC / VRaptor não serve pra você...
Esqueça o seu framework
corporativo caseiro!
Não escreva regras de negócio no controller.
MVC é legal!
Controllers na Web
O que os “pops” de lá dizem?
Clean code is simple and direct. Clean code reads like wellwritten prose. (Grady Booch)
Clean code always looks it was written by someone who cares. There is nothing
obvious that you can do to make it better. (Michael Feathers)
Clean code can be read, and enhanced by a developer other than its original author.
(Dave Thomas)
O que os “pops” daqui dizem?
Código bom é o código que com o mínimo de esforço um desenvolvedor mediano do
projeto entende mesmo após o criador sair do projeto. (Guilherme Silveira)
Código bonito é código fácil e bom de ler. (Paulo Silveira)
Código que você consegue ler imediatamente, sem precisar se
esforçar. (Lucas Cavalcanti)
O que os “pops” daqui dizem?
Código feito pra pessoas lerem: tão simples quanto possível, bem separado, com nomes
decentes, etc. (Cecília Fernandes)
Código bonito é código cujos passos estão todos em um mesmo nível de abstração de forma que eu entenda claramente o melhor
ponto para alterá-lo sem ter que me preocupar se minha mudança gera impactos
inesperados. (Hugo Corbucci)
Referências
•Code Beauty. Fabio Kon. 2010.
•Clean Code. Robert Martin.
OBRIGADO!
Mauricio [email protected]
@mauricioanichehttp://www.aniche.com.br
http://www.tddnomundoreal.com.br
