Anda di halaman 1dari 44

Cdigo limpo

Diego Magalhes Cunha Gustavo Moreira Tauan Nascimento Almeida

Introduo

O custo de ter um cdigo confuso


Ao longo de um certo tempo de trabalho, equipes que trabalham rapidamente no inicio de um projeto podem perceber mais tarde que esto indo a passos de tartaruga. Cada alterao feita no cdigo causa uma falha em outras duas ou tres partes do mesmo cdigo.

O custo de ter um cdigo confuso


Mudana alguma trivial. Cada adio ou modificao ao sistema exige que restauraes, amarraes e remendos sejam "entendidas" de modo que outras possam ser incluidas.

O custo de ter um cdigo confuso


Com o tempo, a baguna se torna to grande e profunda que no d para arrumla. No h absolutamente soluo alguma.

O grande replanejamento
No final, a equipe se rebela. Todos informam gerncia que no conseguem mais trabalhar neste irritante cdigo-fonte e exigem um replanejamento do projeto.

O grande replanejamento
Apesar de a gerncia no querer gastar recursos em uma nova remodelao, ela no pode negar que a produtividade est pssima. No final das contas, ela acaba cedendo s exigncias dos desenvolvedores e autoriza o grande replanejamento desejado.

O grande replanejamento
, ento , formada uma nova equipe especializada. Por ser um projeto inteiramente novo, todos querem fazer parte dessa equipe. Eles desejam comear do zero e criar algo belo de verdade.

O grande replanejamento
Mas apenas os melhores e mais brilhantes so selecionados e os outros devero continuar na manuteno do sistema atual. Agora ambos os times esto numa corrida.

O grande replanejamento
A nova equipe precisa construir um novo sistema que faa o mesmo que o antigo, alm de ter de ser manter atualizada em relaao s mudanas feitas constantemente no sistema antigo. Este, a gerencia no substuir at que o novo possa fazer tudo tambm.

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 situao, entao sabe que dedicar tempo para limpar seu cdigo nao apenas eficaz em termos de custo, mas uma questo de sobrevivencia profissional.

O problema do prazo
Todos os gerentes protegem os prazos e os requisitos, mas essa a funo deles. A sua, proteger o cdigo.

O problema do prazo
Por mais que os prazos estejam estourados, preze por um cdigo bem feito, bem escrito. Imagine se voc fosse um mdico e seu paciente (seu chefe, neste contexto) exigisse que voc no lavasse suas mos antes de uma operao devido a perda de tempo.

O problema do prazo
bvio que voc no dar ouvidos a este paciente. Da mesma forma, em alguns momentos, o atraso aceitvel levando em considerao as consequncias.

Mas afinal, o que ou como um cdigo limpo?

O que ou como um cdigo limpo?


Existem vrias definies. Vamos citar algumas definies dadas por alguns dos pioneiros neste assunto.

Bjarne Stroustrup
Gosto do meu cdigo elegante e eficiente. A lgica deve ser direta para dificultar o encobrimento de bugs, as dependncias mnimas para facilitar a manuteno, o tratamento de erros completo de acordo com uma estratgia clara e o desempenho prximo do mais eficiente de modo a no incitar as pessoas a tornarem o cdigo confuso com otimizaes sorrateiras. O cdigo deve proporcionar uma leitura natural.

Grady Booch
Um codigo limpo simples e direto. Ele to bem legvel quanto uma prosa bem escrita. Ele jamais torna confuso o objetivo do desenvolvedor, em vez disso, ele est repleto de abstraes claras e linhas de controle objetivas.

Dave Thomas
Alem de seu criador, um desenvolvedor pode ler e melhorar um cdigo limpo. Ele tem: - teste de unidade e de aceitao, - nomes significativos, - oferece apenas uma maneira, e no vrias, de se fazer uma tarefa; - possui poucas dependncias, as quais so explicitamente declaradas, - oferecem uma API mnima e clara.

Dave Thomas
O cdigo deve ser inteligivel j que dependendo da linguagem, nem toda informao necessria pode ser expressa no cdigo em si.

Nomes Significativos
Nomes so peas chaves em um cdigo
Variveis, classes, mtodos, ...

Devem nos dizer trs coisas


Porque existem O que fazem Como so usados

Dicas para bons nomes


Distines significativas
Nomes como a1, a2, a3, ..., no dizem nada sobre a varivel, mtodo, etc.

No usar trocadilhos ou abreviaes


O nome deve ser auto-explicativo.

Mtodos e Funes

"A primeira regra dos mtodos que eles devem ser pequenos, a segunda que eles devem ser menores ainda. "

