princípios básicos para desenvolvedores
DESCRIPTION
Introdução aos temas "Clean Code" e "Princípios de Design S.O.L.I.D"TRANSCRIPT
Princípios Básicos para
Desenvolvedores while(!(succeed=try()))
Guilherme Reis
Agenda
• Dicas para iniciantes;
• Mau cheiro;
• Porque se importar com o código;
• Código limpo;
• Princípios básicos de design;
Programação...
Programação é lógica,
não magia negra
• “Eu gosto de programar, só não gosto de lógica” (Ex-
aluno de Computação)
Antes de codificar, pense
no que quer/precisa fazer
Não funcionará na primeira vez! Provavelmente nem na segunda ou terceira;
Mas quando funciona...
Trabalho em equipe
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;
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*;
Baixa Coesão
Alto Acoplamento
• Forte dependência entre componentes;
• Dificulta mudanças;
• Dificulta reaproveitamento de código;
Alto Acoplamento
Fases de um projeto
• 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...
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”;
A culpa não é minha...
“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;
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;
Por que devo me
importar?
Por que devo me
importar?
Ciclo de um projeto
Prevenção
Por que devo me
importar?
• Não é só pelaos 20 centavos estética:
• É pelo TEMPO gasto!
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...
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;
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?
Pensando bem...
Código limpo
Humanos <- Código
Máquinas <- 01101001010
Por falar em nome...
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
Nomenclatura
• Qual componente do formulário será mostrado ou
escondido?
Nomenclatura
• Qual componente do formulário será mostrado ou
escondido?
O que este código faz?
Melhor?
E assim?
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
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
S – Single Responsibility
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;
S – Single Responsibility
S – Single Responsibility
O - Open Closed
• Fechado para edições;
• Aberto para extensões;
O - Open Closed
O - Open Closed
L - Liskov substitution
• As classes derivadas não devem ser mais fracas e nem
mais fortes que sua base
L - Liskov substitution
Customer
Gold Silver Guest
L - Liskov substitution
L - Liskov substitution
I - Interface Segregation
• Melhor ter várias interfaces pequenas para propósitos
específicos
• Do que interfaces genéricas enormes
I - Interface Segregation
I - Interface Segregation
D - Dependency inversion
• Dependa de abstrações, não de detalhes concretos
D - Dependency inversion
D - Dependency inversion
Resultado
Perguntas
Interessado?
OBRIGADO!
• Skype: guitoper
• Twitter: @guitoper
• LinkedIn: br.linkedin.com/pub/guilherme-reis/22/5a2/a44/
• Slides: http://pt.slideshare.net/guitoper/princpios-bsicos-
para-desenvolvedores