O documento apresenta princípios básicos de programação e design de software, incluindo maus cheiros de código, código limpo e os cinco princípios SOLID (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation e Dependency Inversion). O objetivo é ajudar desenvolvedores a escreverem código de melhor qualidade e mais fácil de manter.

1. Princípios Básicos para
Desenvolvedores
while(!(succeed=try()))
Guilherme Reis

2. Agenda
• Dicas para iniciantes;
• Mau cheiro;
• Porque se importar com o código;
• Código limpo;
• Princípios básicos de design;

3. Programação...

4. Programação é lógica,
não magia negra
• “Eu gosto de programar, só não gosto de lógica” (Ex-
aluno de Computação)

5. Antes de codificar, pense
no que quer/precisa fazer

6. Não funcionará na primeira vez!
Provavelmente nem na segunda ou terceira;

7. Mas quando funciona...

8. Trabalho em equipe

9. 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;

10. 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*;

11. Baixa Coesão

12. Alto Acoplamento
• Forte dependência entre componentes;
• Dificulta mudanças;
• Dificulta reaproveitamento de código;

13. Alto Acoplamento

14. Fases de um projeto

15. • 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...

16. 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”;

17. A culpa não é minha...

18. “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;

19. 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;

20. Por que devo me
importar?

21. Por que devo me
importar?

22. Ciclo de um projeto

23. Prevenção

24. Por que devo me
importar?
• Não é só pelaos 20 centavos estética:
• É pelo TEMPO gasto!

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

26. 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;

27. 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?

28. Pensando bem...

29. Código limpo

30. Humanos <- Código
Máquinas <- 01101001010

31. Por falar em nome...

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

33. Nomenclatura
• Qual componente do formulário será mostrado ou
escondido?

34. Nomenclatura
• Qual componente do formulário será mostrado ou
escondido?

35. O que este código faz?

36. Melhor?

37. E assim?

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

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

40. S – Single Responsibility

41. 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;

42. S – Single Responsibility

43. S – Single Responsibility

44. O - Open Closed
• Fechado para edições;
• Aberto para extensões;

45. O - Open Closed

46. O - Open Closed

47. L - Liskov substitution
• As classes derivadas não devem ser mais fracas e nem
mais fortes que sua base

48. L - Liskov substitution
Customer
Gold Silver Guest

49. L - Liskov substitution

50. L - Liskov substitution

51. I - Interface Segregation
• Melhor ter várias interfaces pequenas para propósitos
específicos
• Do que interfaces genéricas enormes

52. I - Interface Segregation

53. I - Interface Segregation

54. D - Dependency inversion
• Dependa de abstrações, não de detalhes concretos

55. D - Dependency inversion

56. D - Dependency inversion

57. Resultado

58. Perguntas

59. Interessado?

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