Seu código é limpo? - Caipyra (São Carlos - SP)

Transcript

1. Técnicas de como fazer um código profissional baseado no livro “Clean Code” Seu código é limpo?
2. Guilherme José Acra Desenvolvedor e líder do squad de mineração no Sigalei Sobre mim @gacra guilherme.acra@sigalei.com.br
3. Introdução
4. • Ambiente profissional: ◦ Responsabilidade ◦ Trabalho em equipe ◦ Trabalhar em códigos desenvolvidos por outras pessoas e em outra época
5. Código limpo
6. Código limpo
7. Introdução • Ao desenvolver o código, pensar em quem vai se deparar com ele no futuro (manutenção) • Faça um código limpo!
8. Código Limpo?
9. Código limpo • Código limpo é um código prazeroso de se ler, como se estivéssemos lendo um bom livro • Deve contar uma história: ◦ O conflito: problema a ser resolvido ◦ A jornada: passos para a solução ◦ A resolução: um retorno ou uma ação do sistema
10. Código limpo • Somos autores e temos que nos preocupar com nosso público: ◦ Atenção aos detalhes ◦ Não ficar enrolando ◦ Não enganar ◦ Fácil de ler
11. Código sujo • Se preocupar em fazer um código limpo não é perda de tempo • Um código ruim diminui a produtividade do time com o tempo ◦ Os desenvolvedores ficam vadiando pelo código tentando entender… • O único jeito de cumprir os prazos, de ir rápido, é mantendo o código o mais limpo possível
12. Código sujo • Gaste Invista um tempo para refatorar o código • Um código fácil de ler é um código fácil de modificar • Manter o código legível é tão importante quanto fazê-lo executar
13. The Zen of Python Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
14. The Zen of Python Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
15. The Zen of Python • Python é uma linguagem que, por si só, facilita a leitura
16. Nomes significativos
17. Nomes significativos • Nomes são tudo em um código ◦ Nomeamos variáveis, funções, argumentos, classes, módulos, pacotes… • Já que fazemos muito, devemos fazer bem • O nome de uma entidade deve deixar claro o que ela é, porque ela existe, o que ela faz e/ou como é usada
18. Nomes significativos
19. Nomes significativos
20. Nomes significativos
21. Nomes significativos
22. • Não usar uma letra só Nomes significativos
23. • Não usar uma letra só • Um comentário não substitui um bom nome Nomes significativos
24. • Não usar uma letra só • Um comentário não substitui um bom nome Nomes significativos
25. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado Nomes significativos
26. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado Nomes significativos
27. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado Nomes significativos
28. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado • Evitar colocar o tipo da variável no nome Nomes significativos
29. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado • Evitar colocar o tipo da variável no nome Nomes significativos
30. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado • Evitar colocar o tipo da variável no nome • Evitar informação desnecessária Nomes significativos
31. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado • Evitar colocar o tipo da variável no nome • Evitar informação desnecessária Nomes significativos
32. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado • Evitar colocar o tipo da variável no nome • Evitar informação desnecessária • Não usar nomenclatura tipo “série numérica” Nomes significativos
33. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado • Evitar colocar o tipo da variável no nome • Evitar informação desnecessária • Não usar nomenclatura tipo “série numérica” Nomes significativos
34. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado • Evitar colocar o tipo da variável no nome • Evitar informação desnecessária • Não usar nomenclatura tipo “série numérica” • Não usar nomes engraçadinhos Nomes significativos
35. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado • Evitar colocar o tipo da variável no nome • Evitar informação desnecessária • Não usar nomenclatura tipo “série numérica” • Não usar nomes engraçadinhos Nomes significativos
36. • Não usar uma letra só • Um comentário não substitui um bom nome • Não usar nomes consagrados por outro significado • Evitar colocar o tipo da variável no nome • Evitar informação desnecessária • Não usar nomenclatura tipo “série numérica” • Não usar nomes engraçadinhos Nomes significativos
37. Nomes significativos • Entidades semelhantes devem ter nomes semelhantes, mas não tão semelhantes a ponto de confundir o leitor em uma leitura rápida
38. Nomes significativos • Entidades semelhantes devem ter nomes semelhantes, mas não tão semelhantes a ponto de confundir o leitor em uma leitura rápida
39. • Defina padrões e permaneça com eles ◦ Use termos iguais para conceitos iguais e termos diferentes para conceitos diferentes Nomes significativos
40. • Defina padrões e permaneça com eles ◦ Use termos iguais para conceitos iguais e termos diferentes para conceitos diferentes Nomes significativos
41. • Nomes de classes e objetos devem ser substantivos • Nomes de funções/métodos devem ser verbos ◦ Usar “get” para obter um recurso e “is” para retornos booleanos Nomes de classes/objetos e métodos/funções
42. Funções (ou métodos)
43. Boas funções • Funções devem ser pequenas ◦ 2 a 5 linhas é o ideal, mais de 20 é exagero ◦ Blocos com “if”, “else”, “for” devem ter o mínimo de linhas possível (apenas 1 se der), ou seja, devem haver outras funções dentro desses blocos ◦ Não deve haver mais de 2 níveis de indentação
44. Boas funções • Uma função deve fazer uma coisa. E fazer bem. E só! • Funções que fazem mais de uma coisa devem ser quebradas em duas ou mais outras funções
45. Boas funções • Deve dar pra entender completamente o que a função faz (e quais são os argumentos e retornos) só pelo seu nome ◦ A função não deve fazer mais do que ela diz que faz (não deve ter efeitos colaterais) • Não deve haver repetição de código ◦ Usar funções para resolver isso
61. Ordenação das funções • As funções devem ser organizadas para que se dê para ler o código como em um artigo de jornal: de cima para baixo ◦ Uma função que é chamada por outra deve estar logo abaixo daquela que a chama ◦ Evita ter que ficar rolando a página para cima e para baixo ◦ Deve dar para ler como sentenças que comecem com “Para…”
65. Argumentos e retornos • Quanto menos argumentos uma função tiver, melhor ◦ Mais que 3 argumentos já é um exagero ◦ Muitos argumentos deixam as linhas longas e tendemos a esquecer em que ordem eles aparecem • O que pode ser feito: ◦ Ao invés de usar um argumento de flag (booleano), criar 2 métodos ◦ Usar mais atributos de objetos (self) ◦ Usar objetos como argumentos
66. Argumentos e retornos
67. Argumentos e retornos
68. Argumentos e retornos
69. Argumentos e retornos • Uma função não deve retornar muitas coisas, prefira retornar um objeto, se for o caso. • Não altere objetos que são argumentos ◦ Argumentos são entradas, retornos são saídas
70. Comentários
71. Comentários • “Não comente um código ruim, reescreva-o” ◦ Comentários não são a solução para um código sujo • O código deve ser capaz de se expressar sozinho (ele é a verdade absoluta)
72. Comentários • Comentários são ruins, pois eles, não raramente, estão mentindo ◦ Falta de cuidado de quem escreveu ◦ O comentário ficou velho (código foi alterado, mudado de lugar ou apagado) • Tente ao máximo não precisar de comentários
73. Funções que substituem um comentário
74. Funções que substituem um comentário
75. Funções que substituem um comentário
76. Comentários bons • Comentários legais (ex: direito de cópia) ◦ Não faça extenso, não faça do código um contrato, cite documentos externos
77. Comentários bons • Explicação de intenção ◦ Não é explicar o que o código está fazendo, mas porque ele está fazendo dessa maneira
78. Comentários bons • Explicação de intenção ◦ Não é explicar o que o código está fazendo, mas porque ele está fazendo dessa maneira
79. Comentários bons • Explicação de intenção ◦ Não é explicar o que o código está fazendo, mas porque ele está fazendo dessa maneira
80. Comentários bons • Explicação do funcionamento de bibliotecas externas • Docstrings para APIs públicas
81. Comentários ruins • Pedaços de código comentado ◦ Provavelmente nunca mais vai ser usado, mas vai ficar no código para sempre, pois quem for ler não vai ter coragem de apagar ◦ O GIT serve para isso!!
82. Formatação
83. Formatação • Os arquivos também não devem ser grandes (ideal é de 200 a 500 linhas) ◦ Ninguém se anima de ler um artigo imenso no jornal • Prefira linhas curtas ◦ Não deve ser necessário rolar a tela para o lado ◦ PEP 8 fala em 79 caracteres
84. Formatação
85. Formatação
86. Formatação
87. Formatação
88. Formatação
89. Formatação • Separar imports/classes/métodos com linhas em branco • Cercar operador de atribuição com espaços • Separar argumentos com espaços • Usar espaço para acentuar precedência de operadores matemáticos
90. Formatação
91. Formatação • O mais importante é que o grupo de programadores entre em um acordo sobre a formatação • O uso de ferramentas automática de formatação ajuda muito (IDE, yapf, isort, pylint)
92. Dicas finais
93. • Não tem problema fazer o código rápido para ver ele funcionar • Mas para dizer que a tarefa está feita é necessário refatorar para torná-lo limpo • Ao trabalharmos com código já existente, temos que deixar ele mais limpo do que quando chegamos • Pratique!!
94. Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best.
95. Obrigado! Guilherme José Acra @gacra guilherme.acra@sigalei.com.br