Desenvolvendo como um Profissional Agil

André Faria@andrefaria @bruno_lui

Bruno Lui

Clean Code’

André Faria Gomes

@andrefariahttp://blog.andrefaria.comhttp://blog.bluesoft.com.br

Black Belt Lean 6 Sigma

+10 de Anos de Desenvolvimento de SoftwareCIO na Bluesoft

Instrutor da Adaptworks

Bruno Lui

@brunoluihttp://brunolui.com

+5 Anos no Desenvolvimento de Software

Desenvolvedor na Bluesoft

Então você quer ser um desenvolvedor de

software profissional?

Quer que as mães apontem para você e digam a seus filhos para que sejam como

você?

Cuidado com o que você Pede!

Profissionalismo é sem dúvida digno

de honra e orgulho, mas também é

responsabilidade.

Você não pode se orgulhar de algo pelo qual não se responsabiliza...

É muito mais fácil ser um largado... Não se responsabilizar pelo trabalho e pela carreira....

Quando um não-profissional faz uma besteira, seu empregador limpa a

bagunça...

Quando um profissional faz uma besteira, ele

limpa a bagunça!

O que você faz para escrever software sem defeitos?

Você se responsabiliza pelos defeitos que cria?

Escrever testes é essencial para garantir que seu software funciona...

Como você pode dizer que é responsável se

não os escreve?

“Toda a linha de código que você escreve deve estar testada, e

Ponto Final!”Uncle Bob

Código escrito por profissionais pode ser alterado sem custos

exorbitantes!

Em outras palavras, você também é responsável pela

estrutura do código que escreve!

Sua carreira é sua responsabilidade!

TreineVá a conferênciasLeia

Não é responsabilidade do seu empregador

Sua empresa te ajuda com isso?

Ótimo! Estão te fazendo um favor.

Mas a responsabilidade ainda é sua!

Também não é responsabilidade do seu empregador te dar “tempo” para você estudar...

“Você recebe por 40 horas para resolver os problemas da sua

empresa não os seus...”

Uncle Bob

Faça as contas....

Sua semana tem 168 horas.

Dê à seu empregador 40, e à sua carreira 20

Sobram 108

+ 56 para dormir 48

+ 52 para ...60

Só não desperdice...

Durante essas 20 horas você deve

estar fazendo algo que gosta, que

aumente ainda mais a sua paixão pelo

que faz.

Esse é o grande segredo!

Além disso,o desenvolvedor

profissional de verdadese preocupa com o código que escreve...

...desenvolve somente código limpo e não consegue mais

escrever código ruim.

Ninguém gosta de encontrar um código ruim !

Raiva

Perda de Tempo

Frustração

Dor

Você fica P...

Mas afinal, o que é um

código limpo?

O que é um código limpo ?

SimplesDiretoEficienteSem duplicidadeEleganteFeito com cuidado

Escolhemos nomes para tudo, então devemos fazer isso bem feito

Nomes significativo

s

- Por que existe;- O que faz;- Como é usado;

O nome deve dizer...

Use nomes que revelem sua intenção

int d; // days

Se um nome de classe ou método requer um comentário, ele não está revelando sua intenção

a1?

int d?a2?

Faça distinções significativas

for (int j=0; j < 34; j++) {s += (t[j]*4)/5;

}

Nomes com apenas uma letra ou numéricos são difíceis de serem encontrados e

entendidos dentro do código.

Use nomes fáceis de encontrar

Use nomes pronunciáveis

Pronuncie seu código

private Timestamp genDMYHS()

private Timestamp generateTimestamp()

Evite palavras

que não são

palavras

Não economize palavras“Use várias palavras para que o método ou variável sejam facilmente entendidos e possam transmitir seu

propósito”

Evite desinformação

Evite palavras que podem ser variáveis ou palavras reservadas em outras

plataformas

Evite desinformação

Evite dar nomes como “listaDeLancamentos”, o tipo não precisa estar no nome

