SlideShare uma empresa Scribd logo
1 de 44
Baixar para ler offline
Código limpo
 Diego Magalhães Cunha
     Gustavo Moreira
Tauan 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
● 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/

Mais conteúdo relacionado

Mais procurados

Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven DevelopmentNaresh Jain
 
Minicurso de JavaScript (Portuguese)
Minicurso de JavaScript (Portuguese)Minicurso de JavaScript (Portuguese)
Minicurso de JavaScript (Portuguese)Bruno Grange
 
Introdução ao GitHub e Git
Introdução ao GitHub  e GitIntrodução ao GitHub  e Git
Introdução ao GitHub e GitIgor Steinmacher
 
DOMinando JavaScript
DOMinando JavaScriptDOMinando JavaScript
DOMinando JavaScriptThiago Poiani
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IJoão Lourenço
 
Clean code - Mantenha seu código limpo
Clean code - Mantenha seu código limpoClean code - Mantenha seu código limpo
Clean code - Mantenha seu código limpoTiago Bencardino
 
TDD (Test Driven Design)
TDD (Test Driven Design)TDD (Test Driven Design)
TDD (Test Driven Design)nedirtv
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareDaniel Cukier
 
O Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de SoftwareO Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de SoftwareCamilo de Melo
 
Behavior driven development (bdd)
Behavior driven development (bdd)Behavior driven development (bdd)
Behavior driven development (bdd)Rohit Bisht
 
Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de softwareAlex Camargo
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven DevelopmentMireia Sangalo
 

Mais procurados (20)

Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
Minicurso de JavaScript (Portuguese)
Minicurso de JavaScript (Portuguese)Minicurso de JavaScript (Portuguese)
Minicurso de JavaScript (Portuguese)
 
clean code
clean codeclean code
clean code
 
Introdução ao GitHub e Git
Introdução ao GitHub  e GitIntrodução ao GitHub  e Git
Introdução ao GitHub e Git
 
Aula03 - JavaScript
Aula03 - JavaScriptAula03 - JavaScript
Aula03 - JavaScript
 
DOMinando JavaScript
DOMinando JavaScriptDOMinando JavaScript
DOMinando JavaScript
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
Princípios SOLID
Princípios SOLIDPrincípios SOLID
Princípios SOLID
 
TDC2014 SP - C/C++ - Modularização de Código C
TDC2014 SP - C/C++ - Modularização de Código CTDC2014 SP - C/C++ - Modularização de Código C
TDC2014 SP - C/C++ - Modularização de Código C
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade I
 
Clean code - Mantenha seu código limpo
Clean code - Mantenha seu código limpoClean code - Mantenha seu código limpo
Clean code - Mantenha seu código limpo
 
TDD (Test Driven Design)
TDD (Test Driven Design)TDD (Test Driven Design)
TDD (Test Driven Design)
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de Software
 
Clean code
Clean codeClean code
Clean code
 
O Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de SoftwareO Processo de Desenvolvimento de Software
O Processo de Desenvolvimento de Software
 
Teste de Software - Introdução
Teste de Software - IntroduçãoTeste de Software - Introdução
Teste de Software - Introdução
 
Behavior driven development (bdd)
Behavior driven development (bdd)Behavior driven development (bdd)
Behavior driven development (bdd)
 
Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de software
 
Test Driven Development
Test Driven DevelopmentTest Driven Development
Test Driven Development
 
Introdução a python
Introdução a pythonIntrodução a python
Introdução a python
 

Semelhante a Codigo limpo

Treinamento TDD - Atech
Treinamento TDD - AtechTreinamento TDD - Atech
Treinamento TDD - Atechcesarcneto
 
Código limpo: Funções Capítulo 3
Código limpo: Funções  Capítulo 3Código limpo: Funções  Capítulo 3
Código limpo: Funções Capítulo 3Inael Rodrigues
 
