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

Я должен подчеркнуть значение этой разницы — я видел разработчиков, которые, сталкиваясь с большими приложениями, делали шаг назад и говорили: «Хорошо, у меня есть несколько идей, которые хорошо показали себя в моем предыдущем проекте среднего масштаба. Думаю, они точно сработают и для чего-то большего, не так ли?». Конечно, до какого-то момента это может быть так, но, пожалуйста, не принимайте это как должное — по большей части большие приложения имеют ряд достаточно серьезных проблем, с которыми нужно считаться. Ниже я приведу несколько доводов в пользу того, почему вам стоит уделить немного больше времени планированию архитектуры своего приложения, и чем вам это будет полезно в долгосрочной перспективе.

Большинство JavaScript-разработчиков в архитектуре своих приложений обычно использует различные комбинации следующих компонентов:

Ссылки по теме:
Ребекка Мёрфи — Создание архитектуры JavaScript-приложений
Питер Мишо — MVC архитектура для JavaScript-приложений
StackOverflow — Дискуссия о современных MVC-фреймворках
Дуг Найнер — Поддерживаемые плагины и фабрика виджетов

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

1. Готова ли ваша архитектура к повторному использованию кода уже сейчас?

Могут ли отдельные модули использоваться самостоятельно? Достаточно ли они автономны для этого? Мог бы я прямо сейчас взять один из модулей вашего большого приложения, просто поместить его на новую веб-страницу, а затем, тут же, начать его использовать? У вас может возникнуть вопрос: «Действительно ли это так необходимо?», но, как бы то ни было, я надеюсь, что вы думаете о будущем. Что, если ваша компания начнет создавать все больше и больше нетривиальных приложений, которые будут иметь некоторую общую функциональность? Если кто-то скажет: «Нашим пользователям очень нравится использовать модуль чата в нашем email-клиенте, почему бы нам не добавить этот модуль к нашему новому приложению для совместной работы с документами?», будет ли это возможно, если мы не уделим должного внимания контролю кода?

2. Сколько модулей в вашей системе зависит от других модулей?

Насколько сильно связаны ваши модули? Перед тем, как я погружусь в объяснения о том, как важна слабая связанность модулей, я должен отметить, что не всегда есть возможность создавать модули, не имеющие абсолютно никаких зависимостей в системе. К примеру, одни модули могут расширять функции других, уже существующих. Эта тема, скорее всего, относится к группировке модулей на основе некоторой функциональности. Отдельные наборы модулей должны работать в вашем приложении без большого количества зависимостей, чтобы наличие или загрузка других модулей не влияла на их работоспособность.

3. Сможет ли ваше приложение работать дальше, если его отдельная часть сломается?

Если вы разрабатываете приложения, подобные Gmail, и ваш webmail-модуль (или группа модулей) перестанет работать из-за ошибки, то это не должно заблокировать пользовательский интерфейс или помешать пользователям использовать другие части вашего приложения, к примеру, такие как чат. В то же время, как было сказано раньше, было бы идеально, если бы модули могли работать и за пределами вашей архитектуры. В моей лекции я упоминал динамические зависимости — возможность загружать модули, исходя из определенных действий пользователя. К примеру, ребята из Gmail могли бы изначально держать чат закрытым, не загружая его код при открытии страницы. А в тот момент, когда пользователь решит воспользоваться им — соответствующий модуль будет динамически загружен и выполнен. В идеальном случае хотелось бы выполнить это без каких-то негативных эффектов в вашем приложении.

4. Насколько легко вы сможете тестировать отдельные модули?

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

Рекомендуем почитать:
Книги по JavaScript на ЛАБИРИНТ