(notação húngara)

Evite desinformação

Evite trocadilhos, escreva exatamente o que você

quer dizer

Nomes de classes devem ser substantivos e não devem conter verbos

Boas práticas

Nomes de métodos devem conter verbos

MétodosClasses

Devem ser pequenos“A primeira regra dos métodos é que eles devem ser pequenos. A

segunda regra é que eles devem ser menores ainda.”

Uncle Bob

Classes menores são mais fáceis de ler e entender o que estão fazendo.

método <= 20 linhaslinha <= 100 caracteres

classe = 200 a 500 linhas

“Métodos e

funções devem

fazer apenas

uma

coisa, fazê-la

certa

e somente faz

ê-la.”

O difícil é defi

nir o

que é “apenas

uma

coisa”

Tentar extrair um novo método de um outro, e dar um nome ao trecho extraído é uma maneira de identificar

Parâmetros

Métodos com muitos parâmetros devem ser evitados e possuírem uma boa justificativa para existirem.

Pois confundem e complicam o entendimento, além de dificultar os testes.

Cuidado com os efeitos colaterais. Eles são mentiras contadas pelo método, quando diz que fará uma coisa, mas faz

outras “escondidas”.

public boolean checkPassword (String password) {String passwordStatus = crypto.decrypt(password);if (passwordStatus.equals(“OK”)) {

Session.initialize();return true;

}return false;

}

CQS - Command Query Separation

Métodos devem fazer algo ou retornar algo, mas não as duas coisas. Isso gera confusão, além de atribuir mais de uma responsabilidade.

Preste atenção no código repetido. Evite duplicidades reaproveitando seus métodos.

DRY - Don’t Repeat Yourself

Para saber se o tamanho da classe é

o ideal, devemos analisar suas

responsabilidades.

Princípio da única da responsabilidade (SRP)

O princípio diz que uma classe deve ter uma, e apenas uma razão para

mudar.

Tentar identificar responsabilidades ajuda a melhorar

nosso código e criar melhores abstrações

Esse é um dos conceitos mais

importantes em OO

Coesão

Cada método deve manipular uma ou mais variáveis.

Classes devem conter poucas variáveis.

Quanto mais variáveis um método manipula, mais coeso

ele é para a classe.

Quando há coesão, significa que métodos e variáveis são

co-dependentes.

Comentários

Comentários podem ser mentirosos e

trazer desinformação,

mesmo sem intenção;

Ele não recebem

“manutenção”, sendo

que quanto mais

velhos maior a chance

de estarem errados.

Comentários não

vão esconder o

código ruim

Geralmente você comenta para que se faça entender.

Quando pensar em comentar, é sinal que seu código deve ser refatorado.

Explique-se no código!

// check if the employee is eligible for benefits if ((employee.flags == 100) && (employee.age > 65))

if (employee.isEligibleForBenefits())

Closing brace comments