ZeroBugsProject - Técnicas de programação efetivas
ZeroBugsProject - Técnicas de programação efetivasZeroBugsProject - Técnicas de programação efetivas
ZeroBugsProject - Técnicas de programação efetivasRafael Chinelato Del Nero
 
TDD: A Essência do Mantra
TDD: A Essência do MantraTDD: A Essência do Mantra
TDD: A Essência do MantraDionatan default
 
Clean Code - Fork In Tuba
Clean Code - Fork In TubaClean Code - Fork In Tuba
Clean Code - Fork In TubaRafael Paz
 
Clean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisClean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisRogerio Fontes
 
Coding Dojo - Funcionamento
Coding Dojo - FuncionamentoCoding Dojo - Funcionamento
Coding Dojo - Funcionamentothiagodp
 
Teste sua aplicação antes que ela teste você
Teste sua aplicação antes que ela teste vocêTeste sua aplicação antes que ela teste você
Teste sua aplicação antes que ela teste vocêTiago Link
 
1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de softwareHeider Lopes
 
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...Developer Academy
 
ESP204 - Cap. 2 - Processos.pdf
ESP204 - Cap. 2 - Processos.pdfESP204 - Cap. 2 - Processos.pdf
ESP204 - Cap. 2 - Processos.pdfAndreLisboa13
 

Semelhante a Codigo limpo (20)

Clean code part 2
Clean code   part 2Clean code   part 2
Clean code part 2
 
Gisele
GiseleGisele
Gisele
 
BDD em Ação
BDD em AçãoBDD em Ação
BDD em Ação
 
Treinamento TDD - Atech
Treinamento TDD - AtechTreinamento TDD - Atech
Treinamento TDD - Atech
 
Código limpo: Funções Capítulo 3
Código limpo: Funções  Capítulo 3Código limpo: Funções  Capítulo 3
Código limpo: Funções Capítulo 3
 
Overview de QA
Overview de QA Overview de QA
Overview de QA
 
ZeroBugsProject - Técnicas de programação efetivas
ZeroBugsProject - Técnicas de programação efetivasZeroBugsProject - Técnicas de programação efetivas
ZeroBugsProject - Técnicas de programação efetivas
 
TDD: A Essência do Mantra
TDD: A Essência do MantraTDD: A Essência do Mantra
TDD: A Essência do Mantra
 
Clean Code - Fork In Tuba
Clean Code - Fork In TubaClean Code - Fork In Tuba
Clean Code - Fork In Tuba
 
Clean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everisClean code @rogeriofontes-techfriday-everis
Clean code @rogeriofontes-techfriday-everis
 
Codigo limpo.pptx
Codigo limpo.pptxCodigo limpo.pptx
Codigo limpo.pptx
 
Refatoração de Código Legado
Refatoração de Código LegadoRefatoração de Código Legado
Refatoração de Código Legado
 
Coding Dojo - Funcionamento
Coding Dojo - FuncionamentoCoding Dojo - Funcionamento
Coding Dojo - Funcionamento
 
Teste sua aplicação antes que ela teste você
Teste sua aplicação antes que ela teste vocêTeste sua aplicação antes que ela teste você
Teste sua aplicação antes que ela teste você
 
FC-Logic
FC-LogicFC-Logic
FC-Logic
 
1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software
 
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
Apresentação do Workshop BDD (Desenvolvimento Guiado por Comportamento) com V...
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
ESP204 - Cap. 2 - Processos.pdf
ESP204 - Cap. 2 - Processos.pdfESP204 - Cap. 2 - Processos.pdf
ESP204 - Cap. 2 - Processos.pdf
 
Clean code
Clean codeClean code
Clean code
 

Último

PROJETO DE EXTENSÃO - EDUCAÇÃO FÍSICA BACHARELADO.pdf
PROJETO DE EXTENSÃO - EDUCAÇÃO FÍSICA BACHARELADO.pdfPROJETO DE EXTENSÃO - EDUCAÇÃO FÍSICA BACHARELADO.pdf
PROJETO DE EXTENSÃO - EDUCAÇÃO FÍSICA BACHARELADO.pdfHELENO FAVACHO
 
