За последнее десятилетие JavaScript превратился в то, что многие назвали бы «большим делом». Благодаря нескольким разновидностям учебных курсов по коду, самоучителям и множеству контента Stack Overflow барьер для входа в качестве разработчика программного обеспечения ниже, чем когда-либо. Однако начать свой путь в качестве разработчика и изучить основы не так уж сложно. Итак, что происходит, когда вы знаете все основы? Что делает разработчика больше, чем просто разработчиком начального уровня? Достаточно ли количественной оценки времени, затрачиваемого на выполнение основных задач разработчика в течение длительного периода, чтобы назвать человека опытнымразработчиком?

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

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

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

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

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

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

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

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

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

Затем архитектура определяет эти детали как структуры в системе и устанавливает правила взаимодействия друг с другом.

Например, приложение может использовать Redux, что само по себе является лишь деталью реализации. Однако как структура хранилище состояний является единственным источником состояния в большинстве приложений, которые его используют. Наряду с структурой хранилища состояний существует множество правил, таких как неизменность состояния и процедуры, определяющие, как код может обновлять состояние приложения. Структура State Store и окружающие его правила составляют его архитектуру.

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

Та же истина применима ко всему приложению. Если вы потратите вдумчивое время на планирование и определение системы перед ее созданием, вам будет намного проще внедрить ее и добавить функции по запросу. Я не говорю, что вы все продумаете до того, как начнете работу над проектом, но у вас будет отличный старт, когда вы разберетесь с остальным по пути.

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