Código limpo ou sem código! Não existe gambiarra!

O código é uma janela da sua melhor versão como programador, então capricha, jovem padawan.

      Por: Douglas Vasconcelos

Muitas vezes, quando você está desenvolvendo um projeto na empresa em que você trabalha, um projeto pessoal ou aquele trabalho em grupo da faculdade, eventualmente outras pessoas vão acabar mexendo no seu código. Muito provavelmente até mesmo o seu “eu” do futuro vai fazer isso, seja para solucionar algum bug ou usar como referência e descobrir como foi implementada aquela funcionalidade. Por isso o melhor a se fazer é deixar o código bem legível, procurando evitar aqueles erros bobos ou escrever coisas que só você vai entender e que provavelmente nem o seu “eu” do futuro vai se lembrar o que é.

Se você está na faculdade, mas ainda não tem o costume de adotar boas práticas de código, tudo bem! Essa é a melhor hora pra começar a aprender, é aí que se inicia a sua jornada com a “Força”!

Para começo de conversa, projetos pequenos são perfeitos para adquirir boas práticas de código. Mesmo se o projeto não for pequeno, mas você tiver a oportunidade de começar do zero, não deixe essa chance escapar — porque nós sabemos como essa história termina: vira uma verdadeira bola de neve! E ninguém gosta de ter débito técnico e ter que refatorar código, não é verdade?

No caso de você estar iniciando na vida de programação, não se preocupe se você já fez aqueles códigos “gambiarrosos”, cheios de prints e que não são muito bonitos. É normal não se ter essa skill logo de cara, mas é importante você ter em mente que treinar boas práticas será muito importante para os seus códigos futuros.

E claro toda hora é hora para se trocar ideias sobre práticas de código, aprender aqueles macetes, algum atalho novo, pedir uma dica de plugin, experimentar novas ferramentas como aquela IDE que você viu seu amigo usar, tentar usar aquela função que você viu no Stack Overflow que resume o seu código de 10 linhas em apenas 3. O importante é descobrir o que mais te agrada e que te deixa satisfeito para escrever uma boa linha de código.

Assim como existem várias linguagens, também existem diversas formas para se escrever e se estruturar um bom código. Você não precisa dominar todas as técnicas, mas precisa aprender o básico, jovem padawan.

Algumas dessas técnicas são básicas como um “ABC” e não são relacionadas à linguagem que você estiver usando, então pode aplicá-las em qualquer caso.

Ok, mas vamos para o que realmente interessa.

1 —Padronizando declaração de variáveis.

Escolha um padrão para declarar as variáveis do seu projeto e o siga fielmente, se não seu projeto irá se tornar um carnaval de variáveis com formatos diferentes. Existem vários padrões que você pode adotar, algumas comunidades de certas linguagens já utilizam um padrão por ser mais aceito. Você pode adotá-lo ou escolher um que seja mais agradável pra você, contanto que o mantenha como padrão em todo o seu projeto. O recomendável, claro, é seguir com o que já é aceito pela comunidade da linguagem que você escolheu.

Uma dica que eu dou para quem programa em Java, quando for criar uma variável que faça sentido ser formada por duas palavras ou mais, evite utilizar o caractere underline para unir as duas palavras. Uma forma melhor é escrever tudo junto, no formato Lower Camel Case. Por exemplo: scoreRangeperformanceValue. Esse caractere acabou me dando um pouco de dor de cabeça com o Spring Data, ao tentar criar queries automáticas utilizando as variáveis que foram declaradas com underline.

2 — Magic!

Nem você nem a pessoa que vai ler seu código são mágicos (eu acredito).

Então tente não tirar números da cartola e jogá-los no meio do código! Se aquele número está ali, ele tem uma explicação. Crie uma constante e nomeie ela de forma que a pessoa que irá ler o seu código (ou até mesmo você no outro dia) vai entender o porquê de existir aquele valor ali.

3 — Easter Eggs no código

Não crie aquelas variáveis misteriosas, como a famosa “aux”, ou easter eggs e ou outros nomes que você esteja acostumado a utilizar (já me deparei até com alguns engraçados como “tapi” e “oca” ou “tika”). Os nomes das variáveis têm que estar alinhados com o papel que elas terão no código. Se você realmente está querendo criar uma variável auxiliar, crie com um nome que indique que ela é uma variável auxiliar mas para aquela determinada ação.

4 — Git é incrível se você souber a forma correta de usar

Aprender a usar corretamente o Git é muito importante. Além de ser uma ferramenta de versionamento, ele pode te ajudar na organização do seu código. Uma funcionalidade que eu acho muito interessante é o Git Hooks: com ele você pode definir um padrão de mensagem para os seus commits, ou seja, só serão aceitos commits que estiverem dentro do regex estabelecido (isso é muito interessante de se utilizar com outras ferramentas como Trello e Jira, para organizar cada issue).

Com o Git Hooks também é possível configurar a execução de testes unitários e o commit só será aceito caso todos os testes tenham sucesso. Isso evita bastante que aquele erro que passou despercebido suba para o repositório. Na minha opinião, o Git é uma ferramenta rica que te permite fazer diversas coisas, muitas dessas você só aprende integrando ele de verdade com o seu projeto e colocando a mão na massa, então tem que codar.

5 — Você é quem faz a arquitetura

