[2023] Código Limpo: dicas práticas para turbinar a escrita, leitura e escalabilidade de um código

[Palestra realizada no evento ROGADX 2023 em Maceió-AL /Brasil]

Todo código é uma sequência de ações que definimos para que a máquina execute algo, e muitas vezes escrevê-las pode parecer simples, mas com certeza você já se deparou com várias perguntas pelo processo. Será que o nome desta variável ou método está ok? Será que poderia criar um método para determinado bloco de código ou até criar outras classes, refatorar? E tenho certeza que não param por aí.

Sentindo esse problema e alguns outros relacionados em diversos ecossistemas, Robert C. Martin ou também conhecido popularmente como “Uncle Bob”, escreveu um livro chamado Clean Code, nele é possível encontrar formas de como escrever códigos bons e como transformar um ruim em um bom, e muitas outras coisas essenciais.

Meu objetivo com esta palestra é mostrar essa visão de maneira prática com dicas chave e também com algumas perspectivas pessoais, que por mais que sejam simples e muitas vezes ignoradas contribuem significativamente para que o código cresça de maneira limpa, saudável e escalável.

Transcript

1. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ /> } /> [ Código Limpo: @denisvieira05 Dicas práticas para turbinar a escrita, leitura e escalabilidade de um código
2. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ Salvee 👋 EU SOU O DENIS, • Quase 10 anos trabalhando com Engenharia de Software • Atualmente Especialista em Desenvolvimento Android na • Graduado Bach. Sistemas de Informação pelo • Algumas empresas que já atuei: /> **
3. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ Introdução COMBINADOS Não sou dono da verdade, apesar de algumas teorias, quero discutir cada tema com vocês e conhecer vocês! Inspiração: Livro chamado Clean Code e muita prática e experiência no mercado Mostrar uma visão de maneira prática com dicas chave e também com algumas perspectivas pessoais.
4. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ Código sujo? • Você já foi impedido de programar bem por conta de um código ruim??? • Qualquer código que gere obstáculos desnecessários e atrasos no trabalho de desenvolvedores. • Problemas comuns: ◦ Mexer em um lugar e quebrar em outro nada haver ◦ Medo em alterar ◦ Curva de aprendizagem alta ◦ Regras de negócio nada claras
5. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ Por que acabamos fazendo um código sujo? • Estavamos tentando entregar resultados muito rápidos. • Percebemos que não daria tempo de entregar um bom trabalho, então entrega qualquer coisa apenas que funcione. • Nós já estamos de saco cheio da tarefa e concluimos de qualquer forma somente funcionando para pegar uma próxima tarefa mais interessante. • Os requisitos mudaram muito ao longo do caminho. • O chefe não entende o que você faz, o cliente muito menos e só reclamam do seu trabalho, então só fazemos funcionar e abandonamos.
6. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ Por que devemos procurar escrever um código limpo? • Caso você fosse um médico e seu paciente (apressado) pedisse para que você não lavasse as mãos para que a cirurgia fosse mais rápida, você iria obedecer? • Seja profissional e não seja apenas um executor, exponha seu conhecimento e profissionalismo ao máximo e mesmo que seja obrigado a fazer de um jeito "sujo" declare publicamente sua opinião e conhecimento. • Mesmo trabalhando sozinho em um projeto, tudo que vai volta eim, aquele código ruim de hoje pode voltar pra você mesmo no futuro e vc vai se estressar com ele e possivelmente gerar mais trabalho.
7. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ Por que devemos procurar escrever um código limpo? IMPACTO & INFLUÊNCIA EXPERTISE TÉCNICA NETWORKING E RELACIONAMENTOS
8. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ Inspiração "Uncle Bob" Robert C. Martin Livro: Clean Code • Filosofia de desenvolvimento cuja o principal objetivo é aplicar técnicas simples que visam facilitar a escrita e leitura de um código • Principal perspectiva é a de que detalhes importam. • Professor, Autor, Programador… • Personalidade da comunidade de desenvolvimento de software, métodos ágeis e software craftsmanship • Foi um dos 17 signatários originais do Agile Manifesto em 2001 • + Livros: Arquitetura limpa, O codificador limpo… /> **
9. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ O que é um código limpo? Mais do que príncipios.. “Um código limpo sempre parece que foi escrito por alguém que se importava” – Michael Feather "É não precisar ler a implementação para saber o que aquele método/classe faz" é ter consciência de que o código limpo que você escreve hoje é um investimento, o qual o seu EU do futuro irá agradecer.
10. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 "Qualquer um consegue escrever código que um computador entende. Bons programadores escrevem código que humanos entendem." MARTIN FOWLER /> } /> [
11. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ Nomes são importantes 1) Evite abreviações, números mágicos e nomes genéricos. Crie constantes. 2) Passe a ideia e objetivo central, use nomes que signifiquema algo 3) Não tenha medo de nomes grandes 4) Isole as palavras de referências de negócio 6) Entenda o idioma que você está codificando • Métodos ou Funções: devem ter nome de verbos (gosto bastante de utilizar do infinitivo), para assim, expressar quais são suas finalidades; • Classes e Objetos: deve ser utilizado substantivos. • Se PT-BR, evite usar plural quando listas, prefira o sufixo "x"lista, usar apenas o "s" é pouco visível e pode gerar confusões 5) Funções e variáveis que retornam bollean, utilizar perguntas como nome
12. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ Nomes são importantes
13. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ Nomes são importantes 8) Tente fazer o mesmo junto com seu time ou para algum projeto especifico e documente - Fazer isso para palavras de negócio é extremamente importante current+"x" 7) Tenha prefixos e sufixos chave pessoais para sempre ta na mão e simplesmente repetir em varios casos - PS: Isso vai te economizar mt tempo na hora de pensar dar nomes para algo "x"+Total "x"+Final get+"x" add+"x" "x"+result "x"+container/layout "x"+Field
14. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ + Princípio DRY (Don’t Repeat Yourself) • “Cada parte do conhecimento deve ter uma representação única, não ambígua e definitiva dentro do sistema.” • Procura reduzir a duplicação de código e os problemas oriundos dessa prática • Não se trata apenas de “não vamos repetir essa linha código” • Ligado à outra prática importante, o “Single Source of Truth” • Pense um pouco no que aquilo significa para o sistema, será que ele poderia ser segmentado e compartilhado? • São práticas fundamentais para evitar modificações em vários lugares e side effects não previstos que podem gerar vários fantasminhas no código.
15. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ + funções simples e claras • 2 pontos claros que devemos ter atenção nas funções, aleḿ de claro seu nome, seriam seus argumentos e quantidade de linhas • Utilizar-se de funções puras é uma boa dica para cumprir essas regrinhas, ela não muda qualquer estado na aplicação, simplesmente recebe algo, processa e retorna algo. • Com isso, você consegue definir uma única responsabilidade/papel e determinando e isolando o contexto da função/classe • Tudo isso facilita para encontrar bugs, criar testes, realizar alguma manutenção e adicionar coisas novas. • Nunca substime o simples, na maioria da vezes, ele resolve!! “A primeira regra das funções é que tem de ser pequenas. A segunda regra das funções é que elas têm de ser ainda menores.” Robert C. Martin
16. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ + Código comentado é bom? • Eu, particularmente, sou defensor de um código não comentado, ou com o mínimo de comentários possível • Nada garante que em uma nova modificação que outro desenvolvedor fez no método/classe o comentário foi atualizado, forçando o desenvolvedor a se preocupar além a implementação mas também com o comentário, perdendo tempo e produtividade. • Procure deixar o seu código mais explícito e legível invés de ter adicionar comentário como primeira opcão. • Lembre-se, testes também são uma forma de documentar e podem deixar um código muito mais explícito de que com comentários, além de forçar sua manutenção em caso de modificação e aumentar a garantia do mesmo. • Então, ta complexo? comente, comente muito, mas é importante ter em mente que essa não é sua única opção e nem precisa ser a primeira.
17. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ + Regra do Escoteiro: "Deixe o código mais limpo do que você encontrou" • Independente de quem seja o “pai da criança”, procurar aproveitar que você está mexendo em um contexto e melhora-lo é uma iniciativa bem vista. • MAS… Faça isso com segurança e sabendo o que faz!!
18. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ + Refatorar o código deve ser um hábito, mas calma… • Pensamentos como “isso é perder tempo valioso” ou “se está funcionando melhor não mexer” são prejudiciais a longo prazo. • A prática da refatoração é uma das melhores formas de se tornar um codificador melhor, ganhar mais agilidade, familiaridade com outros padrões, linguagens e entender o código de outras pessoas • Para realizá-las, é preciso ter alguma garantia de que essas mudanças não irão quebrar o sistema. Uma forma de ter essa garantia é através de testes • Deixe o seu mundo um pouco melhor do que quando você o encontrou, criar alguns testes e assegure sua melhoria contínua.
19. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 Como reduzir a quantidade de IFs de um código </> } /> [
20. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ + Dica simples e mais prática Literal Objects
21. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ +Elevação de Contexto/Escopo • Sua função cresceu demais? -> Que tal criar uma classe ? • Sua classe cresceu demais? -> Que tal criar um novo módulo com várias classes com responsabilidades mais definidas? • Seu módulo cresceu demias e vai ser usado por vários sistemas ? -> Que tal criar uma biblioteca e deixar open-source? • Crescer é uma certeza!!! Faça isso de maneira saúdavel e escalável. Não apenas adicione código, estruture ele !!
22. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ + Sempre lembre-se da velha e boa orientação a objeto
23. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 Elevando o nível </> } /> [
24. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ Princípios S.O.L.I.D S - Single Responsibility Principle Baixo acoplamento e alta coesão O - Open/Closed Principle L - Liskov Substitution Principle I - Interface Segregation Principle D - Dependency Inversion Principle
25. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ + Design Patterns CRIACIONAIS ESTRUTURAIS COMPORTAMENTAIS Abstract Factory Builder Factory Method Object Pool Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of responsibility Command Interpreter Strategy Observer State Memento Template method
26. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 • OVERENGINEERING E EVOLUÇÃO PRECOCE • Entenda o contexto que você está e negocie o que realmente é necessario • O melhor código é aquele que FUNCIONA e entrega VALOR pro cliente ◦ Saiba negociar entregas! </ CUIDADO!
27. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 "Um código limpo deve ser eficiente, simples, direto ao ponto, ter mínimas dependências, não tem duplicações, é fácil de corrigir, precisa ter padrões definidos, tem fácil leitura e entendimento, é elegante e coberto de testes." </ RESUMO
28. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 "Tenha orgulho do seu código!" /> } /> [ “Um código limpo sempre parece que foi escrito por alguém que se importava” – Michael Feather
29. 1 0 1 1 0 1 1 0 1 1 0 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 1 </ } /> [ @denisvieira05 Perguntas? denisvieira05@gmail.com t.me/denisvieira05 denisvieira05.substack.com bento.me/denisvieira05 Obrigado!