Clean Code




         Daniel Tamiosso
presentation based on Hendrik Ebel
Tópicos
O que é?
A motivação
Os objetivos
Escolhendo os nomes
Comentários
Métodos
Objetos e estrutura de dados
Tratamento ...
O que é código limpo?
Uma questão...




      fácil manutenção                          cuidadoso
                       ...
A motivação




O custo total para o proprietário de um código bagunçado
Como mensurar?
Os objetivos
Produzir um código melhor
Escrever código para humanos lerem
Reduzir a complexidade
Manter a manutenibilidade...
Escolhendo os nomes
Variáveis, métodos e classes devem responder as seguintes
perguntas:
       Por que isto existe? O que...
Comentários
A principal proposta de um comentário é explanar um código que não
fala por si só
Não use um comentário quando...
Por que não comentar?
Representam sinais de “códigos sujos”. Tente reescrevê-lo antes!
Eles tendem a mentir.
Eles são semp...
Onde jamais comentar
Fechando blocos de códigos
Marcando posições dentro do código fonte
Javadocs não público
Na forma HTM...
Onde podemos comentar
API pública
Avisos para consequências (do tipo: execute-me somente se você
estiver muito tempo dispo...
Métodos
A sua meta é contar um pedaço de uma estória do sistema
Sua maior lei é ser muito pequeno
E fazer SOMENTE uma cois...
Objetos e estrutura de dados
 Use a mesma linguagem do domínio
 Ser apenas uma coisa. E ser mesmo essa coisa.
 Objetos dev...
Tratamento de erros
É um conceito a parte. Trate-o assim.
Use-as sempre exceções ao invés de códigos de retorno
Esqueça as...
Testes unitários
Test Driven Development (TDD)
       Teste e código de produção são escritos juntos
       Os testes apen...
Arquitetura
Como a construção de uma cidade: incremental e modular
Big Design Up Front (BDUF) inibe a adaptabiliade do sis...
Design
A melhor definição: emergente, nunca final
Simples. Lembre-se sempre
       SRP, DRY, OCP e Fluent Interfaces
     ...
Programação em Par




Após ajustados, os pares produzem código 15% mais lento que
          um desenvolvedor de forma ind...
Programação em Par




   ... mas com 15% a menos de defeitos.
Maus cheiros
Comentários obsoletos e redundantes
Builds com mais de um passo e duração maior que 10 minutos
Testes que req...
Como chegar lá?
1. Torne escrever código limpo parte do seu processo pessoal.
           Atenção contínua para uma excelên...
Finalizando
“Complexity kills. It sucks the life out of developers, it
makes products difficult to plan, build and test......
Upcoming SlideShare
Loading in...5
×

Clean Code

2,856

Published on

Apresentação sobre o que é um código limpo e como fazê-lo.

Published in: Technology
1 Comment
7 Likes
Statistics
Notes
  • 'O número ideal de argumentos é ZERO O máximo é TRÊS' ... não seria 'DOIS' no máximo? mas acredito q vc deva ter um bom motivo pra citar 3 (caso tenha sido proposital), qual seria?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,856
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide

Clean Code

  1. 1. Clean Code Daniel Tamiosso presentation based on Hendrik Ebel
  2. 2. Tópicos O que é? A motivação Os objetivos Escolhendo os nomes Comentários Métodos Objetos e estrutura de dados Tratamento de erros Testes unitários Arquitetura Design Programação em par Maus cheiros Como chegar lá?
  3. 3. O que é código limpo? Uma questão... fácil manutenção cuidadoso legível elegante feito para o problema sem duplicações eficiente simples ... muitas respostas!
  4. 4. A motivação O custo total para o proprietário de um código bagunçado
  5. 5. Como mensurar?
  6. 6. Os objetivos Produzir um código melhor Escrever código para humanos lerem Reduzir a complexidade Manter a manutenibilidade do código ao longo do tempo Idealizar a produção de software como uma tarefa artesanal Software não só para o cliente mas também para o desenvolvedor Uma lei escoteira: Deixar o local do acampamento, no mínimo, mais limpo do que quando você o encontrou.
  7. 7. Escolhendo os nomes Variáveis, métodos e classes devem responder as seguintes perguntas: Por que isto existe? O que isto faz? Como isto é usado? Se o nome escolhido requer um comentário, então o nome não está revelando sua intenção. Evite desinformação Use uma nomenclatura de domínio Se usou algum padrão de projeto, identifique-o Prefira nomes pronunciáveis. Humanos são bons com palavras. Evite o uso de encodings. Evite a mesma palavra para dois conceitos distintos Habilidades em dar nomes vão muito além do conhecimento técnico. Faz parte da cultura do desenvolvedor. E realmente faz diferença.
  8. 8. Comentários A principal proposta de um comentário é explanar um código que não fala por si só Não use um comentário quando você pode usar um método ou uma variável Comentários podem se tornar mentirosos Mas, lembre-se: comentários muitas vezes são um mal necessário
  9. 9. Por que não comentar? Representam sinais de “códigos sujos”. Tente reescrevê-lo antes! Eles tendem a mentir. Eles são sempre falhas de um código que não explanam sua intenção. Com certeza eles não vão melhorar seu código. Esqueça isso.
  10. 10. Onde jamais comentar Fechando blocos de códigos Marcando posições dentro do código fonte Javadocs não público Na forma HTML Em redundância public Carro(){} // default constructor
  11. 11. Onde podemos comentar API pública Avisos para consequências (do tipo: execute-me somente se você estiver muito tempo disponível!) TODO “reais” Comentários de origem legal
  12. 12. Métodos A sua meta é contar um pedaço de uma estória do sistema Sua maior lei é ser muito pequeno E fazer SOMENTE uma coisa O número ideal de argumentos é ZERO O máximo é TRÊS Evite argumentos ao estilo FLAG (booleanos) Command And Query Separation
  13. 13. Objetos e estrutura de dados Use a mesma linguagem do domínio Ser apenas uma coisa. E ser mesmo essa coisa. Objetos devem esconder seus dados e expor operações Estrutura de dados devem expor os dados e não devem possuir operações significativas
  14. 14. Tratamento de erros É um conceito a parte. Trate-o assim. Use-as sempre exceções ao invés de códigos de retorno Esqueça as exceções checadas. Use e abuse das não checadas Nunca retorne NULL retorne uma exceção especial ou de preferência algo como Collections.emptyList() Ah! E nunca passe NULL InvalidArgumentException ou assert Ou melhor: proíba a passagem de NULL como padrão
  15. 15. Testes unitários Test Driven Development (TDD) Teste e código de produção são escritos juntos Os testes apenas alguns segundos antes O código de teste é tão importante quanto código de produção E devem ser tão limpos quanto eles Um método de teste deve testar apenas uma coisa (um assert) ou um conceito FIRST As três leis Fast Você não deve escrever qualquer Independent implementação antes que você tenha escrito Repeatable um teste que falhe Self-Validation Você não deve escrever mais que um teste Timely unitário para demonstrar uma falha Você não deve escrever mais do que o necessário para passar por um teste que está falhando
  16. 16. Arquitetura Como a construção de uma cidade: incremental e modular Big Design Up Front (BDUF) inibe a adaptabiliade do sistema e é invasiva Normalmente resulta na frase: “Uma bazooka pra matar uma mosca” Com isso temos muitas decisões pequenas ao invés de poucas e arriscadíssimas decisões As tecnologias devem aparecer por demanda. Jamais por insegurança futura Pode ser um padrão ou possuir uma bela API. Se ela não for necessária, será extremamente danosa. Assim como o código em geral, deve ser colaborativa.
  17. 17. Design A melhor definição: emergente, nunca final Simples. Lembre-se sempre SRP, DRY, OCP e Fluent Interfaces YAGNI - You Aren’t Gonna Need It Design Patterns Filosofia Unix Princípios de OO Lei de Demeter Um método ou objeto deveria chamar apenas: ele mesmo; qualquer composição, qualquer parâmetro passado e qualquer objeto criado por ele Expressivo e refatorado constante Ah! Testes não mentem Avalie dia-a-dia. Evite chegar a um ponto sem retorno.
  18. 18. Programação em Par Após ajustados, os pares produzem código 15% mais lento que um desenvolvedor de forma individual...
  19. 19. Programação em Par ... mas com 15% a menos de defeitos.
  20. 20. Maus cheiros Comentários obsoletos e redundantes Builds com mais de um passo e duração maior que 10 minutos Testes que requerem mais que um passo Muitos argumentos e argumentos booleanos Métodos esquecidos e métodos que fazem tudo Muitos idiomas em um código fonte Duplicação Nomes que não representam intenção Polimorfismo é deixado de lado por If/Else e Switch/Case Números mágicos e condicionais negativos Longas listas de imports e variáveis de instância Constantes ao invés de enumerações Testes insuficientes (não fuja dos testes triviais)
  21. 21. Como chegar lá? 1. Torne escrever código limpo parte do seu processo pessoal. Atenção contínua para uma excelência técnica em um bom desing melhoram a agilidade da equipe. 2. Aprenda como escrever código limpo. Escrever código limpo é como realizar qualquer outro tipo de trabalho. Requer prática, criticismo e mais prática. 3. Valorize código limpo.
  22. 22. Finalizando “Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test... Each of us should ... explore and embrace techniques to reduce complexity” Ray Ozzie, Chief Technology Officer, Microsoft Corporation Clean code por Robert C. Martin Series

×