O que é código bonito?

1,371 views
1,251 views

Published on

Minha palestra sobre Clean Code no Tech Day da Ticket.

O que é código bonito?

  1. 1. Mauricio Anichemauricio.aniche@caelum.com.br@mauricioanichehttp://www.aniche.com.br
  2. 2. O que é “bonito”?
  3. 3. Qual é o mais bonito?
  4. 4. Qual é o mais bonito?
  5. 5. Qual é o mais bonito?
  6. 6. simples??flexível?fácil deler? semduplicações?curto?enxuto?O que é código bonito?
  7. 7. Qual é o menos feio?
  8. 8. É mais fácil identificaro feio! :)! :)E isso pode ser útil!
  9. 9. métodoslongossempadrãoclassesgigantescódigorepetidomuitosparâmetrosmuitosif’s
  10. 10. “As feias queme perdoem,mas beleza éfundamental!””
  11. 11. Agora vai ficar técnico!
  12. 12. Pensar nos nomesé importante!é 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.
  13. 13. int kkk; // dias da semanaWTF?Use nomes quefaçam sentido!façam sentido!
  14. 14. 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 = newArrayList<int[]>(); for (int[] cell : gameBoard)if(cell.isFlagged())flaggedCells.add(cell); return flaggedCells;}
  15. 15. for(int i = 0; ...) {int a1 = i * 8;int a2 = a1 / 2;int a3 = (a1 + a2) * 3;}Não crie variáveiscom nomes similares!
  16. 16. List<Conta> contasAbertas;@Testpublic void deve_testar_x(){}Tenha um padrão!
  17. 17. List<Conta> scherobles;Pense na língua que vaiescrever.Use nomespronunciáveis!
  18. 18. E em relação aosmétodos?!?!Deve ser enxuto.Deve ter apenas umaresponsabilidade.Deve deixar claro sua intenção.
  19. 19. Quantas linhas? 20? 100?Uma página de impressora?Uma tela?Tamanho dosmétodosmétodos
  20. 20. Qual o tamanho máximo?4? 8? 20?2 ifs? 3 ifs?ComplexidadeCiclomáticaCiclomática
  21. 21. Ou o método faz alguma coisa,ou ele devolve alguma coisa.Nunca os dois.Command QuerySeparationSeparation
  22. 22. O menor possível.Mais que 3? Pense pra fazerisso.Quantidade deparâmetros?
  23. 23. Evite passar “boolean” prosseus métodos.Método faz coisa demais?Usar flags?
  24. 24. Evite retornar null.A ideia do bom vizinho.Não retorne null!
  25. 25. Evite repetir código.- Extraia o que há de comumpara outros métodos.Código repetido?
  26. 26. Comentário de códigoSomente quando necessário.O comentário não é “código”!Raramente são atualizados.
  27. 27. Comentário não é “maquiagem”de código.- Código está feio, refatora.Código feio precisade comentário?
  28. 28. if(aluno.getQtdCursos()>10 &&aluno.getMeses() > 24) {// ...}E aquela condiçãocomplicada?complicada?if(aluno.isImportante()) {// ...}
  29. 29. O melhor é não ter.- Explicar algoritmomatemático?-Explicar alguma decisão denegócio?Quando umcomentário é bom?
  30. 30. E minhas classes?Devem ter uma únicaresponsabilidade.Quanto mais enxuta,mais fácil de manter ereutilizar.Não deve dependerde muitas outras classes.
  31. 31. Objetos devem ter atributos emétodos que manipulam essesatributos.Isso é diferente de umasimples estrutura de dados.OO from theTrenches
  32. 32. Pense em abstrações.Abstrações possibilitam aevolução mais natural docódigo.Estude padrões de projeto.Abstrações sãodo bemdo bem
  33. 33. A classe deve esconder COMOela faz sua tarefa.Intimidade inapropriada.Encapsule direito!
  34. 34. Quando bem utilizados, ajudama flexibilizar o sistema.“Todo mundo” conhece asolução.Estude padrões deprojeto
  35. 35. Tratamento de errosDeve ser feito de maneira elegante.Use exceções paracasos excepcionais.
  36. 36. Não use o retorno do métodopara indicar se houve umaexceção.Não use o retornodo método!
  37. 37. Dê contexto para sua exceção.Se você está encapsulando aexceção, passe-a como a“causa” da sua exceção.Exceptionscaprichadas
  38. 38. Arquitetura?Arquitetura vira código...
  39. 39. Não saia criando EJBs pra láe pra cá...Não tenha 200 camadas, sóporque fica bonito nodiagrama.Evite arquiteturascomplicadas demaiscomplicadas demais
  40. 40. Não me diga que o SpringMVC / VRaptor não serve pravocê...Esqueça o seu frameworkcorporativo caseiro!
  41. 41. Não escreva regras de negóciono controller.MVC é legal!Controllers na Web
  42. 42. O que os “pops” de ládizem?Clean code is simple and direct. Clean code reads likewellwritten prose. (Grady Booch)Clean code always looks it was written by someonewho cares. There is nothing obvious that you can do tomake it better. (Michael Feathers)Clean code can be read, and enhanced by a developerother than its original author. (Dave Thomas)
  43. 43. O que os “pops” daquidizem?Código bom é o código que com o mínimo de esforçoum desenvolvedor mediano do projeto entende mesmoapó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)
  44. 44. O que os “pops” daquidizem?Código feito pra pessoas lerem: tão simples quantopossível, bem separado, com nomes decentes, etc.(Cecília Fernandes)Código bonito é código cujos passos estão todos em ummesmo nível de abstração de forma que eu entendaclaramente o melhor ponto para alterá-lo sem ter queme preocupar se minha mudança gera impactosinesperados. (Hugo Corbucci)
  45. 45. Referências• Code Beauty. Fabio Kon. 2010.• Clean Code. Robert Martin.
  46. 46. OBRIGADO!Mauricio Anichemauricio.aniche@caelum.com.br@mauricioanichehttp://www.aniche.com.brhttp://www.tddnomundoreal.com.br

×