• Save
Clean Code
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Clean Code

  • 4,465 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • '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?
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
4,465
On Slideshare
3,684
From Embeds
781
Number of Embeds
18

Actions

Shares
Downloads
0
Comments
1
Likes
7

Embeds 781

http://danieltamiosso.com 635
http://www.danieltamiosso.com 37
http://webmail.grupocruzeirodosul.com 19
http://www.micromolas.com.br 15
http://visur.com.br 14
http://www.grupocruzeirodosul.com 11
http://www.visur.com.br 8
http://www.studiourbano.com.br 8
http://micromolas.com.br 8
http://www.slideshare.net 6
http://eaubranding.com 5
http://216.154.216.80 5
http://mail.mecasei.com 3
http://studiourbano.com.br 2
http://tarrasconi.com.br 2
http://oldschool 1
http://www.tarrasconi.com.br 1
http://feeds.feedburner.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Clean Code Daniel Tamiosso presentation based on Hendrik Ebel
  • 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. 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. A motivação O custo total para o proprietário de um código bagunçado
  • 5. Como mensurar?
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Programação em Par Após ajustados, os pares produzem código 15% mais lento que um desenvolvedor de forma individual...
  • 19. Programação em Par ... mas com 15% a menos de defeitos.
  • 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. 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. 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