try {String nada;while (i = 3) {

i++;...

} // end while } // end if

“Qualquer comentário que faça você olhar para outras

partes do código para entendê-lo, não vale os bits que

consome”. Uncle Bob

Comentários podem ser úteis...

Aviso de consequências que um trecho de código pode vir a causar

Comentários podem ser úteis...

Mostrar a intenção por trás de uma decisão tomada, e não só pela

informação.

Quando alguém vê um código

comentado, não tem coragem de

apagá-lo. Vão pensar que há um

motivo para estar ali.

Nunca deixe código comentado!

Formatação

“Formatação é importante, pois se trata de Comunicação.”

Boa Comunicação é essencial para os desenvolvedores profissionais

A legibilidade do seu código terá profundo efeito em todas as mudanças que serão feitas e seu estilo e disciplina sobrevive mesmo se o código original for

alterado

Métodos com conceitos relacionados devem ficar verticalmente próximos

A ordem dos métodos cria um fluxo de leitura melhorando a legibilidade do código

Uma boa identação do código ajuda a visualizar todo o escopo, torna mais fácil e rápida a

identificação de situações e regras relevantes.

Essa identação não deve ser maior do que 2, para compreensão fácil e rápida

if (a > 0) { if (b > 1) { if (c > 2) { if (d > 3) { if (e > 4) {

Dê espaços entre operadores, parâmetros e vírgulas.

public getSum(int one,int two,double number){double sum=number+(one*two);

}

Espaçamento

public getSum (int one, int two, double number) {double sum = number + (one * two);

}

Tratamento

de erros

Tratar erros é responsabilidade do desenvolvedor, as coisas podem dar errado e nós temos que garantir que nosso código tem

um tratamento para cada situação

Quem faz a chamada deve verificar se há erros no retorno do método, e isso pode ser

facilmente esquecido.

Use exceptions ao invés de

retornar códigos de erro

Crie mensagens informativas para os erros, mencione o que aconteceu, o que estava tentando fazer, e por que o erro ocorreu.

Forneça o contexto na exception

try {MealExpenses expenses = expensesDao.getMeals();total += expenses.getTotal();

} catch (MealExceptionNotFound e) {total += expenses.getMealPerDiem();

}

Separe as regras de negócio de erros ou outras situações.

Prefira retornar Special case objects ou vazio no caso de

coleções

Não retorne null

Não passe null

Evite passar null para seus métodos, isso

pode gerar as famosas

NullPointerExceptions

Testes unitários

As Três Leis do TDD

As Três Leis do TDD

1 - Você não pode escrever o código até que tenha criado um teste falhando.

As Três Leis do TDD

1 - Você não pode escrever o código até que tenha criado um teste falhando.

2 - Você não pode escrever mais testes do que seja suficiente para falhar.

As Três Leis do TDD

1 - Você não pode escrever o código até que tenha criado um teste falhando.

2 - Você não pode escrever mais testes do que seja suficiente para falhar.

3 - Você não pode escrever mais código do que o suficiente para passar o teste que esta falhando.

conceito por teste

Separe um teste que esteja testando mais de um

conceito em outros testes.

Facilite o entendimento de cada teste.

1

F.I.R.S.TTestes

Os testes devem ser rápidos para executar, pois quando são lentos a frequência de execução

diminui.

Fast

Testes não podem depender uns dos outros, pois se um falha os outros também

falharam

Independent

Ao executa-los mais de uma vez, devem sempre retornar o mesmo resultado

Repeatable

Devem possuir respostas booleanas, sem precisar de interpretação para saber o

resultado.

Self-Validating

Os testes devem ser escritos antes do código. Após o código será mais

difícil fazer o teste.

Timely

O código do teste é tão importante quanto o código da produção

O teste precisa sofrer alterações da mesma forma que o código.

Quanto mais sujo o teste mais difícil dar

manutenção, e menor a flexibilidade para alterá-lo.

“Se você deixar seus testes

apodrecerem, seu código também apodrecerá”

Fique atento aos Maus cheiros

- Comentários pobres, obsoletos e redundantes

- Código comentado

- Testes que requerem mais de um passo

- Muitos parâmetros ou parâmetros boolean

- Métodos mortos ou que fazem muita coisa

- Responsabilidades fora do contexto

- Nomes pequenos e inexpressivos

- Duplicação- Inconsistência- Intenção obscura- Variáveis e funções inexpressivas- Despadronização- Números mágicos- Desencapsulamento- Efeitos colaterais- Testes inuficientes

Você não se torna um bom programador aprendendo uma lista de regras.

Clean code não foi escrito para ser uma lista de regras

As técnicas e práticas têm que começar a fazer parte do nosso dia a dia.

Devemos nos preocupar com a qualidade do código e não somente fazê-lo funcionar.

Conclusão

“Você é responsável pelo código que escreve”

Referências

Muito Obrigado!

@andrefariahttp://blog.andrefaria.com

http://blog.bluesoft.com.br

@bruno_luihttp://brunolui.com