Чтобы по-настоящему понять колесо, нужно его самостоятельно переизобрести.
На днях я провел собеседование на должность senior javascript разработчика. Мой коллега, который также принимал участие в собеседовании, попросил кандидата написать функцию, которая будет выполнять HTTP-запрос, и повторять его несколько раз в случае сбоя.
Поскольку он писал это на доске, псевдокода было бы достаточно. Если бы он продемонстрировал хорошее понимание вопроса, мы были бы остались довольны. Но, к сожалению, он не смог найти хорошего решения.
Подумав что он нервничает, мы решили сделать задание немного проще и попросили его преобразовать функцию на основе обратного вызова в функцию на основе Promise.
Не повезло.
Я могу сказать, что он видел подобный код раньше. Он более или менее знал, как это работает. Псевдокода, демонстрирующего, что он понимает эту концепцию, было бы достаточно.
Но код, который он написал на доске, не имел никакого смысла. У него было только смутное понимание концепции Promise в JavaScript, и он не смог рассказать про него доходчиво.
Это может быть простительно, если вы начинающий разработчик, но если вы претендуете на руководящую должность, этого недостаточно. Как он отладит сложную цепочку Promise и затем объяснит другим, что он сделал?
Статья написана при поддержке компании EDISON Software, которая заботится о здоровье программистов и их завтраке, а также разрабатывает программное обеспечение на заказ.
Разработчики принимают абстракции как должное
Как разработчики мы работаем с абстракциями. Мы абстрагируем код, который в противном случае пришлось бы дублировать. Поэтому, когда мы сосредотачиваемся на более важных моментах, мы принимаем абстракции, с которыми работаем, как должное, и просто предполагаем, что они работают как надо.
Обычно так и есть, но когда все усложняется, стоит знать как работают эти абстракции.
Кандидат на должность senior-разработчика принял абстракцию Promise как должное. Он, вероятно, знал бы, как с ним работать, если бы он встретил это где-то в куске кода, но он не понимал концепцию и поэтому не смог воспроизвести ее на собеседовании.
Он мог просто запомнить код. Это действительно не так сложно:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Я так делал. Вероятно, мы все это делаем. Вы просто запоминаете кусок кода, чтобы вы могли работать с ним. Вы понимаете более или менее, как это работает.
Но если бы он действительно понял концепцию, ему не нужно было бы ее запоминать. Он бы просто знал это и без проблем воспроизводил.
Знай свой исходник
Еще в 2012 году, до того как фронтенд фреймворки стали доминировать и jQuery управлял миром, я прочитал «Secrets of the JavaScript Ninja» Джона Резига, создателя jQuery.
Эта книга научит вас, как создать свой собственный jQuery с нуля, и даст вам уникальное понимание мыслительных процессов, стоящих за созданием этой библиотеки. Хотя в последние годы jQuery отошел на второй план, я настоятельно рекомендую прочитать эту книгу.
Что поразило меня в книге, так это постоянное ощущение, что я мог додуматься до этого сам. Шаги, описанные в книге, были настолько логичны и просты, что я действительно ощутил, что я мог бы создать JQuery, если бы я поставил себе такую цель.
На самом деле я бы никогда не смог этого сделать — я бы посчитал это слишком сложным. Я бы подумал, что мои решения слишком просты и наивны, и я бы просто сдался. Я бы просто принял jQuery как должное и доверился бы ему. После этого я, вероятно, не стал бы разбираться, как он работает. Я бы просто использовал его как черный ящик.
Прочтение этой книги изменило меня. Я начал разбираться в исходном коде и обнаружил, что многие реализации были довольно простыми, даже очевидными.
Теперь самостоятельно придумать эти решения — совсем другое дело. Но чтение исходного кода и самостоятельная реализация существующих решений — это именно то, что помогает вам придумывать свои собственные.
Вдохновение, которое вы получаете, и шаблоны, которые вы обнаруживаете, изменят вас как разработчика. Вы обнаружите, что эта замечательная библиотека, которую вы используете и считаете магией, на самом деле не волшебная, а просто простое и умное решение.
Вы можете потратить время на разбор кода, шаг за шагом, и это также заставит вас пройти те же небольшие, постепенные шаги, которые авторы предприняли для его создания. Это дает вам более глубокое понимание процесса программирования и больше уверенности в реализации ваших собственных решений.
Когда я начал использовать Promise в JavaScript, я думал, что это магия. Затем я узнал, что они основаны на обратных вызовах, и мое видение программирования изменилось навсегда.
Этот шаблон, который должен был избавить от обратных вызовов, был реализован с использованием… обратных вызовов?
Это изменило меня. Это заставило меня осознать, что это не невероятно сложные фрагменты кода, чтобы я в них разобрался. Это модели, которые я мог бы легко понять, если бы у меня было любопытство и желание погрузиться в них.
Вот как вы действительно научитесь программировать. Вот как вы становитесь лучшим разработчиком.
Переизобретаем колесо
Так что давайте будем изобретать колеса заново. Напишите свою собственную привязку данных, свой собственный Promise или даже свое решение для управления состоянием.
Не имеет значение что никто не будет использовать это. Вы узнаете что-то новое для себя. И если вы сможете использовать его в одном из ваших собственных проектов, это будет уже здорово. Вы будете развивать этот код дальше и учиться еще больше.
Дело не в том, чтобы использовать ваше решение в производстве, а в том, чтобы учиться. Написание собственной реализации существующего решения — отличный способ учиться у лучших.
