Princípios Básicos para Desenvolvedores

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