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

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

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

▍ Typescript

— Да

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

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

▍ Управление состояниями

— Да

Управление состояниями – это ещё один важный аспект при создании любого среднемасштабного фронтенд-приложения. Чем сложнее становится приложение, тем труднее управлять его состоянием. В этом отношении существует много библиотек и фреймворков, таких как Redux, MobX, Vuex и Pinia. Эти инструменты помогают поддерживать согласованное состояние приложения и упрощают добавление новой функциональности. Но тут важно иметь ввиду, что глобальное состояние создаёт зацепление, и нужно всерьёз подумать о разделении ресурсов на несколько модулей. Кроме того, старайтесь не злоупотреблять этой техникой для того, что не должно быть глобально доступным, например, для состояния компонентов.

▍ Фича-флаги

— Да

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

▍ Тестирование

— И да, и нет

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

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

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

▍ CI/CD

— Да

Ещё одной важной частью современной разработки выступает непрерывная интеграция и развёртывание (CI/CD, Continuous Integration/Continuous Deployment). С помощью CI/CD можно автоматизировать процесс сборки, тестирования и развёртывания, сэкономив время и уменьшив число возможных ошибок. Используя соответствующий инструмент, можно повысить эффективность разработки и обеспечить постоянную готовность приложения к развёртыванию.

▍ Предметно-ориентированное проектирование

— Нет

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

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

▍ Гексагональная архитектура

— Нет

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

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

▍ Микро-фронтенды

— Нет

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

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

▍ CDN

— Да

Использование CDN (сеть доставки контента, Content Delivery Network) является быстрым, простым и малозатратным способом повышения производительности и надёжности вашего приложения за счёт передачи его контента с исходного сервера на пограничные узлы, откуда он уже загружается на устройство пользователя.

▍ Линтинг

— Да

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

▍ Наблюдаемость

— Да

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

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

▍ Доступность

— Да

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

▍ Система проектирования

— Нет

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

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

▍ Заключение

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

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

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх ????️