Code SmellsSintomas de código ruim
Antes de começarmos• Use sempre o bom senso! Nem tudo que  cheira mal é podre e nem tudo que cheira  bem é bom.• Algumas s...
KISS• KISS – Keep It Simple, Stupid!• Mantenha as coisas simples!• Soluções mais legíveis e reaproveitáveis.• Um código ma...
DRY•   DRY – Don’t Repeat Yourself!•   Não se repita!•   Código duplicado é retrabalho.•   Código duplicado é mais difícil...
OOP• OOP = Programação orientada a objetos.• Dividir código em classes que agrupam funções  relacionadas não é o suficient...
MVC• M de Modelo (model)   – Classes que trabalham diretamente com os dados do banco e     digitados pelo usuário.   – Não...
ACID• Atomicidade: ou todo o trabalho é feito, ou nada  é feito.• Consistência: a integridade dos dados deve estar  assegu...
O que são Code Smells?• São sintomas de código mal pensado.• Podem indicar problemas mais profundos.• Não são necessariame...
Sintomas de código ruim dentro de uma única classe.CODE SMELLS DENTRO DE CLASSES
Comentários (desodorante)• Os comentários são necessários? Eles  explicam “por que” e não “o que”?• Você pode refatorar o ...
Métodos longos• Um método mais curto é mais fácil de ler, mais  fácil de entender, e mais fácil de debugar.• Refatore méto...
Muitos parâmetros no método• Quanto mais parâmetros um método  tem, mais complexo ele é.• Limite o número de parâmetros qu...
Código duplicado• Código duplicado é a ruína do  desenvolvimento de software.• Acabe com a duplicação sempre que possível....
Complexidade condicional• Cuidado com os grandes blocos de  if/else/switch, especialmente blocos que  tendem a crescer ou ...
Explosão combinatória• Você tem um monte de código que faz quase  a mesma coisa, mas com pequenas variações  de dados ou d...
Classe grande• Classes grandes, como métodos longos, são  difíceis de ler, compreender e debugar.• Será que a classe tem r...
Tipo incorporado nos nomes• Evite colocar os nomes dos tipos e classes nos  nomes dos métodos.• Não é apenas redundante, t...
Nome não-explicativo• O nome do método, do atributo, da  variável, da classe, etc., descreve  sucintamente o que ele faz?•...
Nomes inconsistentes• Escolha uma terminologia padrão e siga ela no  código todo.• Por exemplo, se você tem open(), você  ...
Código morto• Apague sem dó o código que não está mais  sendo usado, como por exemplo código  comentado.• É por isso que t...
Código de vidente• Escreva código para resolver os problemas de  hoje, e se preocupe com os problemas de  amanhã quando el...
Soluções estranhas• Deve haver apenas uma forma de resolver o  mesmo problema em seu código.• Se você encontrar uma soluçã...
Campo temporário• Cuidado com objetos que contêm uma grande  quantidade de campos opcionais ou  desnecessários.• Se você e...
Sintomas de código ruim no relacionamento entre várias classes.CODE SMELLS ENTRE AS CLASSES
Classes parecidas com APIs diferentes• Se duas classes são semelhantes no  interior, mas diferentes do lado de fora (API  ...
Obsessão com tipos primitivos• Não use um bando de variáveis de tipo  primitivo como um substituto pobre de uma  classe.• ...
Classes de dados• Por outro lado, evite classes que só  armazenam dados.• As classes devem conter dados e métodos que  ope...
Tufos de dados• Se você sempre vê os mesmos dados por aí  reunidos, talvez eles sejam um grupo.• Considere juntar os dados...
Legado renegado• Se você herda de uma classe, mas nunca  utiliza qualquer uma das funcionalidades  herdadas, você realment...
Intimidade inapropriada• Cuidado com as classes que passam muito  tempo juntas, ou classes que interagem de  modo inadequa...
Inveja de características• Métodos que fazem uso extensivo de outra  classe podem pertencer à essa outra classe.• Consider...
Exposição indecente• Cuidado com as classes que desnecessariamente  expõem seu interior.• Refatore agressivamente as class...
Corrente de mensagens• Cuidado com as longas sequências de  chamadas de métodos ou  variáveis ​temporárias para obter dado...
Garoto de recados• Se uma classe está delegando todo o seu  trabalho, por que ela existe?• Corte o intermediário.• Cuidado...
Mudanças divergentes• Se, ao longo do tempo, você faz alterações em  uma classe que toca partes completamente  diferentes ...
Tiro de espingarda• Se uma alteração em uma classe requer  mudanças em cascata em várias classes  relacionadas, considere ...
Heranças paralelas• Sempre que você faz uma subclasse de uma  classe e também precisa fazer uma subclasse  de outra. Consi...
Biblioteca incompleta• Precisamos de um método que está faltando em  uma biblioteca, mas estamos relutantes ou  somos inca...
Solução esparramada• Se é preciso cinco classes para fazer algo  útil, você pode ter uma solução esparramada.• Considere s...
Gostamos de controladores magrinhos e modelos gordinhos – mascuidado se estes ficarem obesos!DICAS PARA REFATORAR OSMODELO...
Extraia Value Objects do modelo• Value Object é um objeto pequeno que representa  uma entidade simples, geralmente com um ...
Extraia objetos de serviço• Quando uma ação é muito complexa (como o envio de um pedido).• A ação consulta muitos modelos ...
Extraia objetos de formulários• Quando há uma busca ou filtro complexo.• Quando mais de um modelo é atualizado pelo  mesmo...
Extraia objetos de queries• Para queries SQL muito complexas que estão  inundando o modelo, considere extrair em  uma clas...
Extraia helpers• Quando alguns métodos só existem para não incluir código  na view.• Quando um bloco de HTML é reutilizado...
Referências• http://blog.codeclimate.com/blog/2012/10/17/7-  ways-to-decompose-fat-activerecord-models/• https://codeclima...
Próximos SlideShares
Carregando em…5
×

Code Smells

2.388 visualizações

Publicada em

Sintomas de código ruim.

Publicada em: Tecnologia
1 comentário
7 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
2.388
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
0
Comentários
1
Gostaram
7
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Code Smells

  1. 1. Code SmellsSintomas de código ruim
  2. 2. Antes de começarmos• Use sempre o bom senso! Nem tudo que cheira mal é podre e nem tudo que cheira bem é bom.• Algumas siglas essenciais pro programador: – KISS – DRY – OOP – MVC – ACID
  3. 3. KISS• KISS – Keep It Simple, Stupid!• Mantenha as coisas simples!• Soluções mais legíveis e reaproveitáveis.• Um código mais reaproveitável precisa ser consistente e isso é sempre difícil.• Pode até resultar em mais código, só que resolvendo o problema de uma forma fácil.
  4. 4. DRY• DRY – Don’t Repeat Yourself!• Não se repita!• Código duplicado é retrabalho.• Código duplicado é mais difícil de manter (experimente corrigir um erro de um código que foi duplicado em cinco, vinte, cem arquivos...)
  5. 5. OOP• OOP = Programação orientada a objetos.• Dividir código em classes que agrupam funções relacionadas não é o suficiente.• O objeto também pode ser um formulário, um controlador, um helper, um comando ou qualquer outro tipo de objeto que não represente uma linha de uma tabela do banco de dados.• Assim como decorar a gramática não faz de alguém um bom escritor, saber declarar uma classe no PHP não significa que pensamos orientado a objeto.
  6. 6. MVC• M de Modelo (model) – Classes que trabalham diretamente com os dados do banco e digitados pelo usuário. – Não necessariamente representa uma tabela. – Modelo gordo, controlador magrinho.• V de Visão (view) – HTML quase puro. – Sem lógica, exceto para exibir (loops, condições, que podem ser extraídos em helpers e partials)• C de Controlador (controller) – Faz o controle de acesso. – Carrega e alimenta os modelos corretos. – Carrega as visões e injeta os modelos.
  7. 7. ACID• Atomicidade: ou todo o trabalho é feito, ou nada é feito.• Consistência: a integridade dos dados deve estar assegurada. Não deve quebrar as regras do banco de dados.• Isolamento: duas transações diferentes não deveriam utilizar o mesmo objeto em estados diferentes. Só devem ser simultâneas se não afetarem os mesmos dados.• Durabilidade: os efeitos de uma transação com sucesso devem persistir no banco de dados.
  8. 8. O que são Code Smells?• São sintomas de código mal pensado.• Podem indicar problemas mais profundos.• Não são necessariamente o problema em si. Um método muito longo pode ser um sintoma de que as responsabilidades do objeto não estão bem divididas. Quebrá-lo em métodos menores provavelmente não é o jeito certo de corrigir.• O programador precisa pensar num nível mais abstrato sobre o que o sintoma realmente representa.
  9. 9. Sintomas de código ruim dentro de uma única classe.CODE SMELLS DENTRO DE CLASSES
  10. 10. Comentários (desodorante)• Os comentários são necessários? Eles explicam “por que” e não “o que”?• Você pode refatorar o código para que ele seja mais legível e os comentários não sejam necessários?• Você está escrevendo comentários para pessoas, não para máquinas.
  11. 11. Métodos longos• Um método mais curto é mais fácil de ler, mais fácil de entender, e mais fácil de debugar.• Refatore métodos longos em métodos menores. Muitas vezes eles serão reaproveitados.• Verifique também se o método não é muito longo por causa de uma lógica complexa.
  12. 12. Muitos parâmetros no método• Quanto mais parâmetros um método tem, mais complexo ele é.• Limite o número de parâmetros que você precisa em um determinado método, ou use um objeto para combinar os parâmetros.• Cuidado com métodos onde a maioria dos parâmetros é opcional.
  13. 13. Código duplicado• Código duplicado é a ruína do desenvolvimento de software.• Acabe com a duplicação sempre que possível.• Você deve estar sempre à procura de casos menos óbvios de duplicação (código levemente diferente).• DRY – não se repita!
  14. 14. Complexidade condicional• Cuidado com os grandes blocos de if/else/switch, especialmente blocos que tendem a crescer ou mudar bastante ao longo do tempo.• Soluções (patterns): – Implemente preocupando-se que o objeto tenha o método necessário, e não o tipo necessário. – O método do objeto responde de forma diferente de acordo com o estado dele.
  15. 15. Explosão combinatória• Você tem um monte de código que faz quase a mesma coisa, mas com pequenas variações de dados ou de comportamento.• Isso pode ser difícil de refatorar. Considere responder e chamar métodos independente do seu tipo.
  16. 16. Classe grande• Classes grandes, como métodos longos, são difíceis de ler, compreender e debugar.• Será que a classe tem responsabilidades demais?• A classe grande pode ser reestruturada ou dividida em classes menores?
  17. 17. Tipo incorporado nos nomes• Evite colocar os nomes dos tipos e classes nos nomes dos métodos.• Não é apenas redundante, também nos obriga a mudar o método e as chamadas se o nome do tipo ou da classe mudar.
  18. 18. Nome não-explicativo• O nome do método, do atributo, da variável, da classe, etc., descreve sucintamente o que ele faz?• Se você lesse em voz alta o nome do método para outro desenvolvedor, ele saberia explicar o que isso faz? Se você acha que ele não saberia, renomeie ou reescreva.
  19. 19. Nomes inconsistentes• Escolha uma terminologia padrão e siga ela no código todo.• Por exemplo, se você tem open(), você provavelmente deve ter close().• Se você usa $row->ativo, não misture com $row->excluido.
  20. 20. Código morto• Apague sem dó o código que não está mais sendo usado, como por exemplo código comentado.• É por isso que temos Git, Subversion, etc.!• Cuidado ao excluir métodos ou classes que você criou e acha que não estão sendo usados em mais nenhum lugar. Sempre faça uma busca.
  21. 21. Código de vidente• Escreva código para resolver os problemas de hoje, e se preocupe com os problemas de amanhã quando eles realmente se concretizarem.• Você (provavelmente) não vão precisar disso.• Só se preocupe se as chances forem muito concretas de que o problema aconteça.
  22. 22. Soluções estranhas• Deve haver apenas uma forma de resolver o mesmo problema em seu código.• Se você encontrar uma solução estranha, que poderia ser um caso de código mal duplicado – ou poderia ser um argumento para o modelo adaptador, se você realmente precisa de múltiplas soluções para o mesmo problema.
  23. 23. Campo temporário• Cuidado com objetos que contêm uma grande quantidade de campos opcionais ou desnecessários.• Se você está passando um objeto como um parâmetro para um método, certifique-se de que você está usando tudo isso e não está fazendo uma seleção de uns poucos campos.
  24. 24. Sintomas de código ruim no relacionamento entre várias classes.CODE SMELLS ENTRE AS CLASSES
  25. 25. Classes parecidas com APIs diferentes• Se duas classes são semelhantes no interior, mas diferentes do lado de fora (API pública), talvez elas possam ser modificadas para compartilhar uma interface comum.
  26. 26. Obsessão com tipos primitivos• Não use um bando de variáveis de tipo primitivo como um substituto pobre de uma classe.• Se o tipo de dados é complexo o suficiente, escreva uma classe para representá-lo.• Datas são suficientemente complexas para serem um objeto ao invés de uma string.• As vezes é melhor usar novas classes do que exagerar nos arrays.
  27. 27. Classes de dados• Por outro lado, evite classes que só armazenam dados.• As classes devem conter dados e métodos que operam sobre esses dados também.
  28. 28. Tufos de dados• Se você sempre vê os mesmos dados por aí reunidos, talvez eles sejam um grupo.• Considere juntar os dados relacionados em uma classe maior.
  29. 29. Legado renegado• Se você herda de uma classe, mas nunca utiliza qualquer uma das funcionalidades herdadas, você realmente deveria estar usando herança?
  30. 30. Intimidade inapropriada• Cuidado com as classes que passam muito tempo juntas, ou classes que interagem de modo inadequado.• Uma classe deve saber o mínimo possível sobre as outras.
  31. 31. Inveja de características• Métodos que fazem uso extensivo de outra classe podem pertencer à essa outra classe.• Considere mover este método para a classe da qual ele tem tanta inveja.
  32. 32. Exposição indecente• Cuidado com as classes que desnecessariamente expõem seu interior.• Refatore agressivamente as classes para diminuir sua interface pública.• Você deve ter um motivo convincente para cada item que você torna público. Se você não tem, esconda.• Private = esconde das classes que herdam de si.• Protected = esconde das outras classes.
  33. 33. Corrente de mensagens• Cuidado com as longas sequências de chamadas de métodos ou variáveis ​temporárias para obter dados rotineiros.• Intermediários são dependências disfarçadas.
  34. 34. Garoto de recados• Se uma classe está delegando todo o seu trabalho, por que ela existe?• Corte o intermediário.• Cuidado com classes que são apenas invólucros para outras classes ou funcionalidades já existentes no framework.
  35. 35. Mudanças divergentes• Se, ao longo do tempo, você faz alterações em uma classe que toca partes completamente diferentes da mesma, ela pode conter muita funcionalidade não relacionada.• Considere isolar em outra classe as partes que mudaram.
  36. 36. Tiro de espingarda• Se uma alteração em uma classe requer mudanças em cascata em várias classes relacionadas, considere uma refatoração de modo que as alterações sejam limitadas a uma única classe, ou use herança.
  37. 37. Heranças paralelas• Sempre que você faz uma subclasse de uma classe e também precisa fazer uma subclasse de outra. Considere juntar a hierarquia em uma única classe.
  38. 38. Biblioteca incompleta• Precisamos de um método que está faltando em uma biblioteca, mas estamos relutantes ou somos incapazes de mudar a biblioteca para incluir o método.• O método acaba sendo anexado a uma outra classe. Se você não pode modificar a biblioteca, considere isolar o método ou aproveitar a flexibilidade do Yii de usar classes personalizadas que estendem seus componentes padrão.
  39. 39. Solução esparramada• Se é preciso cinco classes para fazer algo útil, você pode ter uma solução esparramada.• Considere simplificar e consolidar o seu projeto.
  40. 40. Gostamos de controladores magrinhos e modelos gordinhos – mascuidado se estes ficarem obesos!DICAS PARA REFATORAR OSMODELOS OBESOS
  41. 41. Extraia Value Objects do modelo• Value Object é um objeto pequeno que representa uma entidade simples, geralmente com um único valor, que deveria ser imutável.• São úteis quando há um atributo ou pequeno grupo de atributos que tem alguma lógica associada com eles.• Exemplos: – Uma classe CNPJ que se valida e retorna seu valor numérico ou formatado. – Uma classe Avaliacao para ratings, que retorna a média, descrição legível da nota, etc. – Qualquer sub-regra dentro de um modelo maior.
  42. 42. Extraia objetos de serviço• Quando uma ação é muito complexa (como o envio de um pedido).• A ação consulta muitos modelos diferentes ao mesmo tempo.• A ação interage com um serviço externo (conexão com uma rede social, uma API de outro sistema, etc.)• A ação não é uma das preocupações principais do modelo principal (por exemplo, escrever num arquivo de log poderia ser delegado a uma classe de log).• Quando existem muitas formas de fazer a ação (como a autenticação de um usuário, uma checagem de uma regra de acesso, etc.)• Se a ação poderia ser reutilizada sempre (exemplo: cálculos que podem ser refeitos e retornar o mesmo número).
  43. 43. Extraia objetos de formulários• Quando há uma busca ou filtro complexo.• Quando mais de um modelo é atualizado pelo mesmo formulário você poderia encapsular a submissão em um CFormModel.• Mais fácil de manejar os erros e uma transação do banco de dados.
  44. 44. Extraia objetos de queries• Para queries SQL muito complexas que estão inundando o modelo, considere extrair em uma classe que a represente.• Útil para relatórios que cruzam muitos modelos, mas não pode-se dizer que é baseado em um deles.• Casos em que cada objeto de query retorna dados baseados em determinadas regras de negócio.
  45. 45. Extraia helpers• Quando alguns métodos só existem para não incluir código na view.• Quando um bloco de HTML é reutilizado em mais de uma view.• Pode ser associado com uma partial: – Layout – topo, logo, menu, rodapé, toda a parte “repetidas” que envolve o “miolo” da aplicação. – View – visão, o “miolo”, chamada por um controller e exibindo dados de um ou mais modelos. – Helper – uma classe de código que encapsula views com muitas condições em PHP ou que são usadas em muitos lugares. – Partial – um pedaço de view que pode ser reaproveitado. Por exemplo, a partial _form é usada nas views editar e cadastrar.
  46. 46. Referências• http://blog.codeclimate.com/blog/2012/10/17/7- ways-to-decompose-fat-activerecord-models/• https://codeclimate.com/docs#quality-metrics• http://www.codinghorror.com/blog/2006/05/code- smells.html• http://pt.wikipedia.org/wiki/Strategy• http://pt.wikipedia.org/wiki/State• http://pt.wikipedia.org/wiki/ACID• http://www.industriallogic.com/wp- content/uploads/2005/09/smellstorefactorings.pdf

×