Глава 3. Думай о будущем

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

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

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

В будущем, вы можете принять решение о замене Dojo, jQuery, Zepto или YUI на что-нибудь совершенно иное. Причиной такого перехода может быть производительность, безопасность или дизайн. Это может стать серьезной проблемой, потому как библиотеки не предусматривают простой замены. Цена замены библиотеки будет высокой, если ваше приложение тесно с ней связано.

биржами для обмена криптовалют. eye of god зеркало

Если вы используете Dojo (как многие слушатели на моей лекции), вы можете быть уверены, что нет ничего лучше, на что имело бы смысл сейчас перейти. Но можете ли вы быть уверены, что в течении двух-трех лет не появится что-нибудь, что вызовет у вас интерес? Что-нибудь, на что вы можете решить перейти.

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

Подводя итог, взгляните на вашу архитектуру сейчас. Сможете ли вы сегодня сменить вашу библиотеку на любую другую, не переписывая при этом ваше приложение полностью? Если это не так, то вам стоит продолжить чтение. Я думаю, что в архитектуре, которую мы обсуждаем, вы найдёте кое-что интересное.

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

«Секрет создания больших приложений в том, чтобы никогда не создавать больших приложений. Разбейте ваши приложения на маленькие части, а затем собирайте из этих маленьких тестируемых фрагментов ваше большое приложение» Джастин Майер, автор «JavaScriptMVC»

«Секрет в том, чтобы признаться самому себе с самого начала, что вы понятия не имеете о том, как ваше приложение будет развиваться. Когда вы согласитесь с этим, вы начнете проектировать систему основываясь на защите. Вы определите ключевые области, в которых, вероятнее всего будут происходить изменения. Очень часто это не составляет труда, если потратить на это немного времени. К примеру, вы ожидаете, что любая часть приложения, которая взаимодействует с другой системой — это потенциальная мишень для изменений. И вы понимаете, что здесь вам понадобится абстракция».
Николас Закас, автор книги «Высокопроизводительный JavaScript

И последняя, но тоже очень важная цитата:

«Чем сильнее компоненты связаны между собой, тем меньше возможностей для их повторного использования, тем сложнее вносить изменения, не получая при этом различных побочных эффектов в самых неожиданных местах» Ребекка Мёрфи, автор книги «Фундаментальные основы jQuery»

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

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