Apresentação realizada com o @andrefaria no Agile Brazil 2012. Nos livros Clean Code e Clean CodeR, Robert Martin descreveu o que significa ser um desenvolvedor de software profissional, como ele deve se comportar, e como deve escrever código. Nessa palestra gostaríamos de apresentar um pouco sobre o que temos aprendido utilizando as técnicas de Clean Code e como você pode, a partir delas, tornar sua equipe mais ágil, melhorar a qualidade e produtividade e tornar sua aplicação flexível para obter respostas rápidas às solicitações do mercado.

1. Clean Code
’
Desenvolvendo como um Profissional Agil
André Faria Bruno Lui
@andrefaria @bruno_lui

2. André Faria Gomes
CIO na Bluesoft
+10 de Anos de Desenvolvimento de Software
Black Belt Lean 6 Sigma
Instrutor da Adaptworks
@andrefaria
http://blog.andrefaria.com
http://blog.bluesoft.com.br

3. Bruno Lui
Desenvolvedor na Bluesoft
+5 Anos no Desenvolvimento de Software
@brunolui
http://brunolui.com

4. Então você quer ser
um desenvolvedor de
software
profissional?

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

6. Cuidado com o
que você Pede!

7. Profissionalismo é
sem dúvida digno
de honra e
orgulho, mas
também é
responsabilidade.

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

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

10. Quando um
não-profissional faz
uma besteira, seu
empregador limpa a
bagunça...

11. Quando um profissional
faz uma besteira, ele
limpa a bagunça!

12. O que você faz para escrever
software sem defeitos?

13. Você se responsabiliza pelos defeitos
que cria?

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

15. Como você pode dizer
que é responsável se
não os escreve?

16. “Toda a linha de código que você
escreve deve estar testada, e
Ponto Final!”
Uncle Bob

17. Código escrito por
profissionais pode ser
alterado sem custos
exorbitantes!

18. Em outras palavras,
você também é
responsável pela
estrutura do código que
escreve!

19. Sua carreira é sua
responsabilidade!
Leia Treine
Vá a conferências
Não é responsabilidade
do seu empregador

20. Sua empresa te ajuda
com isso?
Ótimo! Estão te
fazendo um favor.

21. Mas a
responsabilidade
ainda é sua!

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

23. “Você recebe por 40
horas para resolver
os problemas da sua
empresa não os
seus...”
Uncle Bob

24. Faça as contas....

25. Sua semana tem 168 horas.

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

27. Sobram 108

28. + 56 para dormir
48

29. + 52 para ...
60

47. Só não desperdice...

49. Durante essas 20
horas você deve
estar fazendo algo
que gosta, que
aumente ainda mais
a sua paixão pelo
que faz.

50. Esse é o grande
segredo!

51. Além disso,
o desenvolvedor
profissional de verdade
se preocupa com o
código que escreve...

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

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

54. Raiva

55. Perda de Tempo

56. Frustração

57. Dor

58. Você fica P...

59. Mas afinal, o
que é um
código limpo?

60. O que é um código limpo ?
Simples
Direto
Eficiente
Sem duplicidade
Elegante
Feito com cuidado

61. N om es
nific ati vos
s ig
Escolhemos nomes
para tudo, então
devemos fazer
isso bem feito

62. O nome deve dizer...
- Por que existe;
- O que faz;
- Como é usado;

63. Use nomes que revelem sua intenção

64. int d; // days
Se um nome de classe ou método requer um
comentário, ele não está revelando sua intenção

65. Faça distinções
significativas
a1?
a2?
int d?

66. 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.

67. Use nome
s
fáceis de
encontrar

68. Use nome
s
pronunciáv
eis

69. private Timestamp genDMYHS()
Pronuncie seu código
private Timestamp generateTimestamp()

70. e pa lavras
Evit
não são
que
palavras

71. 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”

72. Evite palavras que podem
ser variáveis ou palavras
reservadas em outras
plataformas
Evite desinformação

73. Evite dar nomes como
“listaDeLancamentos”, o tipo
não precisa estar no nome
(notação húngara)
Evite desinformação

74. Evite trocadilhos, escreva
exatamente o que você
quer dizer
Evite desinformação

75. prát icas
B oas
Nomes de classes devem ser
substantivos e não devem conter verbos
Nomes de métodos devem conter verbos

76. Class es odos
M ét

77. 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.

78. método <= 20 linhas
linha <= 100 caracteres
classe = 200 a 500 linhas

79. e
éto dos
“M
s d evem
fun çõe uma
apenas
faz er certa
faz ê-la
cois a,
azê -la.”
ent e f
e s om

