O Desenvolvedor Back-end e o Dragão Verde
Era só corrigir aquele sinal invertido, rodar os testes e tudo estaria resolvido, mas não, pois pela décima quarta vez, o teste falhava e eu já estava ficando sem ideias. Apesar de tudo, em situações como esta, o teste unitário é um grande aliado.
Lembro-me do dia em que precisei corrigir um bug em produção. Após várias tentativas sem sucesso, descobri que o problema não era o que eu imaginava. Desde então, nunca alterei o código sem antes ter um teste automatizado.
Geralmente minha atividade era encontrar e corrigir um pequeno problema, quase sempre em um código feito por outra pessoa. Outras vezes eu tinha que escrever meu próprio código, com requisitos não tão claros. Porém, sempre tive certeza de que era isso o que mais gostava de fazer: scripts, automatizações, bibliotecas, banco de dados, integrações entre APIs, etc.
Só que nem sempre foi assim. Já tinha tentado fazer de tudo, inclusive front-end. Era nocauteado, frequentemente, por formulários desalinhados ou erros indecifráveis no console do navegador.
Dessa vez, a tarefa era simples: escrever uma API REST que lesse um arquivo, decodificasse e gravasse o resultado na nuvem. Durante a reunião de planejamento, estimamos que três horas seriam suficientes e ainda sobraria tempo para um cafezinho.
Já tinha lido toda a documentação da biblioteca e nada estava escrito sobre o erro que quebrava o meu teste. Já tinha passado da hora de pedir ajuda, não que isso representasse um fracasso, pois ninguém sabe tudo. Mas a gente sempre quer tentar matar o dragão sozinho. Nessas horas que recorríamos ao Google, pois certamente, alguém em algum lugar, já teve o mesmo problema e poderia indicar qual seria a melhor arma para acabar com aquele monstro.
Infelizmente, buscar ajuda na internet tinha disso: aquele mesmo dragão já tinha sido morto por uma espada cravejada de rubis. Bastava pegar e matar a fera, pois eram idênticas. Viviam na montanha, tinham escamas verdes, olhos vermelhos e soltavam fogo pelas ventas. Porém, a espada só era eficaz contra dragões de até 300 anos e o meu tinha 453. Aquela arma não serviria.
Na daily, eu expliquei o problema aos meus colegas e, como sempre, todos ofereceram ajuda. Uma perspectiva externa é sempre valiosa, pois nossa imaginação pode ficar limitada pelo nosso conhecimento. Todo desenvolvedor sabe que a criatividade é uma chave importante para resolver qualquer obstáculo. E ser criativo não é uma dádiva, é uma habilidade que se adquire com a experiência.
Várias sugestões e novas tentativas, mas acho que eu estava sem sorte, pois nenhuma das sugestões resolvia definitivamente o problema. No entanto, daquela vez, a mensagem de erro era outra. Enfim, eu estava progredindo.
Desenvolvedores sempre têm outra estratégia infalível: esticar as pernas e tomar um café. Na verdade, a bebida não é tão importante, o que funcionava mesmo era deixar o inconsciente trabalhar. Quem nunca teve grandes ideias enquanto tomava banho, lavava a louça ou almoçava?
Isso pode ter uma explicação: segundo a teoria dos múltiplos rascunhos proposta por Dennett em “Consciousness Explained” (1991), o nosso pensamento é produzido por vários processos paralelos subconscientes com uma memória compartilhada (a nossa memória). Cada um deles é como se fosse uma cópia de você mesmo, criando rascunhos de pensamentos, mas apenas alguns chegam na versão final e se tornam conscientes.
Acredito que, ao realizarmos atividades automáticas como tomar banho ou tomar café, diminuímos o nível de atenção, permitindo que a consciência “ouça” esses vários pensamentos mais facilmente.
Eureka! Entre um gole de café e outro, tive a revelação de que talvez o problema não estivesse na minha função, mas sim em questões de concorrência. O código agora fluía na minha mente, como se meu cérebro fosse um processador simulando a própria matrix. Rapidamente sentei na cadeira, digitei a solução e o problema foi resolvido como mágica. Levantei os braços, bati palmas para mim mesmo, gritei como se estivesse comemorando um gol. Mas era mais que isso, sentia como se tivesse descoberto o sentido da vida, o universo e tudo mais.
Todos os testes foram bem-sucedidos, mas ainda havia aquela sensação de que a solução não era ideal. Algo no código cheirava mal e estava difícil de entender. Quem é desenvolvedor sabe do que estou falando. Muitas condições, poucas funções e nenhum padrão. Eu precisava refatorar aquele código Frankenstein… mas isso ficará para outro dia.
Esta história é uma pequena ficção baseada no dia a dia de um desenvolvedor back-end. Espero que ela tenha lhe feito sentir-se como um, caso você ainda não seja.