Existem diversas padrões de organização de projeto, normalmente são estruturados em camadas de serviços, em que cada camada fica em uma pasta do projeto e lá ficarão os códigos das features específicas que realizam funções semelhantes. Por exemplo: uma camada que realiza apenas acessos ao banco, o Service. Como trabalho com um projeto web com Spring Boot, uma forma que aprendi a dividir as camadas foi em Controller, onde ficará o controle das rotas da API; Service, onde posso realizar operações com o banco, busca, atualização, inserção; Adapter, onde irei realizar alguma regra de negócio, acessar as propriedades do código ou chamar algum micro-serviço. Outro padrão de estruturação já famoso é o MVC (Model-View-Controller), bastante adotado em projetos web com javascript.

Todos os modelos de arquitetura se baseiam em agrupamento de código por conceito, para otimizar ainda mais a sua vida de programação. Não estou falando que esses padrões que citei logo acima são unanimidade, o ideal é você procurar uma arquitetura que melhor se encaixa ao seu projeto e que vai te ajudar a organizá-lo. Além disso, um projeto organizado é outro nível, então vale muito a pena pesquisar pelo melhor modelo.

6 — README EM CAPS LOCK SIM!

Um ponto fraco da maioria dos programadores é a documentação, sendo que a documentação só está ali para ajudar. Já ouvi muitas vezes que um código bem escrito não precisa de documentação. OK, isso pode até ser verdade em alguns casos, mas, em um projeto grande, nada tira o fato de que muitas vezes é importante aquele comentário para entender aquela função, saber especificamente o que ela recebe e o que vai retornar. Falando sério, documentar não faz mal nenhum — muito pelo contrário, só vai te ajudar! Também, é claro, ajuda o próximo desenvolvedor que for mexer no código, já que ele vai conseguir entender mais rápido o contexto, além de que não vai ficar te perguntando de instante em instante.

A documentação pode ser no próprio README (sério, se esse arquivo está com esse nome, ainda mais em Caps Lock, é porque você TEM QUE LER antes de começar o projeto!). Isso já é bem interessante, mas se tem algum outro arquivo de texto que você queira criar por fora, se lembra de deixar organizado para acabar não confundindo ainda mais a pessoa que vai ler. Existem inclusive algumas ferramentas de documentação automática que são bem interessantes, como o Swagger UI para APIs ou o Asciidoctor.

Existem várias ferramentas que podem te ajudar nessa missão. Escolha a arma que melhor se ajusta à sua necessidade e que a força esteja com você.

O primeiro passo dessa etapa é escolher a sua IDE ideal. Pode ser aquela que tem um tema mais agradável ou a que tem mais funcionalidades interessantes para o seu projeto e, se você for mais simples, pode até ser um editor de texto normal mesmo, contanto que isso te ajude a programar. Mas entenda que uma boa IDE pode impulsionar bastante a sua produtividade.

Como eu estou programando em Java já a algum tempo, comecei pelo Eclipse e confesso que não era muito satisfeito até migrar para o IntelliJ. Foi rápido para me acostumar, até mesmo porque as duas interfaces são bem parecidas, mas me senti mais confortável com o IntelliJ e com os plugins que ele me permite utilizar. Se no futuro aparecer alguma outra IDE mais atraente, vou testar com toda certeza.

Plugins para padronização e correção de código também são ferramentas muito interessantes que facilitam a vida de qualquer um. Então vale a pena perder um pouco de tempo dando uma pesquisada e configurando, porque, depois disso, vão estar à distância de apenas um atalho do seu teclado e seu código vai estar lá todo lindo, formatado com a identação padrão que você programou!!

Uma dica que eu dou é você utilizar duas ferramentas: Lint e o plugin de formatação do Google. Lint é uma ferramenta de verificação automática, que identifica padrões problemáticos no seu código, warnings e erros que podem gerar algum bug. A outra ferramenta é o plugin de formatação do Google, que varia para cada linguagem que você for utilizar, mas que já deixa tudo em um padrão muito legal.

Boas práticas não são adquiridas do dia para a noite, somente com o tempo você pode se tornar um jedi, mestre em clean code e, claro, a prática é amiga da perfeição.

Com o tempo, as boas práticas vão se tornando mais naturais, mas alguns detalhes sempre podem acabar passando despercebidos. Por isso as técnicas e ferramentas sempre irão ajudar desde o iniciante até o mais experiente. Nós sabemos como um código legado malfeito pode ser um terror (ou não… existem, sim, esses casos raros). Então seja o cara legal da vez, faça um código limpo e não crie um monstro para que o próximo desenvolvedor cuide. Não vá para o lado negro da Força.

Bom isso é tudo pessoal, obrigado! Até uma próxima e que a Força esteja com vocês!

Esse conteúdo foi escrito pelo Douglas Vasconcelos, Software Engineer na Neurotech, e originalmente postado no blog da Neurolake.

Compartilhar no facebook
Compartilhar no whatsapp
Compartilhar no linkedin
Compartilhar no telegram
Compartilhar no email

Posts Relacionados

  • RECIFE

+ 55 81 3312-2740

Rua Alfândega, 35 – 4º andar
Shopping Paço Alfândega
Recife – PE- Brasil​
CEP: 50030-030

  • SÃO PAULO

+ 55 11 3076-7900

Rua Joaquim Floriano, 72
12º andar – cj. 121
Itaim Bibi – São Paulo
SP – Brasil
CEP: 04534-000
  • contato@neurotech.com.br
SOLUÇÕES
NEUROTECH
  • RECIFE

+ 55 81 3312-2740

Rua Alfândega, 35 – 4º andar
Shopping Paço Alfândega
Recife – PE- Brasil​
CEP: 50030-030

  • SÃO PAULO

+ 55 11 3076-7900

Rua Joaquim Floriano, 72
12º andar – cj. 121
Itaim Bibi – São Paulo
SP – Brasil
CEP: 04534-000