Clean Code - Desenvolvendo como um Profissional Ágil
-
date post
19-Oct-2014 -
Category
Technology
-
view
3.715 -
download
7
Embed Size (px)
description
Transcript of Clean Code - Desenvolvendo como um Profissional Ágil
Desenvolvendo como um Profissional Agil
Andr [email protected] @bruno_luiBruno 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
Ento voc quer ser um desenvolvedor de
software profissional?
Quer que as mes apontem para voc e digam a seus filhos para que sejam como
voc?
Cuidado com o que voc Pede!
Profissionalismo sem dvida digno
de honra e orgulho, mas tambm
responsabilidade.
Voc no pode se orgulhar de algo pelo qual no se responsabiliza...
muito mais fcil ser um largado... No se responsabilizar pelo trabalho e pela carreira....
Quando um no-profissional faz uma besteira, seu empregador limpa a
baguna...
Quando um profissional faz uma besteira, ele
limpa a baguna!
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 responsvel se
no os escreve?
Toda a linha de cdigo que voc escreve deve estar testada, e
Ponto Final!Uncle Bob
Cdigo escrito por profissionais pode ser alterado sem custos
exorbitantes!
Em outras palavras, voc tambm responsvel pela
estrutura do cdigo que escreve!
Sua carreira sua responsabilidade!
TreineV a confernciasLeia
No responsabilidade do seu empregador
Sua empresa te ajuda com isso?
timo! Esto te fazendo um favor.
Mas a responsabilidade ainda sua!
Tambm no responsabilidade do seu empregador te dar tempo para voc estudar...
Voc recebe por 40 horas para resolver os problemas da sua
empresa no os seus...
Uncle Bob
Faa 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 no desperdice...
Durante essas 20 horas voc deve
estar fazendo algo que gosta, que
aumente ainda mais a sua paixo pelo
que faz.
Esse o grande segredo!
Alm disso,o desenvolvedor
profissional de verdadese preocupa com o cdigo que escreve...
...desenvolve somente cdigo limpo e no consegue mais
escrever cdigo ruim.
Ningum gosta de encontrar um cdigo ruim !
Raiva
Perda de Tempo
Frustrao
Dor
Voc fica P...
Mas afinal, o que um
cdigo limpo?
O que um cdigo limpo ?SimplesDiretoEficienteSem duplicidadeEleganteFeito com cuidado
Escolhemos nomes para tudo, ento devemos fazer isso bem feito
Nomes significativos
- Por que existe;- O que faz;- Como usado;
O nome deve dizer...
Use nomes que revelem sua inteno
int d; // days
Se um nome de classe ou mtodo requer um comentrio, ele no est revelando sua inteno
a1?
int d?a2?
Faa distines significativas
for (int j=0; j < 34; j++) {s += (t[j]*4)/5;
}
Nomes com apenas uma letra ou numricos so difceis de serem encontrados e
entendidos dentro do cdigo.
Use nomes fceis de encontrar
Use nomes pronunciveis
Pronuncie seu cdigo
private Timestamp genDMYHS()
private Timestamp generateTimestamp()
Evite palavras
que no so
palavras
No economize palavrasUse vrias palavras para que o mtodo ou varivel sejam facilmente entendidos e possam transmitir seu
propsito
Evite desinformao
Evite palavras que podem ser variveis ou palavras reservadas em outras
plataformas
Evite desinformao
Evite dar nomes como listaDeLancamentos, o tipo no precisa estar no nome
(notao hngara)
Evite desinformao
Evite trocadilhos, escreva exatamente o que voc
quer dizer
Nomes de classes devem ser substantivos e no devem conter verbos
Boas prticas
Nomes de mtodos devem conter verbos
MtodosClasses
Devem ser pequenosA primeira regra dos mtodos que eles devem ser pequenos. A
segunda regra que eles devem ser menores ainda.
Uncle Bob
Classes menores so mais fceis de ler e entender o que esto fazendo.
mtodo 0) { if (b > 1) { if (c > 2) { if (d > 3) { if (e > 4) {
D espaos entre operadores, parmetros e vrgulas.
public getSum(int one,int two,double number){double sum=number+(one*two);
}
Espaamento
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 ns temos que garantir que nosso cdigo tem
um tratamento para cada situao
Quem faz a chamada deve verificar se h erros no retorno do mtodo, e isso pode ser
facilmente esquecido.
Use exceptions ao invs de
retornar cdigos de erro
Crie mensagens informativas para os erros, mencione o que aconteceu, o que estava tentando fazer, e por que o erro ocorreu.
Fornea o contexto na exception
try {MealExpenses expenses = expensesDao.getMeals();total += expenses.getTotal();
} catch (MealExceptionNotFound e) {total += expenses.getMealPerDiem();
}
Separe as regras de negcio de erros ou outras situaes.
Prefira retornar Special case objects ou vazio no caso de
colees
No retorne null
No passe null
Evite passar null para seus mtodos, isso
pode gerar as famosas
NullPointerExceptions
Testes unitrios
As Trs Leis do TDD
As Trs Leis do TDD
1 - Voc no pode escrever o cdigo at que tenha criado um teste falhando.
As Trs Leis do TDD
1 - Voc no pode escrever o cdigo at que tenha criado um teste falhando.
2 - Voc no pode escrever mais testes do que seja suficiente para falhar.
As Trs Leis do TDD
1 - Voc no pode escrever o cdigo at que tenha criado um teste falhando.
2 - Voc no pode escrever mais testes do que seja suficiente para falhar.3 - Voc no pode escrever mais cdigo 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 rpidos para executar, pois quando so lentos a frequncia de execuo
diminui.
Fast
Testes no podem depender uns dos outros, pois se um falha os outros tambm
falharam
Independent
Ao executa-los mais de uma vez, devem sempre retornar o mesmo resultado
Repeatable
Devem possuir respostas booleanas, sem precisar de interpretao para saber o
resultado.
Self-Validating
Os testes devem ser escritos antes do cdigo. Aps o cdigo ser mais
difcil fazer o teste.
Timely
O cdigo do teste to importante quanto o cdigo da produo
O teste precisa sofrer alteraes da mesma forma que o cdigo.
Quanto mais sujo o teste mais difcil dar
manuteno, e menor a flexibilidade para alter-lo.
Se voc deixar seus testes
apodrecerem, seu cdigo tambm apodrecer
Fique atento aos Maus cheiros
- Comentrios pobres, obsoletos e redundantes
- Cdigo comentado
- Testes que requerem mais de um passo
- Muitos parmetros ou parmetros boolean
- Mtodos mortos ou que fazem muita coisa
- Responsabilidades fora do contexto
- Nomes pequenos e inexpressivos
- Duplicao- Inconsistncia- Inteno obscura- Variveis e funes inexpressivas- Despadronizao- Nmeros mgicos- Desencapsulamento- Efeitos colaterais- Testes inuficientes
Voc no se torna um bom programador aprendendo uma lista de regras.
Clean code no foi escrito para ser uma lista de regras
As tcnicas e prticas tm que comear a fazer parte do nosso dia a dia.
Devemos nos preocupar com a qualidade do cdigo e no somente faz-lo funcionar.
Concluso
Voc responsvel pelo cdigo que escreve
Referncias
Muito Obrigado!
@andrefariahttp://blog.andrefaria.com
http://blog.bluesoft.com.br
@bruno_luihttp://brunolui.com