Clean Code para Front Enders

Já parou para pensar na qualidade do código que você desenvolve? Nesta palestra, vamos apresentar, de forma simples e com exemplos, conceitos de Clean Code e mostrar por que você deve aplicá-los nos seu dia-a-dia.

Transcript

1. Clean Code Para Front Enders @weslley_neri
8. Custo de um código ruim 80% do que fazemos em um software é reparo de erros
9. O que é Clean Code
10. “Gosto do meu código elegante e eficiente. A lógica deve ser direta para dificultar o encobrimento de bugs.” Bjarne Stroustrup - Criador do C++
11. “Você sabe que esta criando um código limpo quando cada rotina que leia se mostrar como o que você esperava.” Ward Cunningham - Criador do XP e um dos signatários originais do Manifesto Ágil
12. A regra do escoteiro Deixe a área do acampamento mais limpa do que como você a encontrou.
13. 6 pontos importantes sobre Clean Code para um Front End
14. 1 - Nomes Significativos
15. Use nomes que revelam sua intenção “Se um nome requer um comentário, então ele não revela sua intenção” - Porque existe - O que faz - Como é usado
16. Use nomes buscáveis Evite usar variáveis com apenas uma letra Usar apenas como variáveis de controle (For) Use nomes pronunciáveis
17. Não dê uma de espertinho Opte por clareza no lugar de divertimento
18. 2 - Funções
19. Não crie funções Megazord
20. Funções devem ser pequenas A primeira regra de funções é que elas devem ser pequenas Se não conseguimos dar um nome sucinto a uma função, então provavelmente ela é grande demais. A segunda regra é que ela devem ser menores ainda
21. Use nomes descritivos Não tenha medo de dar um nome longo a uma função
 
 Um nome longo e descritivo é melhor que um curto e enigmático Um nome longo e descritivo é melhor que um comentário
22. KISS
23. KISS Keep It Simple, Stupid Simples de Entender
 Simples de Usar Simples de Reusar Simples de extender Keep It Stupid Simple
24. DOT Do One Thing Do One Thing And Do It Well
25. Como saber ? É possível extrair outra função com um nome que não seja uma reafirmação da implementação inicial ? “Se uma função executa passos que estão a apenas um nível de abstração abaixo do seu nome, então a função faz apenas uma coisa.” “Funções que fazem apenas uma coisa não podem ser divididas em seções."
26. DRY
 Don’t Repeat Yourself
28. 3 - Comentários
29. "Não comente código ruim - reescreva-o" "O uso adequado dos comentários é compensar a nossa incapacidade de expressar-se em código." "Os comentários imprecisos são muito piores do que nenhum comentário. A verdade só pode ser encontrada em um só lugar: o código ".
30. Comentários Bons Comentários legais como copyright TODO’s Amplificar importância Alertar sobre consequências
31. Comentários Ruins Redundância Comentários obrigatórios
32. Comentários Ruins Reafirmam o óbvio
33. Comentários Ruins Código comentado Quem encontrar um trecho de código comentado não vai ter coragem de deletá- lo. Podem pensar que é algo importante. Pratique o desapego. Temos ferramentas de controle de versão para isso.
34. 4 - Formatação
35. Funções Dependentes Se uma função chama outra, elas devem estar próximas verticalmente, e a função que chama deve estar acima da que é chamada, se possível. Isso dá a seu código um fluxo natural.
36. Indentação "Sem indentação, programas seria praticamente ilegível por seres humanos"
37. 5- Testes
38. Era uma vez uma equipe
39. … que não se importava com a qualidade dos códigos de teste
40. Com o passar das releases o custo de manter o app só aumentava
41. até que tiveram que descartar o app inteiro
42. Moral da história Manter um bom código de testes é tão importante quando manter o código do app "Ter testes sujos é equivalente a, se não pior do que, não ter testes."
43. Conclusão
44. "Qualquer tolo pode escrever código que um computador possa entender. Bons programadores escrevem código que os seres humanos podem entender." - Martin Fowler
45. Obrigado @weslley_neri