В последнее время я искал для себя новые задачи развития. Недавно я брал интервью на некоторые должности разработчиков в некоторых замечательных компаниях, у которых есть совершенно фантастические продукты. Я считаю, что роли продуктового типа лучше подходят моему типу личности. В одном из интервью интервьюер задал мне эти два вопроса:

  • Описать прототипное наследование в JavaScript.
  • Опишите поведениеthis

Это были два очень хороших вопроса о ядре JavaScript, поэтому любой закаленный разработчик JavaScript, очевидно, должен иметь возможность легко сформулировать ответы на них… не так ли?

По крайней мере, для меня это не так 😃 Я изо всех сил пытался сформулировать, как JavaScript имеет лексическую область видимости и какthis может принимать разные значения в зависимости от того, как объявлены функции, yada yada. Но в моем описании пропущено множество важных нюансов, а то, что я сформулировал, я сформулировал не очень хорошо.

Вдобавок я просто сказал, что не могу сформулировать прототипное наследование JavaScript. Я даже не хотел пытаться ответить. Я твердо придерживаюсь мнения, что честность - лучшая политика!

Вот вам и закаленный в боях разработчик JavaScript, доказавший свою весомость тем, что не может описывать столь важные для языка вещи. Но как это случилось? В какой-то момент моей карьеры в JavaScript я смог легко сформулировать такие вещи.

Так что я покинул интервью, чувствуя, что оно было скорее неудачей, чем успехом. Но, как и в большинстве интервью, которые я проходил, я кое-чему научился. В этом случае я понял, что не только изучение нового никогда не заканчивается, но мы должны время от времени возвращаться к основам, чтобы освежить знания, которые мы уже получили. Иногда мы теряем ключи от замка.

Функциональное развитие по композиции

В моем интервью часть моего ответа на неспособность хорошо ответить на вопрос о прототипном наследовании заключалась в том, что при разработке на React композиция предпочтительнее наследования, а также отдается предпочтение функциональному программированию. Парадигма разработки React не одобряет истинно объектно-ориентированный дизайн. В React я считаю, что даже проблема this теперь сведена почти к мышечной памяти при определении обработчиков событий в повседневной разработке, и, помимо обработчиков событий, как часто нам нужно думать о this? Так что за последний год мне просто не нужно было много мысленно думать об этом.

Это подводит меня к самому важному выводу из интервью:

Вернитесь к основам - научите всему, что знаете

Мы все зациклены на желании использовать новейшие и лучшие языковые шаблоны, библиотеки и фреймворки, поскольку они привлекательны и облегчают нашу жизнь. Но основы, абсолютные базовые элементы языков, которые мы используем, почти никогда не исчезнут. Как однажды сказал судья Джуди:

«Библиотеки исчезают, JavaScript - навсегда»

Конечно, основные элементы языков часто улучшаются, но они, как правило, лежат в основе всего, что мы делаем. И когда большие участки нашего кода почти становятся шаблоном, который мы можем печатать с помощью мышечной памяти, именно в этот момент мы должны иметь возможность время от времени отступать, чтобы по-настоящему понять и сформулировать, что делает этот шаблонный код, и почему он написан так, как оно есть.

Освежение нашего понимания основ стоит того, потому что ядро ​​любого языка - это то, на чем мы строим все, на чем он работает. А если вы не можете четко сформулировать основную языковую функцию ... вы ее не понимаете. Так что освежите свои знания, как я это сделаю!