1) O documento discute técnicas de desenvolvimento de software limpo e testes unitários usando TDD. 2) É enfatizado que nomes significativos, comentários apenas quando necessário, métodos curtos e classes coesas levam a códigos mais legíveis e de fácil manutenção. 3) Testes unitários aplicados desde o início do projeto por meio de TDD tornam o código mais robusto e facilitam refatorações futuras.

1. TDD com Clean Code
Chega de amadorismo!

2. Alison Rodrigues de Souza
Motociclista
Programador JAVA
Agilista
Certificado Scrum Master

3. André Dias Lima
Programador JAVA
Agilista
Pós-graduando em Metodos Ágeis

4. O mundo está cheio de
gambiarras...

6. WTF?

9. Amadorismo
Significado de Amador segundo
Aurélio: (...) Que pratica qualquer
arte ou esporte, sem ser um
profissional.(...)

10. Desenvolvedor Profissional
Qualquer tolo pode escrever código
que um computador consiga
entender. Bons programadores
escrevem código que HUMANOS
consigam entender.

11. Martin Fowler
martinfowler.com

12. Então…
como podemos
criar código que
humanos
possam
entender?

13. Robert Martin = Uncle Bob

14. “...Um código
limpo é simples e
direto...”
Grady Booch

15. “Big” Dave Thomas
Além do seu
criador, um
desenvolvedor
pode ler e
melhorar um
código limpo...

16. Ron jeffries
Expressa todas
as ideias do
projeto que estão
no sistema….

17. Ward Cunningham
Você sabe que está
criando um código
limpo quando cada
rotina que você le se
mostra como você
esperava...

18. Clean Code
Simples e direto, um desenvolvedor
pode ler.
Cada rotina que você le mostra
como você expressa todas as ideias.

21. Nomes significativos
Faça distinções significativas, use
nomes diferentes dentro de um mesmo
escopo.
Nomes como a1, a2, a3 são o oposto de
nomes que demonstram intenção - são
confusos e não informam nada.

22. Nomes significativos
Evite também usar abreviações ou
trocadilhos, escreva exatamente o
que você quer dizer, o nome deve
ser auto-explicativo.

23. Nomes significativos
É comprovado que um desenvolvedor
passa muito mais tempo lendo
código do que escrevendo, por isso
não se preocupe em economizar
caracteres ao escolher um nome.

24. Comentários
Comentários podem ser úteis se
colocados nos lugares certos, mas
também podem ser mentirosos e trazer
desinformação.

25. Comentários
Na verdade, o melhor comentário é
aquele que não precisa ser escrito.
Um dos principais motivos para você
escrever um comentário é porque o
código está difícil de ser entendido.

26. Comentários
Você acha que o código ficou meio
confuso e acha melhor adicionar um
comentário? Não, você precisa
refatorar!

27. Método
Métodos devem conter no máximo
20 linhas e seu nível de identação
não pode ser maior que dois.

28. Método
Quanto ao conteúdo, um
método deve ter somente
UMA responsabilidade.

29. Classes e Formatação
A legibilidade do código terá profundo efeito sobre
todas as mudanças que serão feitas, seu estilo e
disciplina sobrevive sobre estas mudanças.
Procure escrever classes com no máximo 500
linhas, classes menores são mais fáceis de se
entender. Já para as linhas de código, tente
estabelecer um limite de caracteres por linha.

30. Classes e Formatação
Uma boa identação ajuda a visualizar
melhor todo o escopo e facilita a
identificação de situações e regras
relevantes.

31. Classes e Formatação
Tente manter conceitos
relacionados mais próximos
verticalmente, para criar um
fluxo na leitura do código.

32. Classes e Formatação
Use espaços entre
operadores, parâmetros e
vírgulas.

33. Classes e Formatação
Evite deixar o código todo
grudado.

34. Tratamentos de erros
Prefira lançar uma exception ao invés
de retornar um código de erro, estes
retornos desorganizam a chamada do
método.

36. Tipos de testes

41. Kent Beck

42. Não existe
desenvolvedor
profissional que
não faça testes
unitários no seu
código!
Klaus
Wuestefeld

45. Unit Test (2 a 7 linhas)

46. Service (Máximo 20 linhas)

47. Por que usar TDD?

48. Bateria de testes cresce

49. O código já nasce testado

50. Me faz pensar no requisito

51. Simplicidade

52. Me ajuda no design

53. Maior segurança para mudanças

54. Exemplos de testes

55. TDD em Código legado

56. TDD em Código legado

58. #SomosTodosProgramadores

59. Obrigado!

60. Contatos
Site/Blog: alisonsouza.com.br
Twitter: @AlisonRSouza
GitHub: AlisonSouza
E-mail: contato@alisonsouza.com.br