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.


● 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.


● 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.


● 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.


● É, 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.


● 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.


● 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.


● 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.


● 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. "


● 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


● 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/

codigo limpo

Education