• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Clean code
 

Clean code

on

  • 1,288 views

Apresentação sobre temas abortado no livro Clean Code de Robert C. Martim....

Apresentação sobre temas abortado no livro Clean Code de Robert C. Martim.
Os benefícios sobre manter seu código limpo. Quais prejuízos um código sujo pode trazer para sua empresa.
Como se expressar no seu código dispensando o uso de inúmeros comentários que poluem o código.

Statistics

Views

Total Views
1,288
Views on SlideShare
1,035
Embed Views
253

Actions

Likes
2
Downloads
0
Comments
0

3 Embeds 253

http://www.gis4dev.com.br 221
http://mj89sp3sau2k7lj1eg3k40hkeppguj6j-a-sites-opensocial.googleusercontent.com 26
http://www.slashdocs.com 6

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Clean code Clean code Presentation Transcript

    • Clean CodeRobert C. Matin "Honestidade em pequenas coisas não é uma coisa pequena“
    • O que você sente ?O que você sente quando encontra um código ruim ?Você já sentiu raiva de quem fez o código no qual você estátrabalhando ?Já sentiu vontade de apagar tudo o que alguém fez e fazer tudode novo ? “Amarás o teu próximo como a ti mesmo”
    • O que é código limpo ?• Fácil manutenção• Elegante• Eficiente• Legível• Sem duplicações• Simples• Cuidadoso• Feito para o problema• Direto• ProdutividadeEntre muitas outras respostas...
    • 5S na codificação• Seiri (Organização) – Saber onde estão as coisas, nomes adequados.• Seiton(Arrumação) – Um pedaço de código deve estar aonde você espera encontrar.• Seiso(Limpeza) – Local de trabalho cheio de fios, sujeira, comida. Código cheio de comentários desnecessários.• Seiketsu(Padronização) – A equipe está de acordo em manter o local de trabalho limpo?• Shutsuke(Autodisciplina)- Disciplina ao seguir as práticas, refletir frequentemente isso no trabalho e estar disposto a mudar.
    • O custo de um código confuso• Lentidão.• Uma alteração, várias falhas.• Remendos.• Produtividade diminui.• Alocação de mais recursos.
    • Código ruim acabou com aempresa• Empresa tinha um produto extraordinário e popular.• Lançamentos frequentes.• Não corrigiam todos BUGS nas novas versões.• Lentidão.• Travamento.Resultado: Saiu do mercadoMotivo: Código ruim.Apressaram o lançamento das entregas, com isso o código ficou umazona, cada vez era adicionados mais recursos e o códigopiorava, chegou um momento que não era possível mais gerencia-lo.
    • A culpa é de quem ?• Mas e ai, não temos tempo pra ficar refatorando e limpando código, a culpa é da gerencia e do marketing que determina prazos curtos.• Quem estima esforço de desenvolvimento ?• Um produto entregue rápido agrega mais valor do que um produto de qualidade?• Quer economizar tempo no desenvolvimento ? Esse tempo será utilizado em dobro na manutenção.
    • Para pensar...• Uma única janela pode causar a degradação de uma casa.• Tempo gasto na leitura pela escrita é de 10 por 1.• Escoteiros: Deixe a área do acampamento mais limpa do que como você a encontrou.
    • Como identificar um códigosujo ?
    • Nomes significativosNomes estão em todo o código, usamos nomes em tudo. Entãotemos que fazer isso bem feito.Porque ele existe.Como é usado.O que ele faz.Revelem seus propósitos.
    • Nomes significativosint d; //tempo decorrido em dias;Se um nome requer um comentários, ESTÁ ERRADO. O nome deve revelarseu propósito.int elapsedTimeInDays;int daysSinceCreation;int daysSinceModification;int fileAgeInDays;
    • Nomes significativospublic List<int[]> getThem(){ List<int[]> list1 = new ArrayList<int[]>(); for(int[] x : theList) if(x[0] == 4) list1.add(x); return list1;}public List<int[]> getFlaggedCells(){ List<int[]> flaggedCells = new ArrayList<int[]>(); for(int[] cell:gameBoard) if(cell[STATUS_VALUE] == FLAGGED) flaggedCells.add(cell); return flaggedCells;}
    • Nomes significativosCUIDADO !Evite informações erradas, interpretações podem ser diferentes.Ex: accountList – List significa um tipo de variável para programadores, e otipo da variável não deve estar no nome.accountList – accounts , accountGroupintAmount – amountEvite nomes muito parecidos:XZYControllerForEfficientHandlingOfStringsXYZControllerForEfficientStorageOfStrings
    • Nomes significativosEvite o uso de “L” minúsculo e “O” maiúsculo , podem serconfundidos com 1 e 0.Faça distinções significativas, não use sequenciais.public static void copyChars(char a1[], char[] a2){ for(int i=0 ; i< a1.length;i++){ a2[i] = a1[i] ; }}
    • Nomes significativos• Use nomes pronunciáveis, evite usar palavras que não são palavras. class Customer { DtaRcrd102{ private Date private Date genymdhms; generationTimestamp; private Date private Date modymdhms; modificationTimestamp; private final String recordId = "102"; = "102"; private final String pszqint } } Ai vc acessa minha classe customer, eepega oovalor da dtarcd102, pega valor da variavel modymdhms!! variável modificationTimestamp !!
    • Nomes significativos• Nomes passiveis de busca, evite uma letra só.• Não use prefixos de variáveis membro. Ex: m_name.• Classes – substantivos.• Métodos – verbos.• Não use humor, gírias , etc.• Use uma palavra por conceito. (Controller,Manager).• Não use trocadilhos. Palavras que realizem mais de uma ação. Ex: Add(adicionar), Add(concatenar).• Contexto significativo, só utilizar prefixo quando o namespace e classe não resolver.
    • Funções• Devem fazer apenas UMA coisa.• Nomes descritivos - Deve descrever exatamente o que a função faz, não se preocupar em utilizar nomes longos, nomes longos são melhores que comentários longos.• Ler o código de cima para baixo, devem ser ordenadas de forma decrescente.
    • Funções Parâmetros• Quantidade ideal: 0.• Mais de 3 parâmetros somente em casos muitos especiais, dificulta os testes.• Não utiliza booleano, implica que a função faz mais de uma coisa.• Evite parâmetros de saída.• Funções devem fazer ou responder a algo.
    • Funções Evite efeitos colateraisEvitar que sua função implique em alterações em fazer outras coisasalém do que diz fazer:public boolean checkPassword(String userName, String password){ User user = UserGateway.findByName(userName); if(user != User.NULL){ String codedPhrase = user.getPhraseEncodedByPassword(); String phrase = cryptographer.decrypt(codedPhrase,password); if("Valid Password".equals(phrase)) { Session.initialize(); return true; } } return false;}
    • Comentários
    • Comentários• Podem ser uteis se colocados nos lugares certos.• Comentários mentem.• Não recebem manutenção.• Um dos motivos mais comuns para se escrever comentário é código ruim.• Pensou em comentar ? Limpe, refatore antes.
    • Comentários Comentários RUIM• Redundante, explicar o que já está explicito.• Enganadores, utilizados para cobrir gambiarras.• Ruidosos, indicam o óbvio.• Evite comentário se é possível utilizar método ou variável.• Marcadores de posição, usar raramente, acaba se tornando um ruído no código.• Ao lado de chaves de fechamento.• Créditos e autoria.• Explicação de código em comentários.• Comentários em HTML.• Informações excessivas .• Conexões nada óbvias, comentários que devem ser explicados.• JavaDoc em códigos que não são públicos.• Entre outros...
    • Comentários Comentários BOM• Diretos• Fontes externas• Alerta sobre consequências• TODO.• Explicação de intenção• Destaque• JavaDoc em API’S públicas
    • Formatação Vertical• Não é regra mas geralmente classes tem 200 , e no máximo 500 linhas, classes menores são mais fáceis de entender.• Conceitos que estão relacionados devem ficar verticalmente próximos um dos outros. Horizontal• Alguns desenvolvedores sugerem o limite de 120 caracteres por linha.• Identação, ajuda a visualizar o escopo e identificar regras e situações mais rápido.
    • Tratamento de Exceção• Não retorne código de erros.• Lançamento de exceções:  Evita o tratamento de retorno.  Muitos lançamentos podem dificultar a manutenção.• Não retornar null.• Não permitir que null seja passado como parâmetro.• Crie mensagens informativas nas exceções.• Não trate regra de negócios no tratamento de erros.
    • Testes• Garantir que cada pedaço do código está fazendo o esperado.• Leis dos TDD: • Você não pode escrever o código até que você tenha criado um teste falhando. • Você não pode criar mais testes do que seja necessário para falhar. • Você não pode escrever mais código do que o suficiente pra passar o teste que esta falhando.
    • Testes Mantenha seus testes limpos!Os testes precisam sofrer alterações da mesma forma que oscódigos.Quanto mais sujo o teste mais difícil será dar manutenção. Um conceito por teste.Separe um teste que esteja testando mais de um conceito emvários teste.Facilite o entendimento de cada teste.
    • Limites Código de terceiros.Evite passar objetos de API’s adiante, mantenha-o na classe oufamília de classes. Testes de aprendizagem• Realizar testes sobre as API’s de terceiros.• Junto com a documentação da API realizar testes sob as funcionalidades nas quais desejam usar.• Ajudam a aumentar o rendimento, quando há atualização da API basta executar os testes de novo.
    • ClassesSegundo padrões java devem começar com as variáveis.-públicas estáticas e constantes.-privadas estáticas e variáveis.-privadas instancias e variáveis.Funções vem depois das variáveis.
    • ClassesSeguem as mesmas regras dos métodos:1. Devem ser pequenas.2. Devem ser menores ainda. Principio da Responsabilidade única(SRP)Uma classe deve ter apenas 1 responsabilidade.Para analisarmos se o tamanho da classe está ideal devemosmedir a responsabilidade dela.
    • EmergenteRegras básicas para criar um design de código eestrutura, aplicando os conceitos de SRP E DIP.Simple Design de Kent Beck• Rode todos os testes.• Remova duplicação.• Expresse sua intenção.• Diminua o número de classes e métodos.
    • Emergente Rode todos os testesSistemas que não podem ser testados não podem serverificados. Logo, pode-se dizer que um sistema que não podeser verificado jamais deveria ser implementado.Quanto mais testes, mais boas maneiras e princípios seguiremospara evitar o acoplamento de nosso código.
    • EmergenteSem duplicaçãoCódigos iguais ou implementações que fazem a mesma coisa.Principal inimigo para um sistema bem desenvolvido.Representa trabalho, risco e complexidade desnecessária extra.
    • Emergente Expresse sua intençãoMuitos de nós já produzimos e trabalhamos com códigosconfusos, isso porque ao desenvolver pensamos somente no nossoentendimento, nosso conhecimento no problema naquele momento éprofundo, mas e quem vai manter o código conseguirá entender ?• Escolha bons nomes.• Métodos e classes pequenas.• Separe responsabilidades.• Nomenclatura padrão.Reduz os defeitos e custos da manutenção. O próximo pode ser você!
    • EmergenteMenos classes e métodosTentar manter nosso sistema pequeno ao mesmo tempo quemantemos nossos métodos e classes pequenas.Dogmatismo exagerado.Abordagem pragmática.Essa é a ultima das prioridades, a menos importante.
    • Maus Cheiros• Comentários obsoletos e redundantes.• Comentários pobres.• Código comentado.• Testes que requerem mais de um passo.• Muitos parâmetros ou parâmetros boolean.• Métodos mortos ou que fazem muita coisa.• Duplicação.• Inconsistências.• Intenção obscura.
    • Maus Cheiros• Responsabilidades fora de contexto.• Variáveis e funções inexpressivas.• Despadronização.• Números mágicos.• Métodos fazendo mais de uma coisa.• Desencapsulamento.• Nomes pequenos e inexpressivos.• Efeitos colaterais.• Testes insuficientes.
    • Assuma esse compromisso