80. efin ir o
é d
O difícil uma
ape nas
é “
que
co isa”

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

82. 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.

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

84. public boolean checkPassword (String password) {
String passwordStatus = crypto.decrypt(password);
if (passwordStatus.equals(“OK”)) {
Session.initialize();
return true;
}
return false;
}

85. 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.

86. DRY - Don’t Repeat Yourself
Preste atenção no código repetido. Evite duplicidades
reaproveitando seus métodos.

87. Para saber se o
tamanho da classe é
o ideal, devemos
analisar suas
responsabilidades.

88. Princípio da única da responsabilidade (SRP)
O princípio diz que uma
classe deve ter uma, e
apenas uma razão para
mudar.

89. Tentar identificar
responsabilidades
ajuda a melhorar
nosso código e criar
melhores abstrações
Esse é um dos
conceitos mais
importantes em OO

90. Coesão
Classes devem conter poucas variáveis.
Cada método deve manipular
uma ou mais 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.

91. Comentários

92. Comentários pode
m
ser mentirosos
e
trazer
desinformação,
mesmo sem inte
nção;

93. Ele não recebem
“man utenção”, sendo
que quanto mais
velhos maior a chance
de e starem errados.

94. Come ntá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.

95. // check if the employee is eligible for benefits
if ((employee.flags == 100) && (employee.age > 65))
Explique-se no código!
if (employee.isEligibleForBenefits())

96. Closing brace comments
try {
String nada;
while (i = 3) {
i++;
...
} // end while
} // end if

97. utras
ça v ocê olhar para o
“Qualquer c omentário que fa que
lo, não vale os bits
partes do cód igo para entendê-
consome”. Uncle Bob

98. Comentários podem ser úteis...
Aviso de
consequências que
um trecho de código
pode vir a causar

99. Com entários podem ser úteis...
Mostrar a intenção
por trás de uma decisão
tomada, e não só pela
informação.

100. Nunca deixe
código comentado!
Quando alguém vê um código
de
comentado, não tem coragem
um
apagá-lo. Vão pensar que há
motivo para estar ali.

101. matação
Fo r

102. “Formatação é importante, pois se
trata de Comunicação.”
Boa Comunicação é essencial para os
desenvolvedores profissionais

103. 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

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

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

106. 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.

107. 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) {

108. Espaçamento
public getSum(int one,int two,double number){
double sum=number+(one*two);
}
Dê espaços entre operadores, parâmetros e vírgulas.
public getSum (int one, int two, double number) {
double sum = number + (one * two);
}

109. tam ento
T ra
de erros

110. 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

111. Use exceptio ns ao invés de
retornar c ódigos de erro
Quem faz a chamada deve
verificar se há erros no retorno
do método, e isso pode ser
facilmente esquecido.

112. Forneça o contexto
na exception
Crie mensagens
informativas para os
erros, mencione o que
aconteceu, o que estava
tentando fazer, e por
que o erro ocorreu.

113. Separe as regras de negócio de erros ou
outras situações.
try {
MealExpenses expenses = expensesDao.getMeals();
total += expenses.getTotal();
} catch (MealExceptionNotFound e) {
total += expenses.getMealPerDiem();
}

114. Não retorne null
Prefira retornar
Special case objects
ou vazio no caso de
coleções

115. Não passe null
Evite passar null para
seus métodos, isso
pode gerar as
famosas
NullPointerExceptions

116. Testes
unitários

117. As Três Leis do TDD

118. As Três Leis do TDD
1 - Você não pode escrever o código
até que tenha criado um teste
falhando.

119. 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.

120. 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.

121. 1 conceito por teste
Separe um teste que esteja
testando mais de um
conceito em outros testes.
Facilite o entendimento
de cada teste.

122. Te stes
F.I.R .S.T

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

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

125. R epeatable
Ao executa-los mais de uma vez, devem
sempre retornar o mesmo resultado

126. Self-Validating
Devem possuir respostas
booleanas, sem precisar de
interpretação para saber o
resultado.

127. T imely
Os testes devem ser
escritos antes do código.
Após o código será mais
difícil fazer o teste.

128. 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.

129. Quanto mais sujo o
teste mais difícil dar
manutenção, e menor a
flexibilidade para alterá-lo.

130. “Se você deixar
seus testes
apodrecerem, seu
código também
apodrecerá”

131. Fique atento
aos Maus
cheiros

132. - 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

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

134. Conclusão
Clean code não foi escrito para ser uma lista de regras
Você não se torna um bom programador aprendendo
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.

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

136. Referências

137. Muito Obrigado!
@andrefaria @bruno_lui
http://blog.andrefaria.com http://brunolui.com
http://blog.bluesoft.com.br