11oC_-_Mural_de_Portugues_4m35.pptxTrabalho do Ensino Profissional turma do 1...
11oC_-_Mural_de_Portugues_4m35.pptxTrabalho do Ensino Profissional turma do 1...11oC_-_Mural_de_Portugues_4m35.pptxTrabalho do Ensino Profissional turma do 1...
11oC_-_Mural_de_Portugues_4m35.pptxTrabalho do Ensino Profissional turma do 1...licinioBorges
 
PRÁTICAS PEDAGÓGICAS GESTÃO DA APRENDIZAGEM
PRÁTICAS PEDAGÓGICAS GESTÃO DA APRENDIZAGEMPRÁTICAS PEDAGÓGICAS GESTÃO DA APRENDIZAGEM
PRÁTICAS PEDAGÓGICAS GESTÃO DA APRENDIZAGEMHELENO FAVACHO
 
Música Meu Abrigo - Texto e atividade
Música   Meu   Abrigo  -   Texto e atividadeMúsica   Meu   Abrigo  -   Texto e atividade
Música Meu Abrigo - Texto e atividadeMary Alvarenga
 
About Vila Galé- Cadeia Empresarial de Hotéis
About Vila Galé- Cadeia Empresarial de HotéisAbout Vila Galé- Cadeia Empresarial de Hotéis
About Vila Galé- Cadeia Empresarial de Hotéisines09cachapa
 
o ciclo do contato Jorge Ponciano Ribeiro.pdf
o ciclo do contato Jorge Ponciano Ribeiro.pdfo ciclo do contato Jorge Ponciano Ribeiro.pdf
o ciclo do contato Jorge Ponciano Ribeiro.pdfCamillaBrito19
 
CRUZADINHA - Leitura e escrita dos números
CRUZADINHA   -   Leitura e escrita dos números CRUZADINHA   -   Leitura e escrita dos números
CRUZADINHA - Leitura e escrita dos números Mary Alvarenga
 
Ficha de trabalho com palavras- simples e complexas.pdf
Ficha de trabalho com palavras- simples e complexas.pdfFicha de trabalho com palavras- simples e complexas.pdf
Ficha de trabalho com palavras- simples e complexas.pdfFtimaMoreira35
 
apostila projeto de vida 2 ano ensino médio
apostila projeto de vida 2 ano ensino médioapostila projeto de vida 2 ano ensino médio
apostila projeto de vida 2 ano ensino médiorosenilrucks
 
Dicionário de Genealogia, autor Gilber Rubim Rangel
Dicionário de Genealogia, autor Gilber Rubim RangelDicionário de Genealogia, autor Gilber Rubim Rangel
Dicionário de Genealogia, autor Gilber Rubim RangelGilber Rubim Rangel
 
ATIVIDADE PARA ENTENDER -Pizzaria dos Descritores
ATIVIDADE PARA ENTENDER -Pizzaria dos DescritoresATIVIDADE PARA ENTENDER -Pizzaria dos Descritores
ATIVIDADE PARA ENTENDER -Pizzaria dos DescritoresAnaCarinaKucharski1
 
Historia da Arte europeia e não só. .pdf
Historia da Arte europeia e não só. .pdfHistoria da Arte europeia e não só. .pdf
Historia da Arte europeia e não só. .pdfEmanuel Pio
 
Projeto de Extensão - ENGENHARIA DE SOFTWARE - BACHARELADO.pdf
Projeto de Extensão - ENGENHARIA DE SOFTWARE - BACHARELADO.pdfProjeto de Extensão - ENGENHARIA DE SOFTWARE - BACHARELADO.pdf
Projeto de Extensão - ENGENHARIA DE SOFTWARE - BACHARELADO.pdfHELENO FAVACHO
 
