Clean Code - Boas práticas para desenvolvimento
•Transferir como PPTX, PDF•
3 gostaram•40 visualizações
Palestra sobre Clean Code ministrada na Benner em Outubro de 2018. Baseada no livro Clean Code do Uncle Bob (Robert Cecil Martin). Código fonte em: https://github.com/paulohs/CleanCodeSample/
Recomendados
Mais conteúdo relacionado
Semelhante a Clean Code - Boas práticas para desenvolvimento
Semelhante a Clean Code - Boas práticas para desenvolvimento (20)
Clean Code - Boas práticas para desenvolvimento
- 1. Clean Code Boas práticas para desenvolvimento
- 2. Paulo Henrique da Silva • Benner Tecnologia • Desenvolvedor há mais de 20 anos • Graduação em Ciências da computação • Pós em Desenvolvimento de aplicações Web • Hobbies: Astronomia/Fotografia
- 3. Habilidade profissional: • Conhecimento • Trabalho
- 8. Programar não é diferente!
- 9. Escrever código profissional, não é diferente!
- 13. O mundo evolui... Vai ser mais fácil programar... O código vai praticamente sumir... Não é tão difícil assim...
- 15. O código nunca vai sumir…
- 19. Como profissionais devemos evitar o código ruim
- 20. A única maneira de ir mais rápido, é manter o código organizado e legível.
- 21. O que é um código bom?
- 23. ”É um código que faz parecer que a linguagem foi feita para o problema” Ward Cunningham
- 26. • Conversor de CSV para JSON
- 27. Práticas de Clean Code
- 28. • Nomes com propósito • Escolher bons nomes leva tempo, mas economiza mais • Cuide dos seus nomes • Troque-os quando achar melhores • Todos que lerem seu código ficarão agradecidos • Nomes pronunciáveis • Evite informações erradas • Prefixos de tipo • Classes devem ser substantivos (Cliente, Conta, Pagina). Evite palavras como Manager, Data, Info (que também não deve ser verbo) • Classes com mais construtores, devem utilizar factories.
- 29. Evite
- 30. Prefira
- 31. Evite Prefira
- 33. • Funções! • Devem ser pequenas! • Deve fazer apenas uma coisa e fazê-la bem • Respeite o nível de abstração • Mínimo possível de parâmetros, máximo 3. • Um parâmetro booleano, cheiro ruim. • Se precisa passar muita coisa, pense em passar um objeto (não é trapaca) • Evite efeitos colaterais. • Funções devem alterar o estado dos objetos que elas pertencem, não o estado de outros objetos • Evite repetição: DRY. A duplicação é a raiz de todo mal!
- 35. • Comentários no código Não utilize! Comentários são, no máximo, um mal necessário. Exceto: Copyright, Docs de API, etc
- 36. • Formatação • Ferramentas com o Visual Studio já forcam a formatação correta. • Mas se você estiver utilizando uma ferramenta que não força, não quer dizer que não é para formatar. • Evite linhas muito longas • Tenha regras de equipe. • Utilize espaçamento vertical
- 37. • Objetos • Saiba diferenciar estruturas de dados de objetos. • Estruturas de dados são representadas por classes que expõem os dados, sem funções significativas. • Objetos são classes que escondem as informações internas e expõem operações que operam em tais dados • Evite classes que são objetos e estruturas de dados ao mesmo tempo!
- 38. • Classes • Devem ser pequenas! • Devem ter uma única responsabilidade. • Poucas variáveis de instância. Alta coesão: Os métodos da classe devem manipular tentar manipular todas as variáveis da classe. • Quando isso não acontece normalmente tem uma outra classe querendo surgir. • Adote o S.O.L.I.D.
- 40. • Testes de unidade • Código limpo deve estar coberto por testes! • O teste também deve ser limpo, pois ele é a documentação do seu código. • Manutenção de código, vai eventualmente exigir mudança nos testes. • F.I.R.S.T.: • Fast • Idenpendent • Repeatable • Self-Validating • Timely
- 41. • Tratamento de erro • Evite códigos de erro • Utilize exceções, elas deixam o código limpo e legível.
- 42. Evite
- 43. Prefira
- 44. Clean Code na arquitetura
- 45. • Sistemas • Injeção de dependência • Desenvolvimento gradual – deve funcionar desde o início (evolução de uma cidade) • Cross-cutting concenrs • Cache • Persistência • Logs • Transação • Segurança • Regras de negócio • Linguagens de domínio • Otimização de decisões
- 49. • Concorrência • Cuidado com os mitos: • Sempre melhora o desempenho • Projeto não muda ao utilizar threads • Não precisamos nos preocupar com concorrência em containers Web (IIS) • Concorrência correta é complexa! • Bugs de concorrência, não se repetem facilmente • Se precisar utilizer, aqui vão algumas dicas: • Responsabilidade única • Limite o escopo dos dados • Utilize cópia dos dados • Threads independentes • Conheça sua biblioteca. • Seções críticas pequenas
- 50. • Muito mais em…
- 51. SOLID Código legível, flexivel e fácil de manter.
- 52. •Single responsability •Open/closed •Liskov substitution •Interface segregation •Dependency inversion
- 53. Single Responsability ”a class should have only a single responsibility”
- 56. Open/closed principle "software entities … should be open for extension, but closed for modification."
- 58. Liskov substitution "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program."
- 62. Interface segregation "many client-specific interfaces are better than one general- purpose interface."
- 63. Dependency inversion "depend upon abstractions, not concretions."
- 65. Dica final... Lave suas mãos, escove os seus dentes e mantenha o seu código limpo! Código e slides em https://github.com/paulohs/CleanCodeSample
- 67. Obrigado! Paulo Henrique da Silva benner.com.br
Notas do Editor
- Gosto de entender como as coisas funcionam.
- Há duas vertentes para ter habilidade profissional: Conhecimento e trabalho! Não há como ser profissional sem as duas.
- Programar com código limpo, não é diferente...
- Alguns alegam que o fim do código está próximo; que logo todo código será gerado e não mais escrito; e não precisaram mais de programadores, pois as pessoas criarão programas a partir de especificações.
- Bobagem. O código representa os detalhes dos requisitos. Não há como ignorar os detalhes. Eles precisam ser especificados. E especificar detalhadamente os requisitos de modo que uma máquina possa executá-los é programar e tal especificação é o código!
- Na verdade só aumenta...
- Como patrimônio, precisa de cuidados.
- Pessoas já perderam seu emprego por conta de código ruim. Produtos já deixaram de existir por conta de código ruim. Empresas faliram por conta de código ruim. As vezes por conta da pressão, do prazo, acabamos criando código ruim. Estamos cansados de trabalhar num problema. Deixamos para refatorar algo depois. Nosso gerente nos pressiona, as vezes temos medo de ser demitidos e deixamos as coisas pela metade.
- O gerente quer um código bom. Ele vai cobrar o prazo, pois é o trabalho dele. Nós como programadores profissionais temos que proteger o código com a mesma paixão. Se você fosse um médico, e seu cliente exigisse que você se apressasse, que parasse com a higienização das mãos pois demora demais. Você, como médico profissional, o que faria?
- Nós programadores sempre temos um dilema: Sabemos que bagunça no código atrapalha. Mas por causa da pressão nos sentimos forçados a cometer essa bagunças. Mas profissionais sérios sabe que a desorganização do código vai reduzir a velocidade do seu trabalho e você perderá o prazo. A única maneira de ir mais rápido, é manter o código organizado e legível.
- Há brigas por linguagens em todo o lugar. Mas essa afirmação coloca a responsabilidade nas nossas costas. Não é a linguagem que faz os programas parecerem simples. É o programador!
- Isto é um código limpo.
- Injeção de dependências
- Injeção de dependências
- .