Codigo limpo

2.150 visualizações

Publicada em

Apresentação feita para a disciplina Projeto de Software, sobre o tema código limpo. O conceito Código limpo prega várias boas práticas de programação com o intuito de deixar o código eficiente e com fácil compreensão mesmo quando lido por programadores menos experientes. Nossa apresentação foi baseada no livro Código Limpo, o qual é melhor descrito nas referências bibliográficas.

Publicada em: Educação
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.150
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
68
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Codigo limpo

  1. 1. Código limpo Diego Magalhães Cunha Gustavo MoreiraTauan Nascimento Almeida
  2. 2. Introdução
  3. 3. O custo de ter um código confuso● Ao longo de um certo tempo de trabalho, equipes que trabalham rapidamente no inicio de um projeto podem perceber mais tarde que estão indo a passos de tartaruga.● Cada alteração feita no código causa uma falha em outras duas ou tres partes do mesmo código.
  4. 4. O custo de ter um código confuso● Mudança alguma é trivial.● Cada adição ou modificação ao sistema exige que restaurações, amarrações e remendos sejam "entendidas" de modo que outras possam ser incluidas.
  5. 5. O custo de ter um código confuso● Com o tempo, a bagunça se torna tão grande e profunda que não dá para arrumá- la.● Não há absolutamente solução alguma.
  6. 6. O grande replanejamento● No final, a equipe se rebela.● Todos informam à gerência que não conseguem mais trabalhar neste irritante código-fonte e exigem um replanejamento do projeto.
  7. 7. O grande replanejamento● Apesar de a gerência não querer gastar recursos em uma nova remodelação, ela não pode negar que a produtividade está péssima.● No final das contas, ela acaba cedendo às exigências dos desenvolvedores e autoriza o grande replanejamento desejado.
  8. 8. O grande replanejamento● É, então , formada uma nova equipe especializada.● Por ser um projeto inteiramente novo, todos querem fazer parte dessa equipe.● Eles desejam começar do zero e criar algo belo de verdade.
  9. 9. O grande replanejamento● Mas apenas os melhores e mais brilhantes são selecionados e os outros deverão continuar na manutenção do sistema atual.● Agora ambos os times estão numa corrida.
  10. 10. O grande replanejamento● A nova equipe precisa construir um novo sistema que faça o mesmo que o antigo, além de ter de ser manter atualizada em relaçao às mudanças feitas constantemente no sistema antigo.● Este, a gerencia não substuirá até que o novo possa fazer tudo também.
  11. 11. O grande replanejamento● Essa corrida pode durar um bom tempo. Já vi umas levarem 10 anos.● E, quando ela termina, os membros originais da nova equipe já foram embora há muito tempo, e os atuais exigem o replanejamento de um novo sistema, pois está tudo uma zona novamente.
  12. 12. O grande replanejamento● Se você já vivenciou pelo menos um pouco dessa situação, entao sabe que dedicar tempo para limpar seu código nao é apenas eficaz em termos de custo, mas uma questão de sobrevivencia profissional.
  13. 13. O problema do prazo● Todos os gerentes protegem os prazos e os requisitos, mas essa é a função deles.● A sua, é proteger o código.
  14. 14. O problema do prazo● Por mais que os prazos estejam estourados, preze por um código bem feito, bem escrito.● Imagine se você fosse um médico e seu paciente (seu chefe, neste contexto) exigisse que você não lavasse suas mãos antes de uma operação devido a perda de tempo.
  15. 15. O problema do prazo● É óbvio que você não dará ouvidos a este paciente.● Da mesma forma, em alguns momentos, o atraso é aceitável levando em consideração as consequências.
  16. 16. Mas afinal, o que é ou como é um código limpo?
  17. 17. O que é ou como é um códigolimpo?● Existem várias definições.● Vamos citar algumas definições dadas por alguns dos pioneiros neste assunto.
  18. 18. Bjarne StroustrupGosto do meu código elegante e eficiente. Alógica deve ser direta para dificultar oencobrimento de bugs, as dependênciasmínimas para facilitar a manutenção, otratamento de erros completo de acordo comuma estratégia clara e o desempenho próximodo mais eficiente de modo a não incitar aspessoas a tornarem o código confuso comotimizações sorrateiras.O código deve proporcionar uma leituranatural.
  19. 19. Grady BoochUm codigo limpo é simples e direto. Ele é tãobem legível quanto uma prosa bem escrita.Ele jamais torna confuso o objetivo dodesenvolvedor, em vez disso, ele está repletode abstrações claras e linhas de controleobjetivas.
  20. 20. Dave ThomasAlem de seu criador, um desenvolvedor pode ler emelhorar um código limpo.Ele tem:- teste de unidade e de aceitação,- nomes significativos,- oferece apenas uma maneira, e não várias, de se fazeruma tarefa;- possui poucas dependências, as quais são explicitamentedeclaradas,- oferecem uma API mínima e clara.
  21. 21. Dave ThomasO código deve ser inteligivel já que dependendo dalinguagem, nem toda informação necessária pode serexpressa no código em si.
  22. 22. Nomes Significativos● Nomes são peças chaves em um código ○ Variáveis, classes, métodos, ...● Devem nos dizer três coisas ○ Porque existem ○ O que fazem ○ Como são usados
  23. 23. Dicas para bons nomes● Distinções significativas ○ Nomes como a1, a2, a3, ..., não dizem nada sobre a variável, método, etc.● Não usar trocadilhos ou abreviações ○ O nome deve ser auto-explicativo.
  24. 24. Métodos e Funções "A primeira regra dos métodos é que eles devem ser pequenos, a segunda é que eles devem ser menores ainda. "
  25. 25. Métodos e Funções● Conter no máximo 20 linhas● Nível de identação não pode ser maior que 2● Receber o mínimo de parâmetros possível ○ Receber muitos parâmetros dificulta o Teste Unitário● Somente uma responsabilidade
  26. 26. Métodos e Funções● Exemplo public boolean checkPassword(String username, String password) { String passwordStatus = cryptographer.decrypt (password); if(passwordStatus.equals(“OK”) ) { Session.initialize(); return true; } return false; }
  27. 27. Comentários● São úteis quando colocados nos locais certos ○ Informar uma consequência ○ Explicar uma decisão tomada● O principal motivo para se escrever um comentário é um código ilegível "Explique-se no código."
  28. 28. Formatação● Forma de comunicação do desenvolvedor● Leitores entenderam o que estão lendo● Auxilia mudanças futuras
  29. 29. Dicas para formatação● Não escreva classes com mais de 500 linhas ○ Classes menores são mais fáceis de se entender● Estabeleça um limite sensato para o tamanho de uma linha● Faça uma boa identação ○ Não deixe seu código grudado
  30. 30. Tratamento de erros● Não exagerar no tratamento de erros ○ Não é possível enxergar objetivo do código● Use exceções ○ Linguagens antigas retornavam códigos de erro● Forneça exceções com contexto ○ Mensagens passadas juntamente com a exceção, como tipo de falha
  31. 31. Testes Unitários (TDD - Test Driven Development)● É uma técnica de desenvolvimento de software que baseia em pequenos ciclos de repetições;● Para cada funcionalidade do sistema é criado um teste antes;● Esse teste deverá falhar, pois não temos nenhuma funcionalidade;● Logo após fazemos o teste passar implementando a funcionalidade.
  32. 32. Motivos para o uso do TDD● Feedback rápido sobre a nova funcionalidade e sobre as outras funcionalidades existentes no sistema;● Código é mais limpo, já que escrevemos códigos simples para o teste passar;● Segurança no Refactoring pois podemos ver o que estamos ou não afetando;● Segurança na correção de bugs;● Maior produtividade já que o desenvolvedor encontra menos bugs e não desperdiça tempo com depuradores;● Código da aplicação mais flexível e menos acoplado.
  33. 33. Ciclo de Desenvolvimento TDD● Red, Green, Refactor:● Escrevemos um Teste que inicialmente não passa (Red) - ele deve falhar;● Adicionamos a nova funcionalidade do sistema;● Fazemos o Teste passar (Green);● Refatoramos o código da nova funcionalidade (Refactoring);● Escrevemos o próximo Teste.
  34. 34. Classes● O nome da classe deve representar sua funcionalidade, explicando o que ela faz;● Não deve conter palavras como “mas”, “e”, ” ou”, “se”: ○ "AvaliarSePodePromoverParaPremium"; ○ "AvaliadorDeClientePremium".● Ter no máximo 25 palavras.
  35. 35. Princípio da responsabilidade única (SRP) - da Classe● Segundo Mr. Robert C. Martin, "uma classe só deve mudar por um único motivo";● Pergunta a se fazer: esta classe vai ter que mudar por mais um motivo com esta introdução que estou fazendo?● Resultado: Muitos métodos pequenos, com muitas classes pequenas. Muita modularidade.
  36. 36. Princípio da responsabilidade única (SRP) - da Classe● Háverá muitas funções, mas cada uma com uma única responsabilidade, e elas irão fazê- las direito;● Os dados e comportamento estão juntos, porém modularizados;
  37. 37. Design Emergente● É um design que nunca é o final, sempre está em evolução;● Kent Beck criou 4 regras básicas para o que ele chamou Simple Design: ○ Rode todos os testes; ○ Remova Duplicação; ○ Expresse sua intenção; ○ Diminua o número de classes e métodos.
  38. 38. Design Emergente● Rode todos os testes: ○ Fazer um sistema testável é possuir todos os testes passando; ○ Ele se torna verificável.● Remova duplicação de código; ○ Exemplo: Se você percebeu que tem um método que se repete em mais de uma classe, remova-o das classes e crie uma nova classe, mesmo que seja só para ter este método.
  39. 39. Design Emergente● Expresse sua intenção: ○ Escolher bons nomes, deixar métodos e classes pequenas e separar responsabilidades.● Diminuir o número de classes e métodos: ○ Sempre que possível, mantenha sistemas pequenos enquanto ao mesmo tempo se mantém métodos e classes pequenas.
  40. 40. Conclusão● Estes princípios nos ajudam a desenvolver códigos de maior qualidade;● Torna o código comunicável entre os membros das equipes de programação;● E influencia em uma melhor manuteniblidade do código.
  41. 41. Obrigado!
  42. 42. Bibliografia● MARTIN, ROBERT C. Código Limpo: Habilidades Práticas do Agile Software. São Paulo: Bookman, 2009.● http://blog.bluesoft.com.br/bluesoft-labs- clean-code-por-bruno-lui/● http://blog.lambda3.com. br/2009/02/principio-da-responsabilidade- unica-srp/● http://www.k19.com.br/artigos/tdd-simples-e- pratico-parte-i/

×