PROVA - ESTUDO CONTEMPORÂNEO E TRANSVERSAL: LEITURA DE IMAGENS, GRÁFICOS E MA...
PROVA - ESTUDO CONTEMPORÂNEO E TRANSVERSAL: LEITURA DE IMAGENS, GRÁFICOS E MA...PROVA - ESTUDO CONTEMPORÂNEO E TRANSVERSAL: LEITURA DE IMAGENS, GRÁFICOS E MA...
PROVA - ESTUDO CONTEMPORÂNEO E TRANSVERSAL: LEITURA DE IMAGENS, GRÁFICOS E MA...azulassessoria9
 
Revolução russa e mexicana. Slides explicativos e atividades
Revolução russa e mexicana. Slides explicativos e atividadesRevolução russa e mexicana. Slides explicativos e atividades
Revolução russa e mexicana. Slides explicativos e atividadesFabianeMartins35
 
JOGO FATO OU FAKE - ATIVIDADE LUDICA(1).pptx
JOGO FATO OU FAKE - ATIVIDADE LUDICA(1).pptxJOGO FATO OU FAKE - ATIVIDADE LUDICA(1).pptx
JOGO FATO OU FAKE - ATIVIDADE LUDICA(1).pptxTainTorres4
 
2° ano_PLANO_DE_CURSO em PDF referente ao 2° ano do Ensino fundamental
2° ano_PLANO_DE_CURSO em PDF referente ao 2° ano do Ensino fundamental2° ano_PLANO_DE_CURSO em PDF referente ao 2° ano do Ensino fundamental
2° ano_PLANO_DE_CURSO em PDF referente ao 2° ano do Ensino fundamentalAntônia marta Silvestre da Silva
 

Último (20)

Bullying, sai pra lá
Bullying,  sai pra láBullying,  sai pra lá
Bullying, sai pra lá
 
PROJETO DE EXTENSÃO - EDUCAÇÃO FÍSICA BACHARELADO.pdf
PROJETO DE EXTENSÃO - EDUCAÇÃO FÍSICA BACHARELADO.pdfPROJETO DE EXTENSÃO - EDUCAÇÃO FÍSICA BACHARELADO.pdf
PROJETO DE EXTENSÃO - EDUCAÇÃO FÍSICA BACHARELADO.pdf
 
11oC_-_Mural_de_Portugues_4m35.pptxTrabalho do Ensino Profissional turma do 1...
11oC_-_Mural_de_Portugues_4m35.pptxTrabalho do Ensino Profissional turma do 1...11oC_-_Mural_de_Portugues_4m35.pptxTrabalho do Ensino Profissional turma do 1...
11oC_-_Mural_de_Portugues_4m35.pptxTrabalho do Ensino Profissional turma do 1...
 
PRÁTICAS PEDAGÓGICAS GESTÃO DA APRENDIZAGEM
PRÁTICAS PEDAGÓGICAS GESTÃO DA APRENDIZAGEMPRÁTICAS PEDAGÓGICAS GESTÃO DA APRENDIZAGEM
PRÁTICAS PEDAGÓGICAS GESTÃO DA APRENDIZAGEM
 
Música Meu Abrigo - Texto e atividade
Música   Meu   Abrigo  -   Texto e atividadeMúsica   Meu   Abrigo  -   Texto e atividade
Música Meu Abrigo - Texto e atividade
 
About Vila Galé- Cadeia Empresarial de Hotéis
About Vila Galé- Cadeia Empresarial de HotéisAbout Vila Galé- Cadeia Empresarial de Hotéis
About Vila Galé- Cadeia Empresarial de Hotéis
 
o ciclo do contato Jorge Ponciano Ribeiro.pdf
o ciclo do contato Jorge Ponciano Ribeiro.pdfo ciclo do contato Jorge Ponciano Ribeiro.pdf
o ciclo do contato Jorge Ponciano Ribeiro.pdf
 
CRUZADINHA - Leitura e escrita dos números
CRUZADINHA   -   Leitura e escrita dos números CRUZADINHA   -   Leitura e escrita dos números
CRUZADINHA - Leitura e escrita dos números
 
