[Desenvolvimento] Criando seu próprio estilo de código

Na rotina do trabalho é muito comum se deparar com o código dos outros, seja no projeto, em code reviews ou testes em processos seletivos e é aí que ter seu próprio estilo de código é tão importante, além do mais o "fit" não tem que acontecer apenas com a "empresa", mas também com a equipe de desenvolvimento.

Já falei, mas vou repetir, tem muita vaga em desenvolvimento, mas pode ter certeza que tem bem mais candidatos. O grande problema de longe é o fator técnico (muitas vezes as empresas até desistem e pegam o "melhorzinho", pois a vaga está aberta há muito tempo) e ter seu próprio estilo de codar diz muito sobre suas habilidades e proficiência em uma tecnologia.

Mas afinal, o que é "ter um estilo de código"? Não estou falando de style guides (entra também), estou me referindo ao jeito de codar em si. Por exemplo, para iterar um array em Javascript, podemos usar: 

- while

- for

- for in

- for of

- forEach

- e outros métodos que fazem outras coisas além de iterar mas a galera usa só pra isso (vixe…)

Enfim, tem várias maneiras de fazer a mesma coisa. Claro que existem diferenças na performance, julgando a lista acima, mas é uma coisa tão insignificante que você pode ignorar com sucesso para um código mais legível.

Historinha: Uma vez estava eu realizando um processo para encontrar um dev backend Node, como era uma vaga simples fiz um testezinho (para a galera enviar junto com LinkedIn e Github). Bastava consumir uma API e fazer umas regrinhas simples, com o objetivo de ver como a galera raciocinava. Sem brincadeira, chegaram centenas de testes idênticos, eu meio que desacreditei, como isso é possível?

Acabei por chamar uma galera que pelo menos a parte de "lógica" fez mais bonitinha do restante. E conversando com eles, novamente, as mesmas respostas. E nos assuntos um pouco mais difíceis, sempre eram chutes ou não sabiam… A resposta desse fenômeno é que todos tinham feito o mesmo bootcamp famosinho de nodejs e por isso todo código era igual. Ninguém em nenhum momento se aprofundou em algo que aprendeu, questionou se tais informações eram válidas ou se quer viu outros caminhos (só para concluir a história, acabou que contratei um cara que não fez esse bootcamp, pois é).

No exemplo acima, eu sei que a vaga era para um nível mais iniciante, então meio que "tudo bem". Também sei que o primeiro passo no processo de aprendizagem é copiar. Mas uma das grandes habilidades da humanidade é o poder de questionar as coisas e, como engenheiro de software, isso de longe é a coisa mais importante que precisamos fazer.

Uma dica é sempre reescrever o que você vê da forma que você julga melhor, por exemplo, se está assistindo um curso onde a pessoa usa um if/else, troque para um ternário ou até elimine o else, siga o que acha melhor (seu estilo). Aquela resposta salvadora do stackoverflow que fez tudo funcionar magicamente, pare, analise, entenda e reescreva. Veja se pode criar abstrações e utilizá-la em outros lugares e escreva à sua maneira, pois um código consistente é essencial. Não só copie e deixe lá. É feio, só de bater o olho, dá para saber que não é seu.

Cada dia que passa, temos mais e mais criadores de conteúdo e profissionais compartilhando conhecimento, por isso não beba apenas de uma fonte, explore outras soluções, aprenda outros caminhos e crie o seu (nada de clubismo, né). Outra coisa que precisa ter em mente é que, às vezes, quem produz um curso, opta por deixar os exemplos extremamente simples para uma melhor compreensão, por exemplo usando uns if/else totalmente desnecessários. A gente segue o curso e faz assim, mas tenha a malícia de pegar esses projetos e refatorá-los e até estendê-los para deixá-los mais completos (aí sim, você pode colocar no seu portfólio e falar que é um projeto seu).

Assim como soluções, pesquise as teorias das coisas. Não é porque eu escrevi um artigo, criei um curso ou até dei aula em uma faculdade que o que falo é verdade (é bizarra a quantidade de informação errada que encontramos por aí, fruto da expansão desses compartilhamentos) por isso sempre dê uma pesquisada mais profunda no quê das coisas. 

Depois de perder um pouquinho o foco do artigo (mas com propriedade), sempre procure seguir as convenções das linguagens, pois cada uma tem a sua e deixa uma clareza na escrita e organização do código, nessa conta temos que adicionar o paradigma que se trabalha e também estilos famosos de programação como pipelines, abstrata, code golf e etc. Claro, não esquecendo dos famosos amiguinhos como SOLID e Object Calisthenics (meio duvidoso algumas coisas aqui). E claro, adapte-se ao seu time, se o time optar por seguir tais convenções, siga, pois consistência é o segredo de um bom código.

Textinho grande hoje, mas a moral é só uma, veja outros caminhos, não se prenda apenas em uma linha de raciocínio, não tenha medo de alterar códigos alheios que venham parar em suas mãos, crie seu estilo e seja consistente, pois só assim seu código vai ficar mais lindo e compreensível. Abraços!