Boas Práticas de Código no Currículo: Clean Code, SOLID e Code Review

Boas práticas de código aparecem na vaga como uma linha de requisito e quase sempre voltam vazias no currículo: clean code, SOLID, code review, padrões de projeto, e nenhuma frase sobre o que foi feito com eles. O recrutador técnico sabe que o termo é amplo. Para o currículo ter peso, cada prática precisa aparecer como uma decisão tomada num projeto, com o que mudou depois. Este texto mostra como escrever essas decisões e separa o significado do termo em programação do significado que ele tem em indústria.

Boas práticas de código são decisões no projeto, não nomes de livros

Escreva cada prática como o trabalho que ela produziu. Clean code, SOLID e padrões de projeto são nomes de conjuntos de decisões, e a entrevista costuma perguntar a decisão, não o nome. Se você não consegue descrever o que mudou no código, a prática ainda não está no seu currículo, por mais que tenha estudado o livro.

Pense em três perguntas para cada linha: o que estava difícil de mudar, o que você fez para facilitar, e o que ficou melhor depois. Se a resposta for só o nome da prática, procure outra parte do trabalho que tenha efeito concreto. Uma função que virou três, um teste que pegou um erro, ou um módulo que passou a aceitar uma nova regra sem alteração no resto servem.

Code review: escreva o que você revisou e o que apontou

Code review é a prática que mais aparece em vagas de desenvolvimento e a que menos aparece com detalhe. Quem revisou código tem o que contar: o tamanho dos pull requests, o tipo de problema que costumava apontar e o que mudou por causa da revisão. Quem só aprovou sem comentar não escreve revisão de código.

Antes: Experiência em code review e boas práticas de desenvolvimento.

Depois: Revisei em média oito pull requests por semana no time de pagamentos, apontando sobretudo ausência de teste em regra de cobrança e dependências circulares entre módulos. Duas dessas revisões evitaram erros em produção.

A segunda versão tem volume, tipo de problema e resultado. A primeira não tem nenhum dos três. Se você revisou em grupo de estudo ou em projeto de código aberto, o mesmo formato vale, com o nome do repositório no lugar do time.

Clean code aparece melhor como refatoração com motivo

Legibilidade não é uma linha de currículo por si só. Ela aparece como refatoração: uma parte do sistema que era difícil de alterar e ficou mais fácil, com um efeito que outra pessoa pode verificar. Nomeie o módulo, o que foi separado e o que isso permitiu.

Antes: Refatoração de código legado seguindo clean code.

Depois: Separei em funções menores o cálculo de desconto do módulo de faturamento, que tinha quase quatrocentas linhas. Com isso, cobri a regra com testes e corrigi um erro de arredondamento que aparecia em notas com parcelamento.

Essa linha funciona para qualquer linguagem e qualquer tamanho de empresa. Se o código não é seu e você só leu, não escreva a refatoração. Escreva a leitura e a dúvida que ela tirou, porque é isso que você fez.

SOLID e padrões de projeto só entram quando houve uma escolha

Princípios como os de SOLID e padrões como fábrica ou estratégia são úteis quando você escolheu um deles para resolver um problema concreto. Se a escolha não foi sua, cite a equipe que escolheu e o que você fez dentro dela. Não escreva o princípio como se tivesse sido sua decisão técnica.

Antes: Aplicação de SOLID e padrões de projeto.

Depois: Isolei a integração com o provedor de pagamento atrás de uma interface própria, o que permitiu trocar de provedor sem alterar a regra de pedido.

A entrevista costuma seguir para o porquê. Quem entendeu a interface sabe responder que ela existe para trocar o provedor sem tocar no pedido, e que ela não resolvia nenhum outro problema que não existisse. Se você conhece o princípio mas não aplicou, o conhecimento vai na formação ou em projeto próprio, com um exemplo que você possa mostrar.

Para as vagas de desenvolvimento, use a linguagem do repositório

Prática de código é uma das áreas em que o currículo mais se beneficia de um caminho público. Um repositório com histórico de commits, testes e revisões escritas dá à linha uma prova que o texto sozinho não dá. Quem tem um projeto assim pode citar o endereço, desde que o repositório esteja público e seja de fato seu. Para montar essa prova, o guia sobre currículo de programador com projetos no GitHub explica como escolher o que mostrar.

O tamanho da experiência muda o tipo de prática que vale citar. Em cargos mais sênior, a linha de arquitetura pede decisões de longo prazo, e o currículo de engenheiro de software sênior trata desse caso. Em cargos de QA, testes automatizados são a prática principal, e o currículo de analista de QA mostra como descrevê-los.

Boas práticas de fabricação não são código: como a vaga de produção usa o termo

Em vagas de indústria, farmácia e alimentos, boas práticas significa Boas Práticas de Fabricação, a BPF. Ela não tem nada a ver com revisão de código. Trata de higiene, controle de processo, registro de lote e rastreabilidade, e é cobrada de quem trabalha na linha ou na qualidade. Confundir os dois é a primeira falha de um currículo de produção que tenta parecer técnico.

Se a vaga é de farmácia, a palavra pode aparecer junto de atendimento ao balcão e de controle de estoque, e o guia de palavras-chave para farmacêutico mostra os termos que essas vagas costumam trazer. Se é de produção, escreva a BPF com a atividade concreta, como registro de lote conferido ou limpeza de área registrada, e não com termo de programação. O exemplo de currículo de assistente de produção mostra a mesma lógica numa linha de chão de fábrica.

Essa separação vale para o currículo inteiro. Não misture os dois sentidos numa mesma frase, e não escreva que você tem boas práticas de fabricação se trabalhou só com código. O recrutador percebe a mistura na primeira leitura, e a entrevista confirma.

Sem equipe de software, a prova vem do que você fez sozinho

Muita gente quer escrever boas práticas de equipe sem ter trabalhado em equipe. A saída honesta é mostrar o que você fez sozinho: um projeto com testes, uma contribuição em código aberto aceita, uma revisão que você escreveu em um grupo de estudo. Cada uma dessas coisas é uma prática real, mesmo que pequena.

Não preencha o que falta. Escrever revisão de código sem nunca ter revisado, ou dizer que aplicou SOLID num projeto que só tem um arquivo, cria uma pergunta que você não consegue responder. Se faltar prática de equipe, a linha mais útil é a que mostra um projeto completo, do início ao fim, com as decisões que você tomou nele.

Escreva boas práticas como decisão com efeito, e deixe o nome por último

Uma prática de código entra no currículo quando você consegue dizer o que mudou por causa dela. Revisão, refatoração, teste e decisão de projeto têm esse efeito quando você descreve o trabalho. O nome do conceito vem no fim, para explicar a escolha, e não no começo, para parecer que você estudou.

Antes de enviar, releia cada linha de prática e pergunte o que aconteceu depois dela. Se a resposta for vazia, a linha não está pronta. Para conferir se as palavras da vaga estão no seu texto como trabalho real, a análise gratuita do AjustaCV compara o currículo com o texto da vaga que você colar, sem cadastro, e mostra quais termos da vaga o seu currículo já tem e quais faltam.

Perguntas frequentes