Palestra sobre codificação limpa e boas práticas de desenvolvimento de sistemas. Juliana Fideles.

1. 25ª Semana da Tecnologia
da Fatec Sorocaba
<Juliana Fideles>
{ gerente de projetos • full stack developer }

2. Quemsoueu?
• Formada em Análise e Desenvolvimento de Sistemas
pela Fatec Sorocaba e pós-graduada em
gerenciamento de projetos pelo Senac Sorocaba.
• Possui mais de 6 anos de experiência na área de
tecnologia da informação. Mais de 2 anos atuando
como voluntária na gestão de projetos e atividades do
Branch Sorocaba do PMI.
• Conhecimentos de gestão de projetos seguindo o guia
PMBoK/PMI e vivência em projetos ágeis.
• Atua como voluntária na coordenação do Branch
Sorocaba do PMI São Paulo.
• Gerente de Projetos em consultoria de planejamento
em Alphaville_

3. Voutecontarumahistória...
+ =
Programador + demanda, chefe com pressa = gambiarra, código ruim!

4. Parecebomacurtoprazo,mas...
Alongoprazooproblemavaisetornaralgomaior...

5. Exemplodepráticasruins...

6. Consequências...
• Novas implementações começam a ficar inviáveis;
• Maior custo/tempo de manutenção;
• Replanejar/remodelar o projeto todo - jogar fora e recomeçar do zero :(

7. Porqueescrevemoscódigosruins?
• Pressa;
• Pressão do cliente/gerente;
• Pelo cansaço de trabalhar no requisito/demanda;
• Excesso de tarefas;
• Aprenda a dizer não!

8. Afinal,queméoculpado?

9. Porquevocêestáaquihoje?
• É ou pretende ser programador(a)
• Deseja ser um profissional ainda melhor :)
• Deseja escrever um Código Limpo :D

10. 25ª Semana da Tecnologia
da Fatec Sorocaba

12. Códigolimpo:
•Elegante, centralizado (um único objetivo);
•Coberto de testes;
•Refatorar* quando preciso;
•Fácil manutenção;

13. Códigolimpo:
"Qualquer um consegue escrever código que um computador
entende. Bons programadores escrevem código que humanos
endentem“ - Martin Fowler

14. Códigolimpo:
•Legível, de fácil entendimento/narração;
•Padrões definidos e nomenclatura que identifique o propósito;
•Modularizado;

15. Códigolimpo:
“Não é a linguagem que faz os programas parecerem simples, é
o programador.”

16. Códigolimpo:
•Um código limpo faz a linguagem parecer adequada para o
problema;
•Não há como criar um código sem lê-lo, portanto torná-lo de fácil
leitura facilita a escrita;
•Buscar o aperfeiçoamento contínuo do projeto :)

17. 25ª Semana da Tecnologia
da Fatec Sorocaba

18. Nomessignificativos</>
•Use nomes que identifique o propósito;
•Clareza e simplicidade do código nos nomes de variáveis e
funções;
•Mudar variáveis para funções que descrevam seu
comportamento;

19. Nomessignificativos</>
•Evitar nomes abreviados, confusos ou semelhantes em funções e
variáveis;
•Evitar nomes que possam gerar ambiguidade no entendimento (Ex: l e
1);
•Nomes de variáveis não devem conter “variável”, “tabela” etc.
•Fazer distinção dos nomes de maneira que o leitor entenda as
diferenças;

20. Nomessignificativos</>
•Usar nomes pronunciáveis e pesquisáveis;

21. Nomessignificativos</>
•Nomes devem revelar a função/objetivo do código;
•Classes devem ser substantivos (Ex: Pessoa, Usuario, Funcionario)
•Métodos devem ser conter verbos e indicar uma ação:
• buscarRegistro()
• excluir()
• gerarBoleto()

