O outro día estaba entrevistando a un programador de JavaScript que solicitaba un posto de alto nivel. Un compañeiro, que tamén estivo presente na entrevista, pediulle ao candidato que escribise unha función que fixese unha solicitude HTTP e, en caso de falla, reintentase varias veces.
Escribiu o código directamente no encerado, polo que bastaría con representar algo aproximado. Se simplemente demostrase que entendía ben cal era a esencia do asunto, quedariamos bastante satisfeitos. Pero, por desgraza, non puido atopar unha boa solución. Entón nós, escribindo como emoción, decidimos facer a tarefa un pouco máis fácil e pedímoslle que fixera unha función construída sobre promesas dunha función con devolucións de chamada.
Pero ai. Si, era obvio que xa vira un código semellante antes. Sabía en termos xerais como funcionaba todo alí. Un esbozo da solución sería suficiente para nós, o que demostraría unha comprensión do concepto. Non obstante, o código que escribiu o candidato no encerado foi un completo disparate. Tiña unha idea moi vaga do que hai promesas en JavaScript e non podía explicar realmente por que son necesarias. Para un júnior, isto aínda sería perdonable, pero xa non se sorteaba o posto de senior. Como conseguiría este desenvolvedor solucionar os erros da complexa cadea de promesas e explicar ao resto o que fixo exactamente?
Os desenvolvedores consideran que o código acabado é evidente
Durante o proceso de desenvolvemento, atopamos constantemente materiais reproducibles. Movemos fragmentos de código para non ter que reescribilos cada vez. En consecuencia, ao centrar toda a nosa atención nas partes clave, miramos o código acabado co que traballamos como algo evidente: simplemente asumimos que todo o que nel funcionará como debería.
E normalmente funciona, pero cando as cousas se complican, comprender a súa mecánica paga máis que recompensa.
Por exemplo, o noso candidato a programador sénior considerou que as promesas eran evidentes. Probablemente imaxinaba como tratar con eles cando ocorren nalgún lugar do código doutra persoa, pero non entendía o principio xeral e non puido repetilo el mesmo na entrevista. Quizais memorizou o fragmento - non é tan difícil:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Eu tamén o fixen, si, probablemente todos o fixemos nalgún momento. Simplemente memorizaron un anaco de código para posteriormente utilizalo no seu traballo, mentres só en termos xerais imaxinaban como funciona todo alí. Pero se o desenvolvedor entendese realmente o concepto, non tería que lembrar nada, só sabería como se fai e reproduciría facilmente todo o necesario no código.
Chegar ás orixes
En 2012, antes do dominio dos frameworks front-end, o mundo de jQuery regras, e eu estaba lendo un libro por John Resig, creador de jQuery.
O libro ensina ao lector a crear o seu propio jQuery desde cero e ofrece unha oportunidade única de involucrarse no tren de pensamento que levou á creación da biblioteca. jQuery caeu en desgracia nos últimos anos, pero aínda recomendo o libro. O que máis me chamou a atención dela foi a súa insistente sensación de que eu puidese pensar en todo isto. Os pasos que describiu o autor parecían tan lóxicos, tan claros que realmente empezou a parecerme que podía crear facilmente jQuery se me puxese no negocio.
Por suposto, en realidade, eu non tería dominado nada como isto - tería decidido que era insoportablemente difícil. As miñas propias solucións pareceronme demasiado sinxelas e inxenuas para funcionar, e teríame rendido. Eu clasificaría jQuery como algo evidente, no correcto funcionamento do que só hai que crer cegamente. Posteriormente, case non dedicaría tempo a afondar na mecánica desta biblioteca, senón que simplemente a empregaría como unha especie de caixa negra.
Pero a lectura deste libro fíxome unha persoa diferente. Comecei a ler o código fonte e descubrín que a implementación de moitas solucións é en realidade moi transparente, incluso obvia. Non, claro, pensar en algo así xa é doutra ópera. Pero é o estudo do código doutro e a reprodución de solucións existentes o que nos axuda a crear algo propio.
A inspiración que obteñas e os patróns que comezas a notar cambiarán como programador. Descubrirás que a marabillosa biblioteca que usas todo o tempo e na que pensas como un artefacto máxico non funciona en absoluto na maxia, senón que simplemente resolve o problema de forma concisa e con recursos.
Ás veces hai que escudriñar o código, desmontándoo paso a paso, pero así é como, avanzando en pequenos pasos sucesivos, pode repetir o camiño do autor cara á solución. Isto permitirache afondar no proceso de escritura de código e darche máis confianza para atopar as túas propias solucións.
Cando comecei a traballar con promesas, pensei que era pura maxia. Entón descubrín que estaban baseados nas mesmas devolucións de chamada, e o meu mundo da programación volveuse patas arriba. É dicir, o patrón, cuxo propósito é salvarnos das devolucións de chamada, implícase por si mesmo mediante devolucións de chamada?!
Isto axudoume a mirar o asunto con outros ollos e a darme conta de que diante de min non hai uns anacos abstrusos de código, complexidade transcendental que nunca comprenderei na miña vida. Estes son só patróns que se poden entender facilmente coa debida curiosidade e unha profunda inmersión. Así é como a xente aprende a codificar e crece como desenvolvedores.
Reinventa esta roda
Así que non dubides en reinventar a roda: escribe o teu propio código para a vinculación de datos, crea unha promesa propia ou mesmo fai a túa propia solución de xestión estatal.
Non importa que ninguén use nunca todo isto, pero agora xa sabes como. E se tes a oportunidade de usar posteriormente tales desenvolvementos nos teus propios proxectos, entón isto é xenial. Podes desenvolvelos e aprender algo máis.
O punto aquí non é enviar o teu código á produción, senón aprender algo novo. Escribir a túa propia implementación dunha solución existente é unha boa forma de aprender dos mellores programadores e mellorar as túas habilidades.
Fonte: www.habr.com