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

Не переусердствуйте со своим дизайном с помощью новейших технологий, вместо того, чтобы попробовать настоящие.

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

Но прежде чем начать что-то, имейте в виду следующие вещи:

  • Переписывание болезненно: в будущем все нужно будет изменить, поэтому сделайте это легко. Ваша архитектура должна поддерживать простой рефакторинг. Хороший дизайн требует так много итераций. Если вы работаете над большим приложением, не забудьте уделить достаточно времени планированию базовой архитектуры, которая имеет наибольший смысл. Зачастую это сложнее, чем мы думаем изначально.
  • Уменьшить сложность, выбрать модульность:

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

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

  • Лучше меньше, да лучше. Создание универсальных компонентов, которые выполняют множество различных функций, МОГУТ быть чрезвычайно полезными, когда вы смотрите на общую картину в долгосрочной перспективе. Это просто должно быть сделано хорошо, и нужно дать время, чтобы стабилизироваться.
  • Шаблоны проектирования.Шаблоны проектирования — это довольно мощный подход, позволяющий всем разработчикам в организации или команде работать на одной странице при создании или обслуживании решений. Если вы планируете работать над своим собственным шаблоном, помните, что, хотя они могут иметь большие первоначальные затраты на этапах планирования и написания, отдача от этих инвестиций может быть вполне оправданной. Однако всегда тщательно изучайте, прежде чем работать над новыми шаблонами, так как вы можете найти более выгодным использовать или строить на основе существующих проверенных шаблонов, чем начинать заново.
  • Тестирование. Пишите код, который можно тестировать. Должны присутствовать модульное, функциональное и E2E-тестирование.
  • Процесс сборки. Корпоративные приложения большие, распределены по модулям и привязаны к четко определенной системе, но, в конце концов, вам нужен единый двоичный файл приложения для запуска вашего приложения.
  • Автоматизация. Это могут быть ваши задачи CI и CD, которые ускорят вашу разработку и создадут продуктивную среду в вашей команде. Задачи на разработку, сборку, тестирование, развертывание и просмотр.
  • Среды. Должна быть функция переключения различных типов среды в зависимости от конфигурации. В режиме разработки создавайте сервисы, повышающие вашу эффективность.
  • Документация. Хорошая документация является ключом к успеху любого проекта. Обеспечение доступности документации позволяет людям узнать о проекте; простота обновления гарантирует актуальность документации.
  • Журнал изменений: помогает другим командам/разработчикам узнавать об изменениях и работе. Все заметные изменения в проекте будут задокументированы в этом файле.

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

Пять частей стандартного бизнес-процесса:

В идеале ваше приложение должно быть построено с учетом бизнес-процесса и проблемы, которую вы пытаетесь решить. Давайте обсудим стандартные моменты бизнес-процесса и то, как они должны быть включены в ваше приложение:

  • Аутентификация/разрешения.Обычно каждое приложение требует аутентификации, точки входа с различными функциями. Создайте отдельную систему аутентификации для каждой функции. Абстракция, которая отделяет систему аутентификации от фактической функции, действительно полезна.
  • Настройка контекстных данных: контроллеры, фабрика. Ваши контроллеры должны быть тонкими и содержать только бизнес-логику.
  • Проверка процесса:валидатор, фильтры, модели, сервисы. Он должен иметь абстракции, которые вы можете использовать в своих контроллерах. Держите сложную часть здесь.
  • Выполнение процесса:вызовы API, отдельные промежуточные уровни, обеспечивающие возможность подключения.
  • Побочный эффект запуска:службы уведомлений, регистрации и другие службы.

Простое приложение

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

Наше решение — оболочка $http с моделями и трансляторами

Мы написали API-оболочку для http-запросов, которая также помогает нам более эффективно вызывать API:

api.get(url).then (function(response) {}).catch(function (error){});
// instead of longer $http method.
// For other http methods, Please refer to the attached code below.

Мы определяем модель, которая помогает в проверке и целостности данных. Переводчики помогают нам поддерживать одинаковый отклик API везде. Кроме того, если я использую API, который имеет такой же ответ, как и другой API, я могу использовать ту же модель данных. Если ответ API изменится в будущем, я просто сменю переводчик в одном месте.

В Innovaccer

Мы в Innovaccer Inc. используем AngularJS. Когда мы начали создавать наш продукт Datashop, было много вариантов выбора, таких как ReactJS, Angular2 и т. д., но мы выбрали AngularJS. причины следующие:

Почему мы выбрали AngularJS?

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

Продолжение следует

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

об авторе

Аюш Шарма — фронтенд-разработчик в Innovaccer и работает в продуктовой команде. Он очень увлечен разработкой программного обеспечения, решением проблем и шаблонами проектирования.