O documento discute práticas para manter código de alta qualidade, incluindo usar nomes significativos, esclarecer informações com constantes e variáveis, criar funções pequenas com uma única responsabilidade, tratar exceções ao invés de retornos estranhos, e formatar o código de maneira consistente.

1. Mantendo o código
saudável

2. Ciências da Computação - UFSC
MBA em Gerenciamento de Projetos -
FGV
Dígitro Tecnologia
AgileCode
Rosana Angelo Branas

3. Você já se sentiu
desmotivado(a) como
desenvolvedor(a)?

4. A área de desenvolvimento de
software tem uma alta rotatividade!

5. Por que será?

7. Não nos sentimos profissionais

8. Temos a necessidade de sentir
orgulho do que estamos fazendo e
de que estamos sempre evoluindo!

9. Código ruim prejudica tudo que
está ao seu redor, sugando nossas
energias

10. Ficamos o tempo todo
corrigindo defeitos…

11. Demora cada vez mais tempo
para lançar novas versões…

12. Muita gente começa a
desistir no meio do caminho…

13. Código ruim causa um efeito
muito nocivo

14. Com o tempo fica impossível
continuar

15. Por que existe
tanto código ruim?

16. Questão cultural

17. 1. READ INPUT TAPE A1, B1, C1;
2. 501 FORMAT A1;
3. IF (A1) 777, 777, 777
4. IF (B1) 888, 888, 888
5. IF (C1) 999, 999, 999
6. STOP 1
7. 799 S = FLOATF(A1 + B1 + C1) /
2.0
8. WRITE TO TAPE S
9. END PROCESS
As linguagens tinham restrições

18. Os ambientes limitavam

19. Os computadores limitavam

20. Geralmente quem manda não
entende de desenvolvimento
de software

21. "THE ONLY WAY
TO GO FAST IS TO
GO WELL.”
ROBERT MARTIN

22. Passamos a maior parte do
tempo lendo o código

23. Se você vê alguém digitando
rápido, ele não está
programando

24. Por isso, quanto mais
investimos em refactoring,
mais tempo economizamos.
E o inverso também é
verdadeiro.

25. “Refactoring é uma alteração
feita na estrutura interna do
software para mantê-lo mais fácil
de ser entendido e menos custoso
de ser modificado sem alterar seu
comportamento observável.”
MARTIN FOWLER

26. Refatore sempre que surgir a
oportunidade!

27. Como dar os
primeiros passos?

28. NOMES COM
SIGNIFICADO
1

29. Invista tempo em escolher
bons nomes

30. Usar nomes claros, que
revelam a intenção

31. Melhor um nome grande do
que um confuso

32. Use nomes relacionados ao
domínio da solução

33. ESCLAREÇA
INFORMAÇÕES
2

34. Declare constantes, variáveis
e funções sempre que isso
servir para melhorar o
entendimento do código

38. FUNÇÕES
3

39. Qual o tamanho ideal
de uma função?

40. Deve ser o menor possível

41. Funções devem ter uma
única responsabilidade

42. Use um nome por conceito
abstrato

43. Evitar side effects

45. ARGUMENTOS

46. Qual a quantidade
de parâmetros ideal?

47. Nenhum

48. Use no máximo 3
argumentos

49. Quando uma função parece
precisar de muitos argumentos,
talvez alguns deles possam ser
agrupados em um objeto

50. Evite argumentos do tipo flag
- true/false

51. Evite argumentos do tipo flag
- true/false

52. RETORNO

53. Funções devem fazer algo ou
retornar algo, nunca ambos

56. Prefira tratamento de exceções
a retornos estranhos

58. TRATAMENTO DE
EXCEÇÕES

59. De preferência usar blocos
try-catch “isolados"

60. COMENTÁRIOS
5

61. Comentários tentam
desvendar um código que
não está claro

62. “THE PROPER USE OF
COMMENTS IS TO
COMPENSATE FOR OUR
FAILURE TO EXPRESS
OURSELF IN CODE.”
ROBERT MARTIN

64. “DON’T COMMENT
BAD CODE -
REWRITE IT.”
BRIAN W. KERNINGHAN E
P. J. PLAUGHER

65. Comentários mentem,
mesmo sem intenção

66. ‣ Comentário legal
‣ TODO
‣ Formato específico que
uma função retorna, etc.
Comentários são aceitáveis
quando não é possível
esclarecer com código

67. CÓDIGO
DESNECESSÁRIO
6

68. Código não usado deve ser
descartado
• Variáveis
• Parâmetros
• Funções
• Classes
• Códigos comentados

69. Abomine código duplicado

70. “DUPLICATION MAY
BE THE ROOT OF ALL
EVIL IN SOFTWARE.”
ROBERT MARTIN

72. FORMATAÇÃO
DO CÓDIGO
7

73. Definir um code style com a
equipe e segui-lo

74. Se possível, "automatize"

75. Manter arquivos pequenos

76. Organizar o código usando a
stepdown rule facilita a
legibilidade

78. FORMATAÇÃO
HORIZONTAL

79. Usar o tamanho da linha com
moderação

80. Sempre procurar formas de
quebrar o código de modo a
garantir a legibilidade

81. Sempre procurar formas de
quebrar o código de modo a
garantir a legibilidade

82. Se é necessário alinhamento
horizontal, tem algo errado

83. Cuidar com a distância da
margem

85. Simplificar estruturas de decisão

88. DECLARAÇÃO DE
VARIÁVEIS

89. Variáveis de instância devem
ficar no topo da classe

90. Se as funções são pequenas,
as variáveis devem ser
declaradas todas juntas no
topo da função

91. Caso contrário, variáveis
devem ser declaradas
próximas do seu uso

92. FUNÇÕES

93. Se uma função chama outra,
elas devem estar próximas
FUNÇÃO CHAMADORA
FUNÇÃO CHAMADA

94. Quanto maior a afinidade
conceitual, menor a distância
entre duas funções

95. Quanto mais importante o
conceito, mais para cima
deve estar

97. Questione-se
sempre!!!

98. Ajude a promover a cultura
da qualidade de código

99. Adote o Code Review: Evoluímos
e ajudamos outros a evoluírem

100. Crie testes automatizados
para garantir a integridade
do código após alterações

101. Obrigada!