Собрали список вопросов, ответы на которые должен знать не только каждый JavaScript разработчик, но и, пожалуй, любой программист.
Назовите две наиболее важные для JavaScript-разработчика парадигмы программирования?
JavaScript – мультипарадигмальный язык, поддерживающий императивное/процедурное программирования наряду с ООП и функциональным программированием. JS поддерживает ООП с прототипным наследованием.
Желательно упомянуть:
1. Прототипное наследование (также: прототипы, объектные ссылки)
2. Функциональное программирование (также: замыкания, функции первого класса, лямбды)
Следует избегать:
Не иметь представления о парадигмах, не упомянуть прототипное ООП или функциональное программирование.
Что такое функциональное программирование?
Функциональное программирование подразумевает вычисление математических функций, избегая общих состояний и изменяемых данных. Lisp (специфицирован в 1958 году) является одним из первых функциональных языков программирования и сильно вдохновлен лямбда-исчислениями. Lisp и подобные ему языки широко применяются и по сей день.
Функциональное программирование – одна из основополагающих концепций JavaScript (один из двух столпов JS). Некоторые функциональные утилиты были добавлены в JavaScript в ES5.
Хорошо упомянуть:
1. Чистые функции / чистота функций
2. Избежание побочных эффектов
3. Простой состав функций
4. Примеры функциональных языков: Lisp, ML, Haskell, Erlang, Clojure, Elm, F Sharp, OCaml и т.д.
5. Особенности, которые поддерживает функциональное программирование: функции первого класса, функции высших порядков, функции как аргументы/значения
Следует избегать:
1. Отсутствие упоминаний чистых функций / избежание побочных эффектов
2. Не привести примеры функциональных языков
3. Не привести примеры функциональных фич JavaScript
В чем заключается разница между классовым и прототипным наследованием?
Классовое наследование: экземпляры наследуются от классов, создаются подклассовые отношения (иерархическая систематизация классов). Экземпляры реализуются через конструктор функции, через дескриптор new. Экземпляр класса может не содержать дескриптор class начиная с ES6.
Прототипное наследование: экземпляры наследуются напрямую от других объектов, реализуются через фабрики или Object.create() и экземпляры могут быть составлены из множества различных объектов для упрощения выборочного наследования. Прототипное наследование более простое и гибкое, нежели классовое.
Хорошо упомянуть:
1. Классы: тесные связи, иерархия
2. Прототипы: конкатенативное наследование, делегирование, функциональное наследование, композиция
Следует избегать:
Не указать на преимущества прототипного наследования перед классовым
Каковы плюсы и минусы функционального и объектно-ориентированного программирования?
Плюсы ООП: простая для понимания концепция объектов и методов вызова. ООП стремится использовать императивный стиль, нежели декларативный, который читается как прямой набор машинных инструкций.
Минусы ООП: как правило, присутствует зависимость от общих состояний. Объекты и их поведение связаны одной сущностью, к которой случайно может быть получен доступ любым количеством функций в неопределенном порядке, что может привести к непредсказуемому поведению, например, состоянию гонки.
Плюсы ФП: используется функциональная парадигма, позволяющая избежать общих состояний и нежелательных эффектов, исключаются ошибки, возможные из-за конкурирования функций. Благодаря таким фичам, как неявное программирование, функции, как правило, радикально упрощаются и легко перестраиваются для более легкого, по сравнению с ООП, повторного использования кода.
Вычисления, использующие чистые функции легко масштабируются на несколько процессоров или распределенных вычислительных кластеров без опасения возникновения борьбы за ресурсы.
Минусы ФП: чрезмерная эксплуатация функциональных подходов, вроде неявного программирования, может привести к снижению читабельности кода, так как конечный код получается более абстрактным, кратким и менее конкретным.
Чаще люди больше знакомы с ООП и императивным подходом, так что некоторые общие идиомы функционального программирования могут вызывать трудности у новичков.
Функциональное программирование имеет более крутую кривую обучения, нежели ООП, имеющего большую популярность и более понятного для изучения. Концепции ФП часто описываются идиомами и обозначениями из лямбда-исчислений, алгебры и теории категорий, требующих знаний основ в этих областях для понимания.
Хорошо упомянуть:
1. Проблемы общих состояний, нежелательного поведения
2. Возможности ФП по радикальному упрощению кода программ
3. Разность в сложности изучения
4. Побочные эффекты и их влияние на надежность программ
5. Сложность изменения и общая хрупкость базы ОО кода в сравнении с таковой в функциональном стиле
Следует избегать:
Не упомянуть недостатки одного из подходов – каждый, кто сталкивался с одним из них, знает и о паре-другой недостатков
Когда классовое наследование – подходящий выбор?
Вопрос с подвохом. Правильный ответ – никогда. Композиция – более простой и гибкий подход, чем наследование классов.
Хорошо упомянуть
"...композиция объектов лучше, чем наследование классов"
Следует избегать:
Упоминание Rect Components. React.js использует дескриптор class, но не позволяет избежать подводных камней классового наследования. Вопреки популярным ответам, не нужно использовать class, чтобы пользоваться React. Такой ответ покажет не понимание как классов в JavaScript, так и Реакта.
Когда лучше использовать прототипное наследование?
Существует более, чем один тип прототипного наследования:
1. Делегирование (цепочка прототипов)
2. Конкатенация (миксины, Object.assign())
3. Функциональное наследование (не путать с функциональным программированием. Функция используется для создания замыкания для private/инкапсуляции)
Хороший ответ:
1. В ситуациях, когда модули или функциональное программирование не обеспечивают очевидного решения
2. Когда нужно собрать объект из нескольких источников
3. В любом случае, когда нужно применить наследование
Следует избегать:
1. Не знать, когда применяются прототипы
2. Не знать о миксинах или Object.assign()
Что значит "композиция объектов лучше, чем наследование классов"?
Это цитата из книги “Design Patterns: Elements of Reusable Object-Oriented Software”. Повторное использование кода должно достигаться за счет сборки малых единиц функциональности в новый объект, а не наследованием классов и созданием иерархий.
Хорошо упомянуть:
1. Избежание наследования и тесных связей
2. Избежание вытекающей из классического наследования проблемы "банан/мартышка" (нужен был банан – получили мартышку, держащую банан посреди джунглей)
Следует избегать:
Не назвать какую-то из упомянутых выше проблем. Не объяснить разницу между композицией и наследованием или не суметь рассказать об преимуществах композиции.
Что такое двусторонняя связь данных и однонаправленный поток данных и в чем разница между ними?
Двусторонняя связь данных подразумевает, что поля интерфейса связаны с моделью данных динамически, то есть при изменении полей интерфейса меняется модель, и наоборот.
Однонаправленный поток данных означает, что только модель – источник истины. Изменения в интерфейсе запускают сообщения, которые сигнализируют пользователю о намерении модели (или "store" в терминах React). Смысл в том, что данные всегда идут в одном направлении, что облегчает понимание.
Односторонние потоки данных детерминированы, тогда как двусторонняя привязка может вызывать нежелательные эффекты, которые труднее отследить и понять.
Хорошо упомянуть:
1. React – новый канонический пример однонаправленного потока данных, так что упоминание Реакта будет хорошей идеей. Cycle.js - еще одна популярная реализация однонаправленного потока данных.
2. Angular – популярный фреймворк, использующий двустороннюю привязку.
Следует избегать:
Непонимание этих концепций, неспособность объяснить разницу между ними.
Каковы плюсы и минусы монолитной архитектуры и микросервисов?
Монолитная архитектура означает, что ваше приложение написано как единый связный блок кода, чьи компоненты спроектированы для совместной работы и использования общих ресурсов.
Подход микросервисов подразумевает, что приложение состоит из множества небольших независимых приложений, способных работать с собственными ресурсами и потенциально на большом количестве отдельных машин.
Преимущества монолитной архитектуры: основным преимуществом монолитной архитектуры является то, что большинство приложений, как правило, имеют множество общих проблем, таких как логирование, ограничение скорости и необходимость функций безопасности – в едином приложении для каждого компонента их проще решать.
Минусы монолитного приложения: так как все компоненты тесно связаны друг с другом, по мере развития приложения, становится труднее его понимать, появляется много неочевидных зависимостей и побочных эффектов.
Плюсы микросервисов: микросервисы обычно лучше организованы, так как каждый компонент выполняет свою задачу и работает независимо от каждого другого компонента. Приложение на основе обособленных компонентов также проще переконфигурировать и изменять.
Минусы микросервисов: при создании нового микросервиса может появится много внезапных проблем, которые не ожидались при проектировании. Для монолитного приложения можно использовать промежуточное программное обеспечение для решения различных сквозных проблем без особых трудозатрат.
При микросервисной архитектуре либо потребуются накладные расходы на отдельные модули для каждой сквозной проблемы, либо нужно инкапсулировать их на другом уровне обслуживания, через который проходит весь трафик.
В конце концов, даже монолитные архитектуры имеют тенденцию направлять трафик через внешний уровень обслуживания, но с монолитной архитектурой можно отложить затраты на эту работу до тех пор, пока проект не станет более зрелым.
Микросервисы же часто развертываются в собственных виртуальных машинах или контейнерах, что приводит к быстрому увеличению числа конфликтов по виртуальным ресурсам.
Хорошо упомянуть:
1. Несмотря на начальную дороговизну, микросервисы выигрывают в долгосрочной перспективе за счет лучшего масштабирования
2. Практические различия микросервисов и монолитных приложений
Следует избегать:
1. Незнание различий архитектур
2. Незнание недостатков микросервисов
3. Недооценивать преимущества масштабирования микросервисов
Что такое асинхронное программирование и почему оно важно в JS?
Синхронное программирование означает, что за исключением условий и вызовов функций, код исполняется последовательно от верха к низу, задерживаясь на длинных задачах, таких как сетевые запросы и чтение/запись с диска.
Асинхронное программирование подразумевает, что когда требуется операция блокировки, запрос отправляется, и код продолжает работать без блокировки до ожидания результата. Когда ответ готов, запускается прерывание, это приводит к запуску обработчика событий и поток управления продолжается. Таким образом, один программный поток может обрабатывать множество параллельных операций.
Пользовательские интерфейсы по своей природе асинхронны, большую часть времени они проводят, ожидая пользовательского ввода, чтобы прервать цикл и запустить обработчик.
Node.js по умолчанию асинхронен, по сути, сервер проводит все время в цикле, ожидая сетевой запрос.
В JavaScript это важно, так как естественно для интерфейсов и положительно сказывается на производительности сервера.
Хорошо упомянуть:
1. Значение блокировок, влияние на производительность
2. Понимание обработчиков и почему они важны для интерфейсов
Следует избегать:
1. Непонимание терминов синхронности и асинхронности
2. Неспособность определить последствия для производительности
Комментарии