O documento apresenta princípios básicos de programação e design de software, incluindo maus cheiros de código, código limpo e os cinco princípios SOLID (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation e Dependency Inversion). O objetivo é ajudar desenvolvedores a escreverem código de melhor qualidade e mais fácil de manter.
9. Maus cheiros
• Primeiramente usado por Kent Beck e citado por Martin
Fowler;
• Indicação superficial de alerta à problemas mais
profundos no sistema;
• Não são bugs, mas falhas no design:
• Atraso no desenvolvimento
• Risco de bugs e falhas no futuro
• “Qualquer nariz” consegue identificar;
10. Exemplos
• Classes e métodos/funções enormes;
• Código ilegível;
• Códigos repetidos;
• Códigos redundantes;
• Métodos/Funções com vários parâmetros;
• Baixa coesão*;
• Alto acoplamento*;
15. • Tudo é muito bonito, limpo, elegante e convincente;
• Tudo funciona e as atividades são cumpridas como se
esperava;
• Tudo flui conforme o cronograma...
No começo...
16. O importante é
funcionar...
• O código começa a “ter um cheiro desagradável”
• No começo nem parece tão ruim;
• Uma verruga aqui, uma gambiarra ali, mais tudo ainda
parece bonito e funcional;
• Não há tempo para organização e melhorias;
• “Em time que está ganhando não se meche”;
18. “Tudo muda, tudo
sempre mudará...”
• Bugs começam a aparecer;
• Mudanças nos requisitos começam a surgir;
• Puxadinhos (Extensões) se tornam necessários;
• Novos campos e botões são adicionados;
• Então o código começa a apodrecer
e consequentemente, o “cheiro” fica insuportável;
19. Como prevenir?
• Mínimo:
• Se importe com o código gerado;
• Escrevendo um “código limpo”;
• Preocupando-se com o design do software;
• Melhor ainda:
• Fazer revisões de códigos com a equipe;
• Escrevendo testes automatizados;
• Realizando refactors ao identificar
maus cheiros no software;
24. Por que devo me
importar?
• Não é só pelaos 20 centavos estética:
• É pelo TEMPO gasto!
25. Como assim tempo?
• O que fazemos em nosso tempo? Sim, os 20% que sobram após o
coffe break, pipi break, tea break, brief break, etc.
• Planejamos mudanças;
• Lemos (e muito) código;
• Atuamos nos planos;
• Codificação de verdade? Não muito...
26. Mais e o código?
• Similar aos bancos de dados:
• Taxa de leitura:escrita de 10:1;
• Não fazemos UPDATE e sim várias sequências de
GET e PUT;
• Nosso cérebro não é um bom cache;
27. Tempo é dinheiro!
• Como reduzir custos através do código? Enchendo o projeto de
estagiários?
• Tempo de leitura/entendimento;
• Seus colegas lerão seus códigos inúmeras vezes
• Entender um módulo leva 2 horas ou 5 minutos?
• Tempo de escrita/adaptação/manutenção;
• O software irá mudar: fato;
• Quão fácil será esta mudança?
• Quanto do código será reaproveitado em outro projeto?
32. Nomenclatura
• Sim, o nome importa!
• O propósito de um nome é revelar intenção/objetivo;
• Depois do ctrl+c e ctrl+v, o que mais utilizamos em IDEs
é o ctrl+SPACE
38. O que mudou?
• Nomes que revelam intenção:
• flaggedCells no lugar de list
• cell no lugar de x
• Remoção de números mágicos:
• cell[STATUS_VALUE] no lugar de x[0]
• Abstração de tipo de dados:
• Cell cell no lugar de int[] cell
39. Princípios básicos
design
• 5 princípios de boas práticas vindas de décadas de experiência
em engenharia de software;
• [S]ingle Responsibility Principle
[O]pen/Closed Principle
[L]iskov Substitution Principle
[I]nterface Segregation Principle
[D]ependency Inversion Principle
41. S – Single Responsibility
• Uma classe/método deve ter apenas uma razão para ser
modificado(a);
• Menor impacto em mudanças;
• Reaproveitamento de código;
• Alta coesão;