El otro día entrevisté a un desarrollador de JavaScript que solicitaba un puesto senior. Un colega, que también estuvo presente en la entrevista, le pidió al candidato que escribiera una función que realizara una solicitud HTTP y, si no tenía éxito, lo volviera a intentar varias veces.
Escribió el código directamente en la pizarra, por lo que sería suficiente para dibujar algo aproximado. Si simplemente hubiera demostrado que entendía bien de qué se trataba, nos habríamos quedado bastante satisfechos. Pero, lamentablemente, no pudo encontrar una solución exitosa. Luego, atribuyéndolo al entusiasmo, decidimos facilitar un poco la tarea y le pedimos que convirtiera una función con devoluciones de llamadas en una función basada en promesas.
Pero Ay. Sí, era obvio que había encontrado ese código antes. Sabía en términos generales cómo funcionaba todo allí. Todo lo que necesitamos es un bosquejo de una solución que demuestre una comprensión del concepto. Sin embargo, el código que el candidato escribió en la pizarra era una completa tontería. Tenía una idea muy vaga de qué eran las promesas en JavaScript y realmente no podía explicar por qué eran necesarias. Para un joven esto habría sido perdonable, pero ya no era apto para el puesto de mayor. ¿Cómo podría este desarrollador corregir errores en una compleja cadena de promesas y explicar a otros qué hizo exactamente?
Los desarrolladores consideran que el código ya preparado es evidente
Durante el proceso de desarrollo, nos encontramos constantemente con materiales reproducibles. Transferimos fragmentos de código para no tener que reescribirlos cada vez. En consecuencia, al centrar toda nuestra atención en las partes clave, consideramos el código terminado con el que trabajamos como algo evidente; simplemente asumimos que todo funcionará como debería.
Y normalmente funciona, pero cuando las cosas se ponen complicadas, comprender la mecánica vale la pena.
Por lo tanto, nuestro candidato para el puesto de desarrollador senior consideraba que los objetos prometedores eran evidentes. Probablemente tenía una idea de cómo lidiar con ellos cuando ocurren en algún lugar del código de otra persona, pero no entendió el principio general y no pudo repetirlo él mismo durante la entrevista. Quizás recordó el fragmento de memoria; no es tan difícil:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Yo también lo hice y probablemente todos lo hemos hecho en algún momento. Simplemente memorizaron un fragmento de código para luego poder utilizarlo en su trabajo, teniendo solo una idea general de cómo funcionaba todo allí. Pero si el desarrollador realmente entendiera el concepto, no tendría que recordar nada: simplemente sabría cómo hacerlo y reproduciría fácilmente todo lo que necesitara en el código.
Volver a las raíces
En 2012, cuando aún no se había establecido el dominio de los marcos front-end, jQuery dominaba el mundo y leí el libro. , escrito por John Resig, creador de jQuery.
El libro enseña al lector cómo crear su propio jQuery desde cero y proporciona una visión única del proceso de pensamiento que llevó a la creación de la biblioteca. En los últimos años, jQuery ha perdido su antigua popularidad, pero sigo recomendando el libro. Lo que más me llamó la atención de ella fue la sensación persistente de que yo mismo podría haber pensado en todo esto. Los pasos que describió el autor parecían tan lógicos, tan claros, que comencé a pensar seriamente que podría crear jQuery fácilmente si me pusiera manos a la obra.
Por supuesto, en realidad no habría podido hacer algo así; habría decidido que era insoportablemente difícil. Mis propias soluciones me parecerían demasiado simples e ingenuas para funcionar y me daría por vencido. Yo clasificaría jQuery como cosas evidentes, en cuyo funcionamiento correcto solo hay que creer ciegamente. Posteriormente, apenas perdería tiempo profundizando en la mecánica de esta biblioteca, sino que simplemente la utilizaría como una especie de caja negra.
Pero leer este libro me convirtió en una persona diferente. Comencé a leer el código fuente y descubrí que la implementación de muchas soluciones era, de hecho, muy transparente, incluso obvia. No, por supuesto, pensar en algo como esto por tu cuenta es una historia diferente. Pero estudiar el código de otras personas y reproducir las soluciones existentes es lo que nos ayuda a encontrar algo propio.
La inspiración que obtenga y los patrones que comience a notar lo cambiarán como desarrollador. Descubrirás que esa maravillosa biblioteca que utilizas constantemente y que estás acostumbrado a considerar como un artefacto mágico no funciona en absoluto con la magia, sino que simplemente resuelve un problema de forma lacónica e ingeniosa.
A veces tendrás que estudiar minuciosamente el código, analizándolo paso a paso, pero así es como, avanzando en pasos pequeños y consistentes, puedes repetir el camino del autor hacia la solución. Esto le permitirá profundizar en el proceso de codificación y le dará más confianza para encontrar sus propias soluciones.
Cuando comencé a trabajar con promesas, me pareció pura magia. Luego descubrí que se basaban en las mismas devoluciones de llamada y mi mundo de programación se puso patas arriba. Entonces, ¿el patrón, cuyo propósito es salvarnos de las devoluciones de llamada, se implementa mediante devoluciones de llamada?
Esto me ayudó a mirar el asunto con otros ojos y darme cuenta de que no se trata de un código abstruso frente a mí, cuya complejidad prohibitiva nunca comprenderé en mi vida. Estos son sólo patrones que pueden entenderse sin problemas con la debida curiosidad y una profunda inmersión. Así es como las personas aprenden a codificar y crecer como desarrolladores.
Reinventar esta rueda
Así que adelante y reinvente las ruedas: escriba su propio código de enlace de datos, cree una promesa local o incluso cree su propia solución de gestión estatal.
No importa que nadie vaya a usar todo esto, pero ahora sabes cómo hacerlo. Y si tienes la oportunidad de utilizar posteriormente dichos desarrollos en tus propios proyectos, en general es genial. Podrás desarrollarlos y aprender algo más.
El punto aquí no es enviar su código a producción, sino aprender algo nuevo. Escribir su propia implementación de una solución existente es una excelente manera de aprender de los mejores programadores y así perfeccionar sus habilidades.
Fuente: habr.com