Outro dia, entrevistei um desenvolvedor JavaScript que afirmava ser um veterano. Um colega que também estava presente na entrevista pediu ao candidato que escrevesse uma função que produzisse uma solicitação HTTP e, em caso de falha, tente novamente várias vezes.
Ele escreveu o código imediatamente no quadro, portanto seria suficiente representar algo aproximado. Se ele simplesmente mostrasse que entendia bem qual era a essência da questão, ficaríamos completamente satisfeitos. Infelizmente, ele não conseguiu encontrar uma solução bem-sucedida. Então, anotando isso como excitação, decidimos facilitar um pouco a tarefa e pedimos que ele fizesse uma função com base nas promessas de uma função com retornos de chamada.
Mas infelizmente. Sim, era óbvio que ele já havia encontrado um código semelhante antes. Em geral, ele sabia como tudo funcionava lá. Um esboço de uma solução que demonstraria uma compreensão do conceito seria suficiente. No entanto, o código que o candidato escreveu no quadro era completamente sem sentido. Ele tinha uma ideia extremamente vaga do que eram as promessas de JavaScript e não sabia realmente explicar por que elas eram necessárias. Para o júnior, isso teria sido desculpável, mas a posição do mais velho não era mais estabelecida. Como esse desenvolvedor conseguiria eliminar bugs em uma cadeia complexa com promessas e explicar aos outros o que exatamente ele fez?
Os desenvolvedores consideram o código pronto óbvio
No processo de desenvolvimento, encontramos constantemente materiais reproduzíveis. Transferimos fragmentos de código para que não seja necessário registrá-los sempre. Consequentemente, concentrando toda a nossa atenção nas partes principais, vemos o código final com o qual trabalhamos como algo auto-evidente - apenas assumimos que tudo funcionará como deveria.
E geralmente funciona realmente, mas quando surgem dificuldades, o entendimento de sua mecânica mais do que compensa.
Portanto, nosso candidato à posição de desenvolvedor sênior considerou objetos de promessa evidentes. Ele provavelmente imaginou como lidar com eles quando eles se encontram em algum lugar no código de outra pessoa, mas ele não entendeu o princípio geral e não pôde repeti-lo na entrevista. Talvez ele tenha se lembrado do fragmento de cor - não é tão difícil:
return new Promise((resolve, reject) => { functionWithCallback((err, result) => { return err ? reject(err) : resolve(result); }); });
Eu também fiz - sim, todos nós, provavelmente, algum dia fizemos. Eles simplesmente memorizaram um pedaço de código, para que mais tarde pudessem usá-lo em seu trabalho, enquanto apenas em termos gerais imaginariam como tudo funcionaria lá. Mas se o desenvolvedor realmente entendesse o conceito, ele não precisaria memorizar nada - ele saberia como fazê-lo e reproduziria facilmente tudo o que é necessário no código.
Chegue às raízes
Em 2012, quando o domínio das estruturas front-end ainda não havia sido estabelecido, o jQuery governa o mundo e eu li o livro
Segredos do JavaScript Ninja , de autoria de John Rezig, criador do jQuery.
O livro ensina o leitor a criar seu próprio jQuery a partir do zero e oferece uma oportunidade única de participar da linha de pensamento que levou à criação da biblioteca. Nos últimos anos, o jQuery perdeu sua popularidade anterior, mas eu ainda recomendo o livro. O que mais me impressionou nela foi o sentimento persistente de que eu mesma conseguia pensar em tudo isso. As etapas que o autor pintou pareciam tão lógicas, tão compreensíveis que me pareciam seriamente que eu poderia criar facilmente o jQuery, se eu fosse direto ao assunto.
É claro que, na realidade, eu não teria dominado nada assim - teria decidido que era extremamente difícil. Minhas próprias decisões me pareceriam muito simples e ingênuas para trabalhar, e eu desistiria. Eu atribuiria o jQuery a coisas evidentes, cuja operação correta você precisa acreditar cegamente. Posteriormente, eu dificilmente teria perdido tempo investigando a mecânica desta biblioteca, mas simplesmente a teria usado como uma espécie de caixa preta.
Mas conhecer este livro me fez uma pessoa diferente. Comecei a ler o código fonte e descobri que a implementação de muitas soluções é realmente muito transparente, até óbvia. Não, é claro, pensar em algo assim - isso é de outra ópera. Mas é o estudo do código de outra pessoa e a reprodução das soluções existentes que nos ajudam a criar algo próprio.
A inspiração que você desenha e os padrões que você começa a perceber o mudarão como desenvolvedor. Você descobrirá que a bela biblioteca que você usa constantemente e que está acostumada a considerar como um artefato mágico não funciona com mágica, mas simplesmente resolve o problema de maneira sucinta e engenhosa.
Às vezes, será necessário aprofundar o código, desmontando-o passo a passo, mas, assim, movendo-se em pequenas etapas consecutivas, você pode repetir o caminho do autor para a solução. Isso permitirá que você mergulhe mais fundo no processo de escrever código e dê mais confiança ao procurar suas próprias soluções.
Quando comecei a trabalhar com promessas, parecia-me que isso era pura magia. Então eu descobri que eles eram baseados nos mesmos retornos de chamada e meu mundo da programação virou de cabeça para baixo. Ou seja, um padrão cujo objetivo é nos salvar de retornos de chamada é ele próprio implementado usando retornos de chamada ?!
Isso me ajudou a olhar para o assunto com olhos diferentes e perceber que não há alguns trechos de código obscuros diante de mim, a complexidade transcendental que nunca consigo compreender em minha vida. Estes são apenas padrões que podem ser facilmente entendidos com a devida curiosidade e imersão profunda. É assim que as pessoas aprendem a programar e crescer como desenvolvedores.
Reinvente esta roda
Portanto, fique à vontade para reinventar as rodas: escreva o código para vinculação de dados, crie uma promessa caseira ou até mesmo tome uma decisão de gerenciar suas condições com as próprias mãos.
Não importa que ninguém nunca use tudo isso - mas agora você pode fazê-lo. E se você tiver a oportunidade de usar esses desenvolvimentos posteriormente em seus próprios projetos, isso geralmente é ótimo. Você pode desenvolvê-los e aprender outra coisa.
O ponto aqui não é enviar seu código para produção, mas aprender algo novo. Prescrever a implementação de uma solução existente por conta própria é uma ótima maneira de aprender com os melhores programadores e, assim, aprimorar suas habilidades.