Outro dia entrevistei um desenvolvedor JavaScript que estava se candidatando a um cargo sênior. Um colega, que também esteve presente na entrevista, pediu ao candidato que escrevesse uma função que fizesse uma solicitação HTTP e, caso não tivesse sucesso, tentasse novamente várias vezes.
Ele escreveu o código diretamente no quadro, então bastaria desenhar algo aproximado. Se ele tivesse simplesmente demonstrado que entendia bem o que estava acontecendo, teríamos ficado bastante satisfeitos. Mas, infelizmente, ele não conseguiu encontrar uma solução bem-sucedida. Então nós, atribuindo isso à empolgação, decidimos tornar a tarefa um pouco mais fácil e pedimos a ele que transformasse uma função com retornos de chamada em uma função baseada em promessas.
Mas, infelizmente. Sim, era óbvio que ele já havia encontrado esse código antes. Ele sabia em termos gerais como tudo funcionava ali. Tudo o que precisamos é de um esboço de uma solução que demonstre a compreensão do conceito. Porém, o código que o candidato escreveu no quadro era um completo absurdo. Ele tinha uma ideia muito vaga do que eram promessas em JavaScript e não conseguia explicar por que eram necessárias. Para um júnior isso teria sido perdoável, mas ele não era mais adequado para a posição de sênior. Como esse desenvolvedor seria capaz de consertar bugs em uma complexa cadeia de promessas e explicar aos outros o que exatamente ele fez?
Os desenvolvedores consideram o código pronto evidente
Durante o processo de desenvolvimento, encontramos constantemente materiais reproduzíveis. Transferimos fragmentos de código para não precisarmos reescrevê-los todas as vezes. Conseqüentemente, ao concentrar toda a nossa atenção nas partes principais, olhamos para o código finalizado com o qual trabalhamos como algo evidente - simplesmente assumimos que tudo funcionará como deveria.
E geralmente funciona, mas quando as coisas ficam complicadas, entender a mecânica mais do que compensa.
Assim, nosso candidato ao cargo de desenvolvedor sênior considerou os objetos promissores evidentes. Ele provavelmente tinha uma ideia de como lidar com eles quando ocorressem em algum lugar do código de outra pessoa, mas não entendia o princípio geral e não conseguia repeti-lo durante a entrevista. Talvez ele tenha lembrado o 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 isso - e provavelmente todos nós já fizemos isso em algum momento. Eles simplesmente memorizaram um trecho de código para depois utilizá-lo em seu trabalho, tendo apenas uma ideia geral de como tudo funcionava ali. Mas se o desenvolvedor realmente entendesse o conceito, ele não teria que se lembrar de nada - ele simplesmente saberia como fazê-lo e reproduziria facilmente tudo o que precisasse em código.
Volte às raízes
Em 2012, quando o domínio dos frameworks front-end ainda não havia sido estabelecido, o jQuery dominava o mundo, e li o livro , de autoria de John Resig, criador do jQuery.
O livro ensina o leitor a criar seu próprio jQuery do zero e fornece uma visão única do processo de pensamento que levou à criação da biblioteca. Nos últimos anos, o jQuery perdeu sua popularidade anterior, mas ainda recomendo fortemente o livro. O que mais me impressionou nela foi a sensação persistente de que eu mesmo poderia ter pensado em tudo isso. As etapas descritas pelo autor pareciam tão lógicas, tão claras que comecei a pensar seriamente que poderia facilmente criar jQuery se simplesmente fosse direto ao assunto.
É claro que, na realidade, eu não teria sido capaz de fazer algo assim - teria decidido que era insuportavelmente difícil. Minhas próprias soluções pareceriam simples e ingênuas demais para funcionar, e eu desistiria. Eu classificaria o jQuery como coisas evidentes, em cujo funcionamento correto você só precisa acreditar cegamente. Posteriormente, dificilmente perderia tempo investigando a mecânica desta biblioteca, mas simplesmente a utilizaria como uma espécie de caixa preta.
Mas ler este livro me tornou uma pessoa diferente. Comecei a ler o código fonte e descobri que a implementação de muitas soluções era de facto muito transparente, até óbvia. Não, é claro, pensar em algo assim sozinho é uma história diferente. Mas é o estudo do código de outras pessoas e a reprodução das soluções existentes que nos ajuda a criar algo próprio.
A inspiração que você ganha e os padrões que você começa a notar mudarão você como desenvolvedor. Você descobrirá que aquela biblioteca maravilhosa que você usa constantemente e que está acostumado a considerar um artefato mágico não funciona em magia, mas simplesmente resolve um problema de forma lacônica e engenhosa.
Às vezes você terá que se debruçar sobre o código, analisando-o passo a passo, mas é assim que, avançando em passos pequenos e consistentes, você poderá repetir o caminho do autor até a solução. Isso permitirá que você se aprofunde no processo de codificação e lhe dará mais confiança para encontrar suas próprias soluções.
Quando comecei a trabalhar com promessas, parecia-me pura magia. Então descobri que eles eram baseados nos mesmos retornos de chamada e meu mundo de programação virou de cabeça para baixo. Então o padrão, cujo objetivo é nos salvar de retornos de chamada, é implementado usando retornos de chamada?!
Isso me ajudou a olhar o assunto com outros olhos e perceber que não se trata de um código obscuro diante de mim, cuja complexidade proibitiva nunca compreenderei em minha vida. São apenas padrões que podem ser compreendidos sem problemas com a devida curiosidade e imersão profunda. É assim que as pessoas aprendem a codificar e crescem como desenvolvedores.
Reinvente esta roda
Então vá em frente e reinvente as rodas: escreva seu próprio código de vinculação de dados, crie uma promessa interna ou até mesmo crie sua própria solução de gerenciamento de estado.
Não importa que ninguém use tudo isso - mas agora você sabe como fazer. E se você tiver a oportunidade de usar posteriormente esses desenvolvimentos em seus próprios projetos, isso geralmente será ótimo. Você será capaz de desenvolvê-los e aprender outra coisa.
O objetivo aqui não é enviar seu código para produção, mas aprender algo novo. Escrever sua própria implementação de uma solução existente é uma ótima maneira de aprender com os melhores programadores e, assim, aprimorar suas habilidades.
Fonte: habr.com