Источник: Nuances of Programming
На днях я проводил собеседование на позицию senior разработчика JavaScript. Мой коллега, тоже присутствовавший на собеседовании, попросил претендента написать функцию, которая будет выполнять HTTP-вызов и повторять его несколько раз в случае неудачи.
Так как он писал код на маркерной доске, псевдокода было бы достаточно. Мы были бы довольны, если бы он просто продемонстрировал хорошее понимание вопроса. Но, к сожалению, он не смог найти хорошее решение.
Подумав, что он просто нервничал, мы решили сделать задачу проще и попросили его преобразовать функцию, основанную на обратном вызове, в функцию, основанную на промисе.
Неудачно.
Да, я могу сказать, что он видел похожий код раньше. Он в той или иной степени знал, как он работает. Решения в псевдокоде, демонстрирующего его понимание концепции было бы достаточно.
Но код, который он написал на доске, вообще не имел смысла. У него было только отдаленное представление о концепции промисов в JavaScript и он не смог хорошо его объяснить.
Подобное может сойти вам с рук, если вы junior разработчик, но если вы претендуете на позицию senior разработчика, этого совершенно недостаточно. Как бы он смог отладить цепочку промисов и потом объяснить свои действия другим?
Разработчики принимают абстракции как должное
Мы работаем с абстракциями. Мы абстрагируем код, который в противном случае пришлось бы повторять. Поэтому, когда мы концентрируемся на более важных участках, мы принимаем абстракции как должное и просто предполагаем, что они работают.
Обычно так и есть, но, когда все усложняется, необходимо действительно знать, как эти абстракции работают.
Кандидат на позицию senior разработчика принял абстракцию промисов как должное. Он, возможно, знал, как с ней работать, если бы увидел ее где-то в куске кода, но он в действительности не понимал концепцию и не был способен воспроизвести ее на собеседовании.
Он мог просто запомнить код. На самом деле это не так уж и сложно:
Я заучивал, как и многие другие. Вы просто запоминаете кусок кода и можете иметь с ним дело, более или менее понимая, как он работает.
Но если бы он действительно понимал концепцию, ему не нужно было бы запоминать код. Он бы просто знал его и не испытывал проблем с его воспроизведением.
Знайте ваш источник
Еще в 2012, до того, как фронтенд фреймворки стали доминировать, миром управляла jQuery, и я читал книгу “Секреты JavaScript ниндзя” Джона Резига, создателя jQuery.
Эта книга учит, как создавать собственный jQuery с нуля, и дает уникальное понимание мыслительных процессов, стоящих за созданием этой библиотеки. Хотя в последние годы jQuery отошла на второй план, я настоятельно рекомендую прочитать вам эту книгу.
Больше всего в ней меня поразило постоянное чувство того, что я мог бы и сам до этого додуматься. Описанные шаги были настолько логичны и просты, что я действительно почувствовал, что сам смог бы создать jQuery, если бы взялся за это.
Разумеется, в реальности я бы никогда не смог этого сделать — мне бы это показалось слишком сложным. Я бы поверил, что мои решения слишком просты и наивны, чтобы они заработали, и просто сдался. Я бы принял jQuery как должное и поверил, что он работает. После этого я, наверное, не стал тратить время на то, чтобы разобраться, как это работает, просто использовал бы как черный ящик.
Но эта книга изменила меня. Я начал читать исходный код и обнаружил, что многие реализации решений были очень простыми, даже очевидными.
Разумеется, придумать эти решения самостоятельно совершенно другое дело. Но чтение исходного кода и самостоятельная реализация существующих решений и есть именно то, что помогает появиться вашим собственным решениям.
Вдохновение, которое вы получите, и шаблоны, которые вы откроете, изменят вас как разработчика. Вы увидите, что эта великолепная магическая библиотека, которую вы используете, в реальности совсем не волшебная, а очень даже простая, но продуманная.
Для понимания кода требуется время. Шаг за шагом, постепенно вы пройдете тот же путь, который прошли авторы, чтобы создать эту библиотеку. Вы получите более глубокое понимание процесса написания кода и больше уверенности в ваших собственных решениях.
Когда я начал использовать промисы в JavaScript, я думал, что они какая-то магия. Затем я узнал, что они просто основаны на обратных вызовах, и мое видение программирования изменилось навсегда.
Этот шаблон, который должен был освободиться от обратных вызовов, был внедрен с помощью… обратных вызовов?
Это изменило меня и заставило понять, что эти фрагменты кода не такие уж и сложные. Они лишь шаблоны, которые легко понять, если проявить любопытство и терпение.
Вот так я действительно научился программировать. Вот как вы становитесь лучшим разработчиком.
Изобретите колесо
Так что идите вперед и изобретайте колесо. Напишите ваш собственный биллинг данных, собственный промис или даже собственное решение для управления состоянием.
Не имеет значения, будет ли кто-нибудь их использовать. Вы научитесь. И если вы сможете применить этот код в одном из ваших проектов, будет здорово. Вы будете развивать его дальше и научитесь еще большему.
Смысл не в том, чтобы использовать ваше решение в продакшне. Писать код с вашими собственными реализациями существующих решений — это прекрасный способ учиться у лучших.
Читайте также:
Перевод статьи Danny Moerkerke: Why Coding Your Own Makes You a Better Developer