• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Codigo limpo
 

Codigo limpo

on

  • 1,253 views

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

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.

Statistics

Views

Total Views
1,253
Views on SlideShare
1,252
Embed Views
1

Actions

Likes
1
Downloads
31
Comments
0

1 Embed 1

http://www.slashdocs.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Codigo limpo Codigo limpo Presentation Transcript

    • Código limpo Diego 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ódigolimpo?● Existem várias definições.● Vamos citar algumas definições dadas por alguns dos pioneiros neste assunto.
    • 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.
    • 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.
    • 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.
    • Dave ThomasO código deve ser inteligivel já que dependendo dalinguagem, nem toda informação necessária pode serexpressa 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● Exemplo public 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/