Привет, Хаброжители! Вы пока еще не знаете JS. И Кайл Симпсон признается, что тоже его не знает (по крайней мере полностью)… И никто не знает. Но все мы можем начать работать над тем, чтобы узнать его лучше. Сколько бы времени вы ни провели за изучением языка, всегда можно найти что-то еще, что стоит изучить и понять на другом уровне.Учтите, что, хотя книга и называется «Познакомьтесь, JavaScript», она не для новичков. У нее другая задача: дать обзор тем, в которых необходимо разобраться на начальном этапе изучения JS. Даже если вы уже написали достаточно кода JS, эту книгу не стоит пропускать, возможно, в ваших знаниях есть пробелы, которые необходимо заполнить перед углубленным изучением сложных тем.
Общая картина
В этой книге приведен обзор тем, в которых необходимо разобраться в начале изучения JS. Книга призвана заполнить пробелы, которые могли подвести читателей, не имеющих опыта JS, на первых порах знакомства с языком. Я также надеюсь, что книга намекает на более глубокие подробности, которые разожгут ваше любопытство и побудят больше узнать о языке.
В остальных книгах серии прочие части языка рассматриваются очень детально, что было бы невозможно сделать в нескольких коротких главах.
И все же помните: не нужно торопиться. Не неситесь к следующей книге, пытаясь выхватить что-нибудь полезное на бегу, не жалейте времени и вернитесь к уже просмотренному материалу. Выделите еще немного времени на анализ кода ваших текущих проектов и сравните его с тем, что рассматривалось в книге.
В последней главе структура языка JS разделена на три столпа. Далее приводится краткий план того, чего можно ожидать от других книг серии и как бы я рекомендовал действовать дальше. Также не пропускайте приложения, особенно приложение Б — раздел «Практика, практика, практика!»
Столп 1: области видимости и замыкания
Организация переменных по областям видимости (функции, блоки) — одна из фундаментальных характеристик любого языка; возможно, никакая другая характеристика не оказывает столь значительного влияния на поведение программ.
Области видимости можно сравнить с банками, а переменные — с цветными камешками, которые вы раскладываете по этим банкам. Тогда модель области видимости языка напоминает набор правил, которые помогают определить, в какой банке должны находиться камешки конкретного цвета.
Области видимости могут вкладываться друг в друга, и для любого заданного выражения или команды доступны только переменные на этом или на одном из более высоких уровней (внешние области видимости); переменные на более низких уровнях (внутренние области видимости) скрыты и недоступны.
Так ведут себя области видимости в большинстве языков (так называемые лексические области видимости). Границы единиц областей видимости и принадлежность переменных к этим областям определяются во время разбора (компиляции) программы. Иначе говоря, это решение, принимаемое на стадии создания программы: расположение функций/областей видимости в программе определяет структуру областей видимости в этой части программы.
JS использует лексические области видимости, хотя многие разработчики утверждают, что это не так, из-за двух специфических характеристик модели, отсутствующих в других языках с лексическими областями видимости.
Первая особенность обычно называется поднятием (hoisting): все переменные, объявленные в любой точке области видимости, интерпретируются так, словно объявлены в ее начале. Вторая особенность заключается в том, что переменные, объявленные с ключевым словом var, имеют функциональную область видимости, даже если располагаются в блоке.
Ни поднятия, ни функциональной области видимости var недостаточно для того, чтобы подкрепить утверждение об отсутствии лексической видимости в JS. У объявлений let/const существует специфическое ошибочное поведение, называемое временной мертвой зоной (TDZ, Temporal Dead Zone), из-за которого могут появляться наблюдаемые переменные, которые не могут использоваться. Как бы странно ни выглядела TDZ, она также отменяет зону лексической видимости. Все это лишь уникальные особенности языка, которые должен узнать и понять каждый разработчик JS.
Замыкание является естественным результатом лексической видимости в языках, в которых функции являются полноправными значениями, как в JS. Когда функция создает ссылки на переменные из внешней области видимости, а потом эта функция передается как значение и выполняется в других областях видимости, она сохраняет доступ к переменным исходной области видимости; в этом состоит суть замыкания.
Во всем программировании, но особенно в JS, замыкания лежат в основе многих важных паттернов проектирования, включая модули. На мой взгляд, модули лучше всего соответствуют принципам организации кода в JS.
В книге 2, «Области видимости и замыкания», вы сможете больше узнать об областях видимости, замыканиях и работе модулей.
Столп 2: прототипы
Вторым столпом языка является система прототипов. Эта тема подробно рассматривалась в главе 3, раздел «Прототипы», но хочу просто сделать несколько замечаний относительно ее важности. JS — один из очень немногих языков, в которых объекты можно создавать явно и непосредственно, без предварительного определения их структуры в классе.
Многие годы разработчики реализовывали на основе прототипов паттерн проектирования «класс», так называемое прототипическое наследование (см. приложение А, раздел «Прототипические «классы»). Затем с появлением в ES6 ключевого слова class язык ускорил свое движение по направлению к программированию в стиле ОО/классов.
Но я считаю, что это стремление только скрывает красоту и мощь системы прототипов — способности двух объектов просто соединиться друг с другом и взаимодействовать динамически (во время выполнения функции/метода) посредством совместного использования контекста this.
Классы — всего лишь один из паттернов, которые можно реализовать на основе этой мощи. Можно подойти с совершенно другой стороны: просто принять объекты как объекты, забыть о классах и предоставить объектам взаимодействовать через цепочку прототипов. Такой подход называется делегированием поведения. Я считаю, что для организации поведения и данных делегирование работает лучше, чем наследование классов.
Однако почти все внимание достается наследованию классов. А его остатки приходятся на долю функционального программирования (FP, functional programming) как своего рода «антиклассовому» подходу к проектированию программ. Меня это огорчает, потому что в результате никто не рассматривает делегирование как жизнеспособную альтернативу.
Рекомендую выделить больше времени на книгу 3, «Объекты и классы», — она показывает, что делегирование объектов имеет существенно больший потенциал, чем вы, возможно, представляли себе. Я вовсе не являюсь противником классов, но намеренно выдвигаю тезис: «Классы — не единственный механизм работы с объектами». Мне хотелось бы, чтобы как можно больше разработчиков JS задумалось над этим.
На мой взгляд, делегирование объектов намного лучше соответствует духу и стилистике JS, чем классы.
Столп 3: типы и преобразования
Безусловно, третий столп JS чаще всего упускают из виду при рассмотрении природы JS.
Абсолютное большинство разработчиков совершенно превратно представляют себе работу типов в языках программирования, особенно в JS. Волна интереса в широком сообществе JS способствовала переходу на решения со статической типизацией и инструменты с поддержкой типов вроде TypeScript или Flow.
Согласен, разработчики JS должны больше знать о типах и о том, как JS управляет преобразованиями типов. Я также согласен с тем, что инструменты с поддержкой типов могут пригодиться — при условии, что разработчики уже получили эти знания и воспользовались ими!
Но я совершенно не согласен с постоянно встречающимся выводом о том, что механизм типов JS плох и типы JS необходимо прикрыть решениями, лежащими за пределами языка. Чтобы умно и основательно пользоваться типами в программе, совершенно не обязательно следовать принципам статической типизации. Есть и другие варианты, если в вас живет дух противоречий и вы хотите действовать в стиле JS (а впрочем, об этом позднее).
Пожалуй, этот столп важнее первых двух в том смысле, что ни одна программа JS не сможет сделать ничего полезного, если не будет правильно пользоваться типами значений JS, а также преобразованиями значений между разными типами.
Даже если вы любите TypeScript/Flow, то не сможете извлечь максимум пользы из них или методологий программирования без глубокого знания того, как сам язык обходится с типами значений.
Чтобы больше узнать о типах JS и преобразованиях, см. книгу «Типы и грамматические конструкции». Но пожалуйста, не пропускайте эту тему только потому, что вы постоянно слышали, будто всегда должны использовать === и забыть обо всем остальном.
Без изучения этого столпа вы не сможете в полной мере владеть JS.
По ветру
Дам совет относительно того, как вам продолжать свое познавательное путешествие по JS и ваш путь по остальным книгам серии: помните о ветре.
Для начала задумайтесь над тем, как большинство людей подходит к изучению и использованию JS. Вероятно, вы уже заметили, что эти книги во многих отношениях идут против ветра. В серии YDKJSY я достаточно уважаю читателя, чтобы объяснять все части JS, не ограничиваясь популярными темами. Я искренне верю, что вы заслуживаете (и способны) получить полное представление о языке.
Но такой подход отличается от того, который применяется в большинстве существующих материалов.
Также он означает, что чем больше вы будете следовать рекомендациям в этих книгах — т. е. будете тщательно обдумывать и самостоятельно анализировать, что лучше подойдет для вашего кода, — тем больше вы будете выделяться среди коллег. Это может быть и хорошо, и плохо. Лучший способ выделиться на общем фоне — делать что-то по-другому.
Но многие люди также говорили мне, что приводили объяснения из книг во время собеседования и интервьюер говорил кандидату, что тот ошибается; более того, у нескольких человек, по их утверждениям, даже были отозваны офферы.
По возможности я стараюсь приводить абсолютно точную информацию о JS, источником которой обычно является сама спецификация. Но в книгах есть и мое личное мнение насчет наилучших способов интерпретации и использования JS. Я не выдаю свои мнения за факты или наоборот. Читателям всегда понятно, что есть что.
Факты, касающиеся JS, обычно неоспоримы. В спецификации либо что-то сказано, либо нет. Если вам не нравится, что говорится в спецификации, — обсуждайте это с TC39! Если на собеседовании интервьюер утверждает, что вы ошибаетесь относительно фактов, спросите, может ли он подтвердить свое высказывание по спецификации. Если интервьюер не изменит своего решения, скорее всего, работать в этом месте не стоит.
Но если вы решили разделить мою точку зрения на те или иные вопросы, будьте готовы к тому, что ее придется отстаивать. Не ограничивайтесь простым повторением моих слов. Сформируйте свое мнение. Защищайте его. И если кто-то, на кого вы хотите работать, с вами не согласен, уходите. JS обширен, и в нем хватит места для множества разных подходов.
Иначе говоря, не бойтесь идти против ветра, как это делаю я в своих книгах и учебных курсах. Никто не сможет вам сказать, как использовать JS наиболее эффективно; решение остается за вами. Я всего лишь стараюсь дать вам возможность прийти к собственным заключениям, какими бы они ни были.
С другой стороны, существует «ветер», на который действительно следует обращать внимание и следовать за ним: это то, как работает JS на уровне языка. В JS некоторые вещи работают хорошо и естественно (при должной практике и старании), но есть и другие, которые даже не стоит пытаться делать.
Можно ли сделать так, чтобы программа на JS была внешне похожа на программу Java, C# и Perl? А как насчет Python, или Ruby, или даже PHP? В той или иной степени — безусловно, возможно. Но стоит ли?
На мой взгляд, не стоит. Считаю, что вам следует изучить и принять подход JS и писать свои программы в стиле JS настолько, насколько это практично. Кто-то скажет, что это подразумевает неформальное и неряшливое программирование, но я о другом. Просто в JS существует множество паттернов и идиом, которые легко узнаются как характерные для JS, и умение идти по ветру — стандартный путь к успеху.
Наконец, возможно самое важное, что необходимо понять: как ваши программы и коллеги-разработчики справляются со своими задачами. Не думайте, что после чтения этих книг вам удастся за ночь изменить все тенденции в существующих проектах. Такой подход всегда обречен на неудачу.
Изменения придется вносить понемногу и неспешно. Постарайтесь объяснить коллегам, почему важно снова вернуться и переосмыслить ваш подход. Но делайте это постепенно, и пусть сравнения кода «до и после» говорят за вас. Соберите всю команду для обсуждения и выступайте за решения, основанные на анализе и подтверждающей информации из кода, а не на том, что «наш старший разработчик всегда делал это так».
И это самый важный совет, который поможет вам в изучении JS. Всегда ищите возможности лучше использовать те средства, которые вам предоставляет JS, для написания более понятного кода. Каждый, кто будет работать над вашим кодом (включая вас самого в будущем), будет вам благодарен!
По порядку
Итак, теперь у вас имеется более широкое представление о том, что вам предстоит исследовать в JS, и правильный настрой, с которым вы отправитесь в свое путешествие.
Один из самых распространенных вопросов, которые мне обычно задают в этот момент, звучит так: «А в каком порядке нужно читать книги?» И на него обычно можно дать прямолинейный ответ… но не всегда.
Большинству читателей я рекомендую осваивать книги серии в следующем порядке:
1. Начните с изучения основ JS в книге «Познакомьтесь, JavaScript» (книга 1) — хорошие новости, вы уже почти закончили эту книгу!
2. В книге «Области видимости и замыкания» (книга 2) ознакомьтесь с первым столпом JS: лексической видимостью, а также тем, как она поддерживает замыкания и как паттерн «Модуль» используется для организации кода.
3. В книге «Замыкания и объекты» (книга 3) сосредоточьтесь на втором столпе JS: как работает this в JS, как прототипы объектов поддерживают делегирование и как прототипы делают возможным механизм классов для организации кода в ОО-стиле.
4. В книге «Типы и грамматические конструкции» (книга 4) рассматривается третий и последний столп JS: типы и преобразования типов, а также влияние синтаксиса и грамматики JS на то, как мы пишем свой код.
5. Когда вы успешно освоите все три столпа, в книге «Асинхронная обработка и оптимизация» (книга 5) изучите использование программной логики для моделирования изменений состояния в программах как синхронно (немедленно), так и асинхронно (со временем).
6. Серия завершается книгой «ES6 и не только» (книга 6) — взглядом в ближнее и далекое будущее JS, включая разнообразные возможности, которые в скором времени с большой вероятностью появятся в программах JS.
Так выглядит рекомендуемый порядок чтения книг серии.
Однако книги 2–4 обычно можно читать в произвольном порядке в зависимости от того, какая тема вас интересует и что вам будет проще изучать сначала. Но не рекомендую пропускать хотя бы одну из этих трех книг — даже книгу «Типы и грамматика», хотя такое искушение наверняка возникнет у некоторых из вас! — даже если вы думаете, что в этой теме вы уже разбираетесь.
Книга 5 («Асинхронная обработка и оптимизация») критична для глубокого понимания JS. Но если вы начнете изучать ее и решите, что материал слишком сложный, отложите ее до тех пор, пока вы не начнете лучше разбираться в языке. Чем больше кода JS вы написали, тем больше вы оцените эту книгу. Не бойтесь возвращаться к ней в будущем.
Последняя книга серии «ES6 и не только» в некоторой степени обособлена. Ее можно читать в последнюю очередь или же сразу же после книги «Познакомьтесь, JavaScript», если вы хотите расширить свои представления о сути JS. Скорее всего, эту книгу я буду еще обновлять, так что стоит время от времени возвращаться к ней.
Но в каком бы порядке вы ни решили знакомиться с книгами YDKJSY, для начала прочитайте приложения, особенно фрагменты из приложения Б «Практика, практика, практика!». Я ведь уже говорил, что вы непременно должны практиковаться? Лучший способ научиться программировать — писать код.
Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок
Для Хаброжителей скидка 25% по купону — JavaScript
По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
