Codigo limpo
- 1. Código limpo Diego Magalhães Cunha Gustavo Moreira Tauan Nascimento Almeida
- 2. Introdução
- 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. 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. 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.
- 7. 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.
- 8. 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.
- 9. 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.
- 10. 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.
- 11. 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.
- 12. 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.
- 13. 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.
- 14. 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.
- 15. 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.
- 16. 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.
- 17. Mas afinal, o que é ou como é um código limpo?
- 19. O que é ou como é um código limpo? ● Existem várias definições. ● Vamos citar algumas definições dadas por alguns dos pioneiros neste assunto.
- 20. Bjarne Stroustrup Gosto do meu código elegante e eficiente. A lógica deve ser direta para dificultar o encobrimento de bugs, as dependências mínimas para facilitar a manutenção, o tratamento de erros completo de acordo com uma estratégia clara e o desempenho próximo do mais eficiente de modo a não incitar as pessoas a tornarem o código confuso com otimizações sorrateiras. O código deve proporcionar uma leitura natural.
- 21. Grady Booch Um codigo limpo é simples e direto. Ele é tão bem legível quanto uma prosa bem escrita. Ele jamais torna confuso o objetivo do desenvolvedor, em vez disso, ele está repleto de abstrações claras e linhas de controle objetivas.
- 22. Dave Thomas Alem de seu criador, um desenvolvedor pode ler e melhorar 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 fazer uma tarefa; - possui poucas dependências, as quais são explicitamente declaradas, - oferecem uma API mínima e clara.
- 23. Dave Thomas O código deve ser inteligivel já que dependendo da linguagem, nem toda informação necessária pode ser expressa no código em si.
- 24. 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
- 25. 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.
- 26. Métodos e Funções "A primeira regra dos métodos é que eles devem ser pequenos, a segunda é que eles devem ser menores ainda. "
- 27. 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
- 28. 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; }
- 29. 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."
- 30. Formatação ● Forma de comunicação do desenvolvedor ● Leitores entenderam o que estão lendo ● Auxilia mudanças futuras
- 31. 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
- 32. 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
- 33. 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.
- 34. 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.
- 35. 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.
- 36. 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.
- 37. 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.
- 38. 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;
- 39. 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.
- 40. 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.
- 41. 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.
- 42. 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.
- 43. Obrigado!
- 44. 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/