22. Funções(){
•Dividir grandes blocos de código em funções menores - modularizar;
•A função no deve ser maior que a tela;
•Apenas uma linha dentro do if, else e while, geralmente chamando
outra função (com o descritivo da função);
•A função deve fazer apenas uma coisa;
•“Extrair” uma função de outra função;

23. Olhe o trecho de código em destaque...

24. Extraímos uma função daquele trecho, tornando o código legível!

25. Essa função deveria apenas fazer o upload de uma imagem, mas faz outras coisas!
O nome da função não condiz com o que ela faz.

26. Endentação(ou
identação)...

27. Visualmente melhor <3

28. Endentação(ouidentação)...
•Formatação: o que vale é a regra do time! {
}

29. Comentários*/
• Se o código for expressivo o suficiente, não precisa de comentários! Melhore
a narrativa do seu código ;)
• No geral, comentários servem para explicar um código ruim – o bom código é
auto documentado;
• Comentários vão ficando defasados ao longo da escrita do código;
• O ideal é focar esforços em tornar o código mais descritivo;
• Criar funções onde o nome da função diga a mesma coisa que o código diria;

30. Comentários*/

31. Comentários*/
•Quando houver comentários legais e sobre direitos autorais, é válido
fazer a referência a qual lei/licença a qual esse comentário se refere;
•Comentários informativos sobre retorno de objetos podem ser úteis –
mas só quando não houver outra alternativa;
•Usar comentários também quando desejar documentar uma decisão que
foi tomada no código (um retorno, uma prioridade etc);

32. Comentários*/
•Comentários para esclarecer parâmetros, valores, ou coisas inteligíveis.
Porém sempre há o risco desse comentário “esclarecedor” estar errado
ou defasado;
•Deixar comentários TODO, sobre a definição do que fazer em um
método, pode ser útil;
•Documentação de API’s públicas;

33. Objetoseestruturadedados;

34. Esse código facilita a adição de novas
funções sem precisar alterar a estrutura
de dados (classe e propriedades
existentes).
Aqui seria fácil adicionar um métodos
Perímetro a Classe Geometria.

35. Já esse código implementa funções de
uma classe abstrata Shape, e facilita
adicionar novas classes sem precisar
alterar as funções existentes.

36. Lei de demeter {
•Princípio do “mínimo conhecimento possível”;
•1 – Uma entidade deve conhecer o mínimo possível de outras entidades;
•2 – uma entidade só deve se relacionar com “amigos” (não deve falar
com “estranhos”);
•3 – Somente falar somente com “amigos próximos”;

37. Lei de demeter {
•Em resumo:
Um método M de uma classe C só conhece:
•Métodos de C
•Objetos criados por M
•Objetos passados como argumentos para M
•Objetos em variáveis de instâncias de C

38. Lei de demeter {
•Benefícios:
•Melhora a manutenção de código;
•Mais fácil de adaptar/expandir classes;
•Menos dependências;

39. Tratamento de erros!
•Exceções tratadas ao invés de códigos/strings de erros;
•Tratamento de exceções devem estar dentro das funções ou métodos;
•Não usar exceções genéricas: tratar as exceções para cada tipo de erro;
•Não retornar nulo nas exceções;

40. Dicas finais =)
•Melhoria contínua;
•Não deixe acumular problemas – ócio produtivo ;)
•Refatoração do código do amiguinho;
•Falar sobre código limpo é o primeiro passo ;)

41. Referência:
• The Clean Coder - Robert C.
Martin Programador desde 1970;
Fundador e Presidente Object
Mentor Inc. Livros:
• Designing Object-Oriented C++
Applications using the Booch Method.
1995.
• Agile Software Development:
Principles, Patterns and Practices.
2002.
• Clean Code: A Handbook of Agile
Software Craftsmanship.

42. 25ª Semana da Tecnologia da
Fatec Sorocaba
<Juliana Fideles>
{ gerente de projetos • full stack developer }
www.linkedin.com/in/julianafideles