Mtodos e Funes
Conter no mximo 20 linhas Nvel de identao no pode ser maior que 2 Receber o mnimo de parmetros possvel
Receber muitos parmetros dificulta o Teste Unitrio

Somente uma responsabilidade

Mtodos e Funes
Exemplo
public boolean checkPassword(String username, String password) { String passwordStatus = cryptographer.decrypt (password); if(passwordStatus.equals(OK) ) { Session.initialize(); return true; } return false; }

Comentrios
So teis quando colocados nos locais certos
Informar uma consequncia Explicar uma deciso tomada

O principal motivo para se escrever um comentrio um cdigo ilegvel "Explique-se no cdigo."

Formatao
Forma de comunicao do desenvolvedor Leitores entenderam o que esto lendo Auxilia mudanas futuras

Dicas para formatao


No escreva classes com mais de 500 linhas
Classes menores so mais fceis de se entender

Estabelea um limite sensato para o tamanho de uma linha Faa uma boa identao
No deixe seu cdigo grudado

Tratamento de erros
No exagerar no tratamento de erros
No possvel enxergar objetivo do cdigo

Use excees
Linguagens antigas retornavam cdigos de erro

Fornea excees com contexto


Mensagens passadas juntamente com a exceo, como tipo de falha

Testes Unitrios (TDD - Test Driven Development)


uma tcnica de desenvolvimento de software que
baseia em pequenos ciclos de repeties;

Para cada funcionalidade do sistema criado um teste


antes;

Esse teste dever falhar, pois no temos nenhuma


funcionalidade;

Logo aps fazemos o teste passar implementando a


funcionalidade.

Motivos para o uso do TDD


Feedback rpido sobre a nova funcionalidade e sobre as outras funcionalidades existentes no sistema; Cdigo mais limpo, j que escrevemos cdigos simples para o teste passar; Segurana no Refactoring pois podemos ver o que estamos ou no afetando; Segurana na correo de bugs; Maior produtividade j que o desenvolvedor encontra menos bugs e no desperdia tempo com depuradores; Cdigo da aplicao mais flexvel e menos acoplado.

Ciclo de Desenvolvimento TDD


Red, Green, Refactor: Escrevemos um Teste que inicialmente no passa (Red) - ele deve falhar; Adicionamos a nova funcionalidade do sistema; Fazemos o Teste passar (Green); Refatoramos o cdigo da nova funcionalidade (Refactoring); Escrevemos o prximo Teste.

Classes
O nome da classe deve representar sua funcionalidade, explicando o que ela faz; No deve conter palavras como mas, e, ou, se:
"AvaliarSePodePromoverParaPremium"; "AvaliadorDeClientePremium".

Ter no mximo 25 palavras.

Princpio 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 introduo que estou fazendo? Resultado: Muitos mtodos pequenos, com muitas classes pequenas. Muita modularidade.

Princpio da responsabilidade nica (SRP) - da Classe


Hver muitas funes, mas cada uma com
uma nica responsabilidade, e elas iro fazlas direito;

Os dados e comportamento esto juntos,


porm modularizados;

Design Emergente
um design que nunca o final, sempre est em evoluo; Kent Beck criou 4 regras bsicas para o que ele chamou Simple Design:
Rode todos os testes; Remova Duplicao; Expresse sua inteno; Diminua o nmero de classes e mtodos.

Design Emergente
Rode todos os testes:
Fazer um sistema testvel possuir todos os testes passando; Ele se torna verificvel.

Remova duplicao de cdigo;


Exemplo: Se voc percebeu que tem um mtodo que se repete em mais de uma classe, remova-o das classes e crie uma nova classe, mesmo que seja s para ter este mtodo.

Design Emergente
Expresse sua inteno:
Escolher bons nomes, deixar mtodos e classes pequenas e separar responsabilidades.

Diminuir o nmero de classes e mtodos:


Sempre que possvel, mantenha sistemas pequenos enquanto ao mesmo tempo se mantm mtodos e classes pequenas.

Concluso
Estes princpios nos ajudam a desenvolver cdigos de maior qualidade; Torna o cdigo comunicvel entre os membros das equipes de programao; E influencia em uma manuteniblidade do cdigo. melhor

Obrigado!

Bibliografia
MARTIN, ROBERT C. Cdigo Limpo: Habilidades Prticas do Agile Software. So Paulo: Bookman, 2009. http://blog.bluesoft.com.br/bluesoft-labsclean-code-por-bruno-lui/ http://blog.lambda3.com. br/2009/02/principio-da-responsabilidadeunica-srp/ http://www.k19.com.br/artigos/tdd-simples-epratico-parte-i/

Anda mungkin juga menyukai