Download - Codigo limpo
Código limpoDiego Magalhães Cunha
Gustavo MoreiraTauan Nascimento Almeida
Introdução
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Mas afinal, o que é ou como é um código limpo?
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.
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.
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.
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.
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.
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
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.
Métodos e Funções
"A primeira regra dos métodos é que eles devem ser pequenos, a segunda é que eles
devem ser menores ainda. "
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
Métodos e Funções
● Exemplopublic boolean checkPassword(String username, String password) {
String passwordStatus = cryptographer.decrypt(password);if(passwordStatus.equals(“OK”) ) {
Session.initialize();return true;
}return false;
}
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."
Formatação
● Forma de comunicação do desenvolvedor
● Leitores entenderam o que estão lendo
● Auxilia mudanças futuras
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
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
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.
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.
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.
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.
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.
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;
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.
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.
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.
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.
Obrigado!
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/