Baixar para ler offline
Carregado porPaulo Henrique da Silva
Clean Code - Boas práticas para desenvolvimento
O documento discute boas práticas de 'clean code' em desenvolvimento de software, enfatizando a importância de escrever código organizado, legível e com um design coerente. Destaca princípios como a responsabilidade única para classes, a necessidade de evitar duplicação, e a importância de testes unitários limpos e abrangentes. Conclui recomendando a aplicação de princípios SOLID e a manutenção constante da qualidade do código.
Clean Code - Boas práticas para desenvolvimento
- 1. Clean Code Boas práticaspara desenvolvimento
- 2. Paulo Henrique daSilva • 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.
- 8. Programar não édiferente!
- 9. Escrever código profissional,não é diferente!
- 13. O mundo evolui... Vaiser mais fácil programar... O código vai praticamente sumir... Não é tão difícil assim...
- 15. O código nuncavai sumir…
- 16.
- 19. Como profissionais devemos evitaro código ruim
- 20. A única maneirade ir mais rápido, é manter o código organizado e legível.
- 21. O que éum código bom?
- 23. ”É um códigoque faz parecer que a linguagem foi feita para o problema” Ward Cunningham
- 26. • Conversor deCSV para JSON
- 27.
- 28. • Nomes compropó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.
- 30.
- 31.
- 33. • Funções! • Devemser 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 nocódigo Não utilize! Comentários são, no máximo, um mal necessário. Exceto: Copyright, Docs de API, etc
- 36. • Formatação • Ferramentascom 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 • Saibadiferenciar 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 • Devemser 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 deunidade • 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 deerro • Evite códigos de erro • Utilize exceções, elas deixam o código limpo e legível.
- 42.
- 43.
- 44. Clean Code naarquitetura
- 45. • Sistemas • Injeçãode 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 • Cuidadocom 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 maisem…
- 51. SOLID Código legível, flexivele fácil de manter.
- 52. •Single responsability •Open/closed •Liskov substitution •Interfacesegregation •Dependency inversion
- 53. Single Responsability ”a classshould 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 aprogram should be replaceable with instances of their subtypes without altering the correctness of that program."
- 62. Interface segregation "many client-specificinterfaces are better than one general- purpose interface."
- 63. Dependency inversion "depend uponabstractions, not concretions."
- 65. Dica final... Lave suasmã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 daSilva benner.com.br
Notas do Editor
- #3 Gosto de entender como as coisas funcionam.
- #4 Há duas vertentes para ter habilidade profissional: Conhecimento e trabalho! Não há como ser profissional sem as duas.
- #10 Programar com código limpo, não é diferente...
- #14 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.
- #15 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!
- #16 Na verdade só aumenta...
- #18 Como patrimônio, precisa de cuidados.
- #19 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.
- #20 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?
- #21 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.
- #24 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!
- #26 Isto é um código limpo.
- #47 Injeção de dependências
- #48 Injeção de dependências
- #55 .