Ficha de trabalho com palavras- simples e complexas.pdf
Ficha de trabalho com palavras- simples e complexas.pdfFicha de trabalho com palavras- simples e complexas.pdf
Ficha de trabalho com palavras- simples e complexas.pdf
 
apostila projeto de vida 2 ano ensino médio
apostila projeto de vida 2 ano ensino médioapostila projeto de vida 2 ano ensino médio
apostila projeto de vida 2 ano ensino médio
 
Dicionário de Genealogia, autor Gilber Rubim Rangel
Dicionário de Genealogia, autor Gilber Rubim RangelDicionário de Genealogia, autor Gilber Rubim Rangel
Dicionário de Genealogia, autor Gilber Rubim Rangel
 
Aula sobre o Imperialismo Europeu no século XIX
Aula sobre o Imperialismo Europeu no século XIXAula sobre o Imperialismo Europeu no século XIX
Aula sobre o Imperialismo Europeu no século XIX
 
ATIVIDADE PARA ENTENDER -Pizzaria dos Descritores
ATIVIDADE PARA ENTENDER -Pizzaria dos DescritoresATIVIDADE PARA ENTENDER -Pizzaria dos Descritores
ATIVIDADE PARA ENTENDER -Pizzaria dos Descritores
 
Historia da Arte europeia e não só. .pdf
Historia da Arte europeia e não só. .pdfHistoria da Arte europeia e não só. .pdf
Historia da Arte europeia e não só. .pdf
 
Projeto de Extensão - ENGENHARIA DE SOFTWARE - BACHARELADO.pdf
Projeto de Extensão - ENGENHARIA DE SOFTWARE - BACHARELADO.pdfProjeto de Extensão - ENGENHARIA DE SOFTWARE - BACHARELADO.pdf
Projeto de Extensão - ENGENHARIA DE SOFTWARE - BACHARELADO.pdf
 
PROVA - ESTUDO CONTEMPORÂNEO E TRANSVERSAL: LEITURA DE IMAGENS, GRÁFICOS E MA...
PROVA - ESTUDO CONTEMPORÂNEO E TRANSVERSAL: LEITURA DE IMAGENS, GRÁFICOS E MA...PROVA - ESTUDO CONTEMPORÂNEO E TRANSVERSAL: LEITURA DE IMAGENS, GRÁFICOS E MA...
PROVA - ESTUDO CONTEMPORÂNEO E TRANSVERSAL: LEITURA DE IMAGENS, GRÁFICOS E MA...
 
CINEMATICA DE LOS MATERIALES Y PARTICULA
CINEMATICA DE LOS MATERIALES Y PARTICULACINEMATICA DE LOS MATERIALES Y PARTICULA
CINEMATICA DE LOS MATERIALES Y PARTICULA
 
Revolução russa e mexicana. Slides explicativos e atividades
Revolução russa e mexicana. Slides explicativos e atividadesRevolução russa e mexicana. Slides explicativos e atividades
Revolução russa e mexicana. Slides explicativos e atividades
 
JOGO FATO OU FAKE - ATIVIDADE LUDICA(1).pptx
JOGO FATO OU FAKE - ATIVIDADE LUDICA(1).pptxJOGO FATO OU FAKE - ATIVIDADE LUDICA(1).pptx
JOGO FATO OU FAKE - ATIVIDADE LUDICA(1).pptx
 
2° ano_PLANO_DE_CURSO em PDF referente ao 2° ano do Ensino fundamental
2° ano_PLANO_DE_CURSO em PDF referente ao 2° ano do Ensino fundamental2° ano_PLANO_DE_CURSO em PDF referente ao 2° ano do Ensino fundamental
2° ano_PLANO_DE_CURSO em PDF referente ao 2° ano do Ensino fundamental
 

Codigo limpo

  • 1. Código limpo Diego Magalhães Cunha Gustavo Moreira Tauan Nascimento Almeida
  • 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.
  • 6.
  • 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?
  • 18.
  • 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.
  • 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/