Recientemente, entrevisté a un desarrollador de JavaScript que aspiraba a un puesto de senior. Un colega que también estaba presente en la entrevista pidió al candidato que escribiera una función que realizaría una solicitud HTTP y, en caso de fallar, intentaría de nuevo varias veces.
Él escribía el código directamente en la pizarra, por lo que bastaría con representar algo aproximado. Si simplemente hubiera demostrado que entiende bien la esencia del asunto, habríamos estado bastante satisfechos. Pero, desafortunadamente, no logró encontrar una solución adecuada. Entonces, atribuyendo esto a los nervios, decidimos facilitar un poco la tarea y le pedimos que transformara la función con callbacks en una función basada en promesas.
Pero, lamentablemente. Sí, era evidente que un código así le había sido familiar antes. Sabía en términos generales cómo funcionaba todo. Nos habría bastado con un esbozo de solución que demostrara comprensión del concepto. Sin embargo, el código que el candidato escribía en la pizarra era una completa tontería. Tenía una idea muy vaga de lo que son las promesas en JavaScript y no pudo explicarlo adecuadamente. Para un junior esto habría sido todavía excusable, pero para un puesto de senior ya no era suficiente. ¿Cómo podría este desarrollador solucionar errores en una compleja cadena de promesas y explicar a los demás qué exactamente había hecho?
Los desarrolladores consideran el código listo como algo obvio.
En el proceso de desarrollo, nos encontramos constantemente con materiales reproducibles. Transferimos fragmentos de código para no tener que escribirlos de nuevo cada vez. Por lo tanto, al concentrar toda nuestra atención en las partes clave, vemos el código final con el que trabajamos como algo evidente: simplemente asumimos que todo funcionará como se espera.
Y, por lo general, realmente funciona, pero cuando surgen dificultades, comprender su mecánica más que compensa.
Así, nuestro candidato para el puesto de desarrollador senior consideraba que los objetos promesa eran evidentes. Probablemente, entendía cómo manejarlos cuando se encontraban en el código de otros, pero no comprendía el principio general y no pudo repetirlo por sí mismo en la entrevista. Tal vez memorizó un 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; probablemente todos nosotros lo hemos hecho alguna vez. Simplemente memorizamos un fragmento de código para luego usarlo en el trabajo, teniendo una idea general de cómo está estructurado. Pero si un desarrollador realmente entendiera el concepto, no necesitaría memorizar nada; simplemente sabría cómo hacerlo y podría reproducir todo lo necesario en el código sin dificultad.
Regresa a los orígenes
En 2012, cuando todavía no dominaban los frameworks de frontend, el mundo estaba gobernado por jQuery, y yo leía un libro , escrito por John Resig, el creador de jQuery.
El libro enseña al lector cómo crear su propia jQuery desde cero y ofrece una oportunidad única para comprender el pensamiento que llevó a la creación de la biblioteca. En los últimos años, jQuery ha perdido su anterior popularidad, pero aún así recomiendo mucho el libro. Lo que más me impresionó fue la persistente sensación de que yo podría haber llegado a estas conclusiones por mi cuenta. Los pasos que describía el autor parecían tan lógicos, tan claros, que realmente empecé a pensar que podría haber creado jQuery sin problemas, si tan solo me hubiera puesto a ello.
Por supuesto, en realidad no habría sido capaz de hacerlo; habría decidido que era demasiado difícil. Mis propias soluciones me habrían parecido demasiado simples y naïve para funcionar, y hubiera levantado las manos en señal de rendición. Habría considerado jQuery como algo obvio, en cuya funcionamiento correcto solo hay que creer ciegamente. Posteriormente, probablemente no habría gastado tiempo intentando entender la mecánica de esta biblioteca, y simplemente la habría utilizado como una especie de caja negra.
Pero el conocer este libro me convirtió en otra persona. Comencé a leer el código fuente y descubrí que la implementación de muchas soluciones es en realidad muy clara, incluso obvia. No, por supuesto, llegar a algo así por mi cuenta es otra historia. Pero precisamente el estudio del código ajeno y la reproducción de soluciones ya existentes nos ayuda a inventar algo propio.
La inspiración que obtendrás y los patrones que comenzarás a notar te transformarán como desarrollador. Descubrirás que esa maravillosa biblioteca que usas constantemente y de la que sueles pensar como un artefacto mágico, en realidad no se basa en magia, sino que simplemente resuelve problemas de manera concisa e ingeniosa.
A veces tendrás que trabajar arduamente en el código, desglosándolo paso a paso, pero así, avanzando con pequeños pasos consecutivos, podrás replicar el camino del autor hacia la solución. Esto te permitirá sumergirte más en el proceso de escritura de código y te dará más confianza al buscar tus propias soluciones.
Cuando empecé a trabajar con promesas, me parecía que era pura magia. Luego descubrí que en su base se encuentran los mismos callbacks, y mi mundo como programador dio un giro. ¿Es decir, el patrón que busca liberarnos de los callbacks se implementa a través de callbacks?
Esto me ayudó a ver el asunto con otros ojos y a comprender que no se trataba de fragmentos de código extraños con una complejidad que nunca podría entender. Son solo patrones que pueden desglosarse fácilmente con la debida curiosidad y un profundo conocimiento. Así es como las personas aprenden a programar y crecen como desarrolladores.
Reinventa esta rueda
Así que no dudes en reinventar ruedas: escribe tu propio código para enlazar datos, crea una promesa casera o incluso haz tu propia solución para la gestión de estados.
No importa que nadie use todo esto alguna vez, ahora tienes esa habilidad. Y si tienes la oportunidad de utilizar esos desarrollos más adelante en tus propios proyectos, eso es aún mejor. Podrás expandirlos y aprender aún más.
El objetivo aquí no es enviar tu código a producción, sino aprender algo nuevo. Implementar de forma autónoma soluciones existentes es una excelente manera de aprender de los mejores programadores y perfeccionar tus habilidades.
Fuente: habr.com
