Não Caia na Armadilha de Julgar o Código dos Outros

Imagine uma situação em que alguém novo entra numa empresa e, nas primeiras semanas, começa a criticar o código com os colegas ou até em público. Já vi isso inúmeras vezes, e o que posso dizer é que quase todo mundo (incluindo você e eu) provavelmente já fez isso em algum momento.

Isso não é exclusivo de empresas de produto, mas também vale para devs que trabalham em consultorias. Já vi vários consultores, na minha experiência anterior como um deles, fazendo o mesmo com o código do cliente.

Isso é completamente normal, e você não precisa ter vergonha disso, mas devemos trocar uma mentalidade de crítica por uma de curiosidade: "Por que isso foi feito assim?"

Criticar o código de outra pessoa não só passa a impressão de que você é ingênuo, como também pode baixar o moral do time e atrapalhar o crescimento individual.

O Que Faz um Código Ser Bom?

Se a primeira coisa que vem à sua cabeça é bons nomes, boa separação de domínios/responsabilidades, código fácil de ler e por aí vai... você não está errado, e sim, esses itens podem indicar um bom código, mas são abstratos. Código bom pode significar coisas diferentes para pessoas diferentes, mas existem alguns indicadores que observei nas últimas empresas em que trabalhei:

• Presença de guias de estilo fortes: As empresas costumam impor guias de estilo para manter uma base de código mais coesa.
• Presença de uma arquitetura forte: Não existe arquitetura perfeita, mas sempre uma em evolução. Uma coisa que vi várias vezes são empresas em que a arquitetura está sempre melhorando com base no feedback dos devs e no crescimento da empresa/produto.
• Presença forte de testes: Isso não é opcional. Os testes guiam o design do nosso código, embora eu já tenha visto empresas com uma cobertura de código enorme, mas com um código muito difícil de ler. Isso não é a regra; pelo contrário, já vi várias empresas com uma cultura forte de testes e o resultado foi um design de código robusto.

A chave para um bom código, na minha opinião, é a simplicidade. Até os algoritmos mais complexos às vezes podem ser quebrados em várias partes pequenas e simples.

Existem também alguns outros indicadores abstratos de um bom código:

• Eficiência
• Legibilidade
• Fácil de entender
• Fácil de manter e de estender

Por Que Criticamos

Isso não é científico, mas tenho algumas suposições sobre isso. À medida que ganhamos experiência e ficamos mais seniores, começamos a ver alguns padrões que se repetem entre empresas e, por causa da nossa experiência, às vezes só olhamos para um código e dizemos: "Ah, droga, esse código é tão difícil de entender que, se eu mudar qualquer coisa aqui, nem sei o que pode acontecer."

Às vezes não é a nossa experiência, mas o nosso viés de empresas anteriores. Quando trabalhamos muito tempo numa empresa com um guia de estilo definido e nos acostumamos com ele, mudar para outra pode nos deixar críticos, porque estávamos acostumados com um jeito antigo de programar.

Também temos a tendência de comparar as coisas e, às vezes, comparamos o jeito de outra pessoa fazer as coisas com o nosso, sendo que não existe jeito certo de fazer algumas coisas. Por exemplo, dar nome a variáveis é difícil, e se você colocar 10 devs numa sala para discutir um nome, quase todos vão chegar com abordagens diferentes.

Vamos Mudar Essa Mentalidade

Então, em vez de só criticar o código, pergunte a si mesmo:

Por que isso foi feito assim?

E aqui vão alguns fatores:

• Falta de conhecimento do domínio: Até os devs mais experientes caem nessa, e isso é mais comum no mundo das startups, onde estão testando várias coisas para encontrar seu lugar no mercado. Os devs tendem a seguir essa linha, construindo software com o conhecimento que tinham no momento. Como as startups estão sempre evoluindo, é difícil justificar uma refatoração enorme.
• Pressão para entregar: Já vi muito isso. Existe um prazo apertado para entregar um projeto, e algo precisa ser cortado; às vezes é mais fácil justificar uma dívida técnica que pode ser paga no futuro do que atrasar o projeto.
• Falta de experiência: Isso também é comum. A tecnologia evolui muito e, se olharmos o código que escrevemos cinco anos atrás, você provavelmente vai dizer: "Não acredito que escrevi esse código." A tecnologia evolui, e o jeito de escrever software também.

Então, da próxima vez que você se pegar querendo criticar o código de outra pessoa, tenha empatia e tente entender por que ele foi escrito daquele jeito e, com isso, pergunte de um jeito mais gentil e sincero e proponha formas de melhorar.

Você sempre pode aprender e fazer novos amigos no caminho.

Bom código ;)