Clean code
5 gostaram1,070 visualizações
O documento aborda a importância de escrever código limpo, enfatizando a manutenção, legibilidade e eficiência. Discute os custos de um código confuso e recomenda práticas como nomes significativos, funções concisas e a importância de testes. Também destaca que um bom design de código deve seguir princípios como a responsabilidade única e evitar duplicações.
![Nomes significativos
public 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;
}](https://image.slidesharecdn.com/cleancode-120620064033-phpapp01/85/Clean-code-12-320.jpg)
![Nomes significativos
Evite o uso de “L” minúsculo e “O” maiúsculo , podem ser
confundidos 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] ;
}
}](https://image.slidesharecdn.com/cleancode-120620064033-phpapp01/85/Clean-code-14-320.jpg)
Clean code
- 1. Clean Code Robert C. Matin "Honestidade em pequenas coisas não é uma coisa pequena“
- 2. 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 tudo de novo ? “Amarás o teu próximo como a ti mesmo”
- 3. O que é código limpo ? • Fácil manutenção • Elegante • Eficiente • Legível • Sem duplicações • Simples • Cuidadoso • Feito para o problema • Direto • Produtividade Entre muitas outras respostas...
- 4. 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.
- 5. O custo de um código confuso • Lentidão. • Uma alteração, várias falhas. • Remendos. • Produtividade diminui. • Alocação de mais recursos.
- 6. Código ruim acabou com a empresa • 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 mercado Motivo: Código ruim. Apressaram o lançamento das entregas, com isso o código ficou uma zona, cada vez era adicionados mais recursos e o código piorava, chegou um momento que não era possível mais gerencia-lo.
- 7. 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.
- 8. 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.
- 9. Como identificar um código sujo ?
- 10. Nomes significativos Nomes estão em todo o código, usamos nomes em tudo. Então temos que fazer isso bem feito. Porque ele existe. Como é usado. O que ele faz. Revelem seus propósitos.
- 11. Nomes significativos int d; //tempo decorrido em dias; Se um nome requer um comentários, ESTÁ ERRADO. O nome deve revelar seu propósito. int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays;
- 12. Nomes significativos public 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; }
- 13. Nomes significativos CUIDADO ! Evite informações erradas, interpretações podem ser diferentes. Ex: accountList – List significa um tipo de variável para programadores, e o tipo da variável não deve estar no nome. accountList – accounts , accountGroup intAmount – amount Evite nomes muito parecidos: XZYControllerForEfficientHandlingOfStrings XYZControllerForEfficientStorageOfStrings
- 14. Nomes significativos Evite o uso de “L” minúsculo e “O” maiúsculo , podem ser confundidos 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] ; } }
- 15. 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 !!
- 16. 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.
- 17. 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.
- 18. 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.
- 19. Funções Evite efeitos colaterais Evitar que sua função implique em alterações em fazer outras coisas alé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; }
- 20. Comentários
- 21. 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.
- 22. 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...
- 23. 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
- 24. 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.
- 25. 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.
- 26. 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.
- 27. Testes Mantenha seus testes limpos! Os testes precisam sofrer alterações da mesma forma que os có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 em vários teste. Facilite o entendimento de cada teste.
- 28. Limites Código de terceiros. Evite passar objetos de API’s adiante, mantenha-o na classe ou famí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.
- 29. Classes Segundo 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.
- 30. Classes Seguem 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 devemos medir a responsabilidade dela.
- 31. Emergente Regras básicas para criar um design de código e estrutura, 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.
- 32. Emergente Rode todos os testes Sistemas que não podem ser testados não podem ser verificados. Logo, pode-se dizer que um sistema que não pode ser verificado jamais deveria ser implementado. Quanto mais testes, mais boas maneiras e princípios seguiremos para evitar o acoplamento de nosso código.
- 33. Emergente Sem duplicação Có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.
- 34. Emergente Expresse sua intenção Muitos de nós já produzimos e trabalhamos com códigos confusos, isso porque ao desenvolver pensamos somente no nosso entendimento, 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ê!
- 35. Emergente Menos classes e métodos Tentar manter nosso sistema pequeno ao mesmo tempo que mantemos nossos métodos e classes pequenas. Dogmatismo exagerado. Abordagem pragmática. Essa é a ultima das prioridades, a menos importante.
- 36. 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.
- 37. 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.