Recentemente, tive uma entrevista com um desenvolvedor JavaScript que estava concorrendo a uma posição de sênior. Um colega, que também estava presente na entrevista, pediu ao candidato para escrever uma função que realizasse uma requisição HTTP e, em caso de falha, tentasse novamente várias vezes.
Ele estava escrevendo o código diretamente no quadro, então bastava desenhar algo aproximado. Se ele tivesse apenas mostrado que entendia bem o cerne da questão, teríamos ficado bastante satisfeitos. Mas, infelizmente, ele não conseguia encontrar uma solução adequada. Então, atribuindo isso à ansiedade, decidimos facilitar um pouco a tarefa e pedimos que ele transformasse a função com callbacks em uma função baseada em promessas.
Mas, infelizmente. Sim, era evidente que ele já tinha visto esse tipo de código antes. Ele tinha uma ideia geral de como tudo funcionava. Teríamos ficado satisfeitos com um esboço de solução que demonstrasse a compreensão do conceito. No entanto, o código que o candidato escrevia no quadro era um completo nonsense. Ele tinha uma noção bastante nebulosa do que são promessas em JavaScript e não conseguia explicar devidamente para que elas servem. Para um júnior isso seria ainda aceitável, mas para uma posição sênior não era o caso. Como esse desenvolvedor conseguiria corrigir bugs em uma cadeia complexa de promessas e explicar aos outros o que exatamente fez?
Os desenvolvedores consideram o código pronto como autoexplicativo.
Durante o processo de desenvolvimento, deparamos constantemente com trechos de código reutilizáveis. Nós copiamos fragmentos de código para não precisarmos escrevê-los novamente a cada vez. Assim, concentrando toda a atenção nas partes-chave, olhamos para o código pronto como se fosse algo evidente – suponhamos que tudo funcionará como deveria.
E geralmente funciona mesmo, mas quando surgem complicações, entender sua mecânica vale mais do que a pena.
Assim, nosso candidato à vaga de desenvolvedor sênior considerava os objetos promise como autoexplicativos. Ele provavelmente tinha uma ideia de como manipular esses objetos quando estavam em algum código de terceiros, mas não compreendia o princípio geral e não conseguiu replicá-lo na entrevista. Talvez ele tivesse decorado um trecho 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 – provavelmente todos nós fizemos em algum momento. Apenas decorávamos um trecho de código para depois utilizá-lo no trabalho, tendo apenas uma ideia geral de como tudo funcionava. Mas se o desenvolvedor realmente entendesse o conceito, não precisaria decorar nada – ele apenas saberia como isso é feito e reproduziria tudo o que é necessário no código sem esforço.
Volte às origens
Em 2012, quando ainda não havia se estabelecido o domínio dos frameworks de front-end, o mundo era dominado pelo jQuery, e eu li o livro , escrito por John Resig, o criador do jQuery.
O livro ensina o leitor a criar seu próprio jQuery do zero e oferece uma oportunidade única de compreender o raciocínio que levou à criação da biblioteca. Nos últimos anos, o jQuery perdeu popularidade, mas eu ainda recomendo muito o livro. O que mais me impressionou nele foi a persistente sensação de que eu poderia ter chegado a tudo isso sozinho. Os passos que o autor descrevia pareciam tão lógicos, tão claros, que eu realmente comecei a acreditar que eu poderia facilmente criar jQuery se apenas me dedicasse ao assunto.
Obviamente, na realidade, eu não conseguiria nada parecido – acharia que isso é extremamente difícil. Minhas próprias soluções pareceriam simples demais e ingênuas demais para funcionar, e eu desistiria. Eu consideraria o jQuery como algo autoevidente, cuja operação correta exigiria apenas uma crença cega. Posteriormente, provavelmente eu não teria disposto de tempo para me aprofundar na mecânica dessa biblioteca, apenas usaria como uma espécie de caixa-preta.
Mas meu encontro com este livro me transformou em outra pessoa. Comecei a me aprofundar no código-fonte e descobri que a implementação de muitas soluções é, na verdade, muito transparente, até mesmo óbvia. Claro, pensar por conta própria em algo semelhante é outro assunto. Mas é precisamente estudar o código dos outros e reproduzir soluções já existentes que nos ajuda a inventar algo novo.
A inspiração que você obterá e os padrões que começará a notar mudarão você como desenvolvedor. Você descobrirá que aquela maravilhosa biblioteca que você usa constantemente e que costuma pensar como um artefato mágico, na verdade, não é mágica, mas simplesmente resolve um problema de forma concisa e engenhosa.
Às vezes, você terá que trabalhar arduamente no código, analisando-o passo a passo, mas é assim, avançando com pequenos passos consecutivos, que você conseguirá repetir o caminho do autor até a solução. Isso permitirá que você se aprofunde mais no processo de escrita de código e aumente sua confiança ao buscar soluções próprias.
Quando comecei a trabalhar com promessas, parecia que era pura mágica. Depois, descobri que elas se baseiam nas mesmas callbacks, e meu mundo de programador virou de cabeça para baixo. Ou seja, o padrão, cujo objetivo é nos livrar das callbacks, se realiza por meio de callbacks?!
Isso me ajudou a olhar para o assunto de outra forma e perceber que não estava diante de trechos de código abstratos e de uma complexidade que eu nunca conseguiria entender. São apenas padrões que podem ser compreendidos facilmente com a devida curiosidade e imersão. É assim que as pessoas aprendem a programar e crescem como desenvolvedores.
Reinvente a roda
Então, sinta-se à vontade para reinventar rodas: escreva seu próprio código para vinculação de dados, crie uma promessa caseira ou até mesmo faça sua própria solução para gerenciamento de estados.
Não importa que ninguém nunca vá usar isso – a questão é que agora você sabe como fazer. E se você tiver a oportunidade de usar essas criações em seus próprios projetos mais tarde, será ainda melhor. Você poderá desenvolvê-las e aprender ainda mais.
O objetivo aqui não é colocar seu código em produção, mas sim aprender algo novo. Implementar por conta própria uma solução já existente é uma excelente maneira de aprender com os melhores programadores e, assim, aprimorar suas habilidades.
Fonte: habr.com
