Исследование и выбор фреймворков для разработки веб-приложений

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

ВВЕДЕНИЕ

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

Изначально для разработки веб-сайтов было достаточно языка HTML для создания разметки и CSS для описания визуальных стилей, однако с популяризацией и увеличением доступности сети Интернет к ним стали предъявляться всё более и более жесткие требования и на помощь веб-разработчикам пришёл динамический язык программирования JavaScript (JS), позволяющий добавлять интерактивность на сайты.

Однако, в последние несколько лет веб-сайты стали более нагруженными, так как стали выполнять более широкий спектр задач и получили чуть ли не большее распространение по сравнению с десктопными приложениями, поэтому появилась необходимость в повышении их производительности и структурированности, ускорении и упрощении как разработки такого рода веб-приложений, так и обработки ими данных. Для решения таких задач ведущими ИТ-специалистами были придуманы веб-фреймворки, наибольшую популярность из которых получили: ReactJS, Vue.js и Angular.

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

Проблеме выбора фреймворка для разработки веб-приложения посвящено большое количество работ отечественных и зарубежных исследователей, среди которых такие авторитетные лица JavaScript-разработки, как Andrei Neagoie, John Hannah, Sunil Sandhu, Evan You и другие[1-4]. В своих работах исследователи пытались сформулировать рекомендации для выбора фреймворков при разработке продуктов различной сложности и масштаба, рассуждали о преимуществах и недостатках фреймворков. Также существует площадки, приводящие ежегодную, а порой и ежемесячную статистику популярности фреймворков среди разработчиков и работодателей. Хотя имеющиеся в открытом доступе работы представляют субъективное мнение, многие из авторов пользуются авторитетом среди разработчиков со всего мира, что позволяет назвать приведенные работы экспертным мнением.

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

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

Объектом исследования являются фреймворки для разработки веб-приложений на языке JS.

Предметом исследования являются программные продукты.

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

Задачи, поставленные в диссертационной работе:

1) исследование и выбор фреймворков для разработки веб-приложений;

2) исследование и выбор средств разработки;

3) разработка алгоритма сравнения программных продуктов;

4) разработка структуры приложения;

5) исследование полученных программных продуктов на основе алгоритма их сравнения.

Положения, выносимые на защиту:

1. Разработана структура веб-приложений, основанных на компонентном подходе.

2. Разработан алгоритм проведения сравнения однотипных программных продуктов, созданных на базе различных фреймворков.

Научная новизна:

1) Разработка структуры системы, позволяющей ускорить и упростить разработку программных продуктов.

2) Разработка алгоритма проведения сравнения однотипных программных продуктов, созданных на базе различных фреймворков.

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

Теоретические и практические результаты могут быть применены для разработки веб-приложений и будут выложены в публичный репозиторий.

Основные результаты работы были опубликованы на следующих конференциях:

? Национальная научно-практическая конференция «Актуальные проблемы науки и практики в различных отраслях народного хозяйства» (Пенза, 2018);

? 6-ая Международная научно-техническая конференция «Качество в производственных и социально-экономических системах» (Курск, 2018);

? Международная научно-практическая конференция «Интеграция науки, общества, производства и промышленности» (Тюмень, 2019) - 2 статьи;

? 4-ая Всероссийская научно-техническая конференция с международным участием «Перспективы развития технологий обработки и оборудования в машиностроении» (Курск, 2019).

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

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



1. АНАЛИТИЧЕСКИЙ ОБЗОР

фреймворк интерфейс алгоритм база

1.1 Анализ предметной области

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

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

Исходя из такой потребности появилась новая концепция программирования - реактивное программирование - парадигма программирования, ориентированная на потоки данных и распространение изменений. Это означает, что должна существовать возможность легко выражать статические и динамические потоки данных, а также то, что нижележащая модель исполнения должна автоматически распространять изменения благодаря потоку данных[5].

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

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

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

Веб-фреймворки (JS-фреймворки) - это инструменты для построения динамических веб-, мобильных и одностраничных приложений на языке JavaScript. В большинстве случаев разработчики используют их в тех случаях, когда предоставленную задачу невозможно, сложно или очень долго выполнять стандартными средствами. Чаще всего фреймворки используют для написания одностраничных приложений, представляющих собой одну страницу, на которой динамически происходят нужные действия без перехода с неё[6].

К преимуществам использования веб-фреймворков можно отнести:

1) высокая скорость разработки;

2) безопасность;

3) минимизация расходов (большинство из веб-фреймворков имеют открытый код и являются бесплатными);

4) высокая производительность за счет минимизации и оптимизации кода;

5) модульность.

К недостаткам веб-фреймворков можно отнести:

1) трудности разработки из-за некоторых его ограничений;

2) сложности с обновлением версии.

Затрагивая тему популярных JS-фреймворков нельзя не сказать несколько слов о наиболее часто используемых из них.

На 2019 год наиболее популярными веб-фреймворками являются:

1) React;

2) AngularJS;

3) Vue.js.

React является достаточно сложным в изучении из-за недостаточно полной и качественной документации, его функциональность не столь велика, как у некоторых других JS-фреймворков, однако, он по праву занимает одну из лидирующих позиций в большинстве существующих современных рейтингов веб-фреймворков из-за того, что в нем есть множество шаблонов и готовых функций для front-end'а, удобство использования HTML+JavaScript, т.е. синтаксис JSX, наличие расширений для браузеров, позволяющих производить качественную отладку кода, возможность рендеринга как на клиентской стороне, так и на серверной.

React считается самым быстрорастущим JS-фреймворком и подходит как для создания маленьких приложений, так и для крупных проектов.

Преимущества React:

1) компактность, эффективность, производительность и гибкость;

2) простая модель компонентов;

3) обилие онлайн-ресурсов для изучения;

4) большое сообщество разработчиков с огромным количеством готовых решений;

5) возможность рендеринга как на клиенте, так и на сервере.

Недостатки React:

1) новый синтаксис для изучения;

2) необходимы системы сборки;

3) требование сторонних инструментов и библиотек;

4) может быть несовместим с кодом и другими библиотеками, модифицирующими DOM-дерево.

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

Преимущества:

1) быстрое написание кода;

2) высокий уровень читабельности кода;

3) быстрое тестирование любой части приложения;

4) удобство использования.

Недостатки:

1) сложность в освоении;

2) низкая производительность интерфейсов.

Vue.js - легкий современный фреймворк для создания пользовательских интерфейсов. Использует синтаксис шаблона HTML для связки DOM и данных. Модели являются простыми javascript-объектами, которые перестраивают интерфейс и/или контент при изменении данных.

Многофункциональный и производительный, позволяет обрабатывать вводимые пользователем данные, создавать шаблонные компоненты и многое другое.

Преимущества:

1) прост в освоении;

2) хорошая производительность;

3) мало зависимостей;

4) отличная документация.

Недостатки:

1) высокие риски;

2) небольшое сообщество разработчиков, соответственно, мало готовых решений.

Также ниже приведены графики, отображающие востребованность и рейтинги вышеперечисленных веб-фреймворков на конец 2018 года (Рис. 1 - 3):



Рисунок 1 - График востребованности специалистов (количество опубликованных объявлений на различных ресурсах)

Рисунок 2 - График востребованности среди разработчиков (в количествах скачиваний с Github за последние два года)



Рисунок 3 - График соотношения репозиториев по количеству звезд

Структура приложения является важной составляющей любого проекта, так как она непосредственно влияет на многие факторы разработки.

К преимуществам структурированного проекта можно отнести следующее:

1) разработчики могут сосредоточиться на создании продукта;

2) общая структура проектов помогает новым специалистам быстро входить в курс дела;

3) люди с меньшим опытом также могут создавать масштабируемые проекты;

4) совместное и повторное использование кода.

К целям введения структуры можно отнести:

1) увеличение производительности за счет четкого поиска файлов в редакторе;

2) естественный процесс перемещения файлов;

3) ненавязчивая и разумная гибкость;

4) структура обязана способствовать масштабируемости и повторному использованию;

5) структурированный код должен быть достаточно прост, с минимальным порогом вхождения.

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

При выборе веб-фреймворка для нового проекта разработчики руководствуются множеством факторов и тонкостями тех или иных фреймворков. Требования проектов, в общем, включают в себя быструю загрузку как разметки, так и контента, удобную навигацию внутри проекта, обработку большого количества данных и проч. Исходя из требований к проекту определяется какого типа будет проект: стандартный многостраничный сайт или одностраничное приложение (SPA)[7], внутри которого необходимо реализовывать маршрутизацию, позволяющую выводить определенные модули по указанному маршруту.

К особенностям SPA можно отнести:

? поддержка клиентской навигации: все перемещения пользователя по модулям-страницам однозначно фиксируются в истории навигации, причем навигация при этом является “глубокой”, то есть если пользователь скопирует и откроет ссылку на внутреннюю модуль-страницу в другом браузере или окне, то он попадет на соответствующую страницу;

? размещение на одной веб-странице: всё необходимое для работы текущей страницы должно быть определено в папке модуля текущей страницы;

? хранение постоянного состояния работы клиента в кэше браузера или в Web Storage;

? загрузка всех скриптов, требующихся для старта приложения при инициализации веб-страницы;

? постепенная подгрузка модулей по требованию.

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

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

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

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

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

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

1. Создание основы приложения;

2. Возможности маршрутизации;

3. Задание и изменение данных внутри отдельного компонента;

4. Передача данных внутри проекта, т.е. между отдельными компонентами;

5. Написание кода компонентов;

6. Процесс рендеринга и методы жизненного цикла компонентов;

7. Миграция между версиями фреймворков.

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

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

1.2 Анализ аналогов

Как было сказано в предыдущем пункте, в популярной в настоящее время области планирования задач и распределения времени существует огромное количество готовых решений от широкого круга разработчиков: как от ведущих ИТ-гигантов типа Google или Yandex, так и от одиночных разработчиков.

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

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

Таблица 1 - Анализ аналогов

Google Календарь	Многофункциональный календарь-планировщик, позволяющий очень подробно распределять время, синхронизирующийся на всех устройствах, поддерживает несколько календарей (например, календарь дней рождений и мои планы). Работает в любом браузере, привязывается к гугл-аккаунту. Поддерживает интеграцию с такими крупными сервисами как amoCRM, Microsoft Outlook. Позволяет делиться своим расписанием, просматривать записи в календарях других людей, если у вас есть право доступа к ним. Есть возможность экспорта и импорта данных с других календарей.
DesktopCal	Маленький календарь с возможностью создания списка задач на определенную дату. Является десктопным приложением для ОС Windows, выводится на рабочий стол в качестве виджета. Есть возможность стилизации элементов. Имеется возможность перемещения данных на другой девайс, печать расписания прямо из приложения. Легкий в настройке и использовании[8].
Todoist	Веб-приложение с приятным интерфейсом. Регистрация быстрая и лёгкая, есть возможность зарегистрировать через соцсети. Возможно создание плана как на определенную дату, так и в общий список дел без привязки к дате. Можно завести несколько календарей разной тематики. В меню есть отдельно выделенный пункт с архивом задач.

1.3 Постановка задачи

Необходимо спроектировать структуру, создать программный продукт “Календарь”, на основе двух различных веб-фреймворков и произвести анализ полученных продуктов на основе разработанного алгоритма их сравнения.

Скорость загрузки ПП должна быть не более 1,5 секунды и данные должны изменяться без перезагрузки страницы. Так как данное приложение рассчитано на пользователей любого уровня - иметь простой, удобный и интуитивно-понятный интерфейс.

К основным функциональным требованиям ПП можно отнести:

1) отображение месяца с днями недели и числами;

2) выбор даты для создания события;

3) создание событий на соответствующую дату;

4) отображение событий соответствующей даты;

5) удаление событий.

К основным эксплуатационным требованиям ПП можно отнести:

1) кроссбраузерность;

2) корректное отображение интерфейса на ПК.

На Рис. 4 представлена диаграмма Use Case, на которой отображено взаимодействие пользователя с приложением.

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

1) просмотр списка событий выбранного месяца;

2) выгрузка событий в .xls формат.



Рисунок 4 - Диаграмма Use Case

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

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

1.4 Планирование разработки

Для выполнения задач проекта следует выбрать модель жизненного цикла, а также модель процесса разработки. Существует четыре модели жизненного цикла программного продукта:

1) каскадная подразумевает линейную последовательность выполнения стадий создания системы. Другими словами, переход с одной стадии на следующую происходит только после того, как будет полностью завершена работа на текущей;

2) инкрементная подразумевает разработку системы с линейной последовательностью стадий, но в несколько инкрементов (версий), т. е. с запланированным улучшением продукта;

3) спиральная подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий;

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

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

Рисунок 5 - Спиральная модель жизненного цикла ПП



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

Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта.

Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.

Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum -- определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint'а.

По окончанию Sprint'а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint'е, спрогнозировать ожидаемую эффективность (производительность) в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое[9].

Схематическое изображение процесса приведено на Рис. 6:



Рисунок 6 - Схема Scrum

В классическом Scrum существует 3 базовых роли:

? Product owner является связующим звеном между командой разработки и заказчиком. Задача PO -- максимальное увеличение ценности разрабатываемого продукта и работы команды;

? Scrum master. Задача Scrum Master -- помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO;

? Команда разработки (Development team) состоит из специалистов, производящих непосредственную работу над производимым продуктом.

В рамках данной работы все три роли пришлось объединить в лице автора. Для построения плана разработки ПП была использована система управления проектами OpenProject. Созданный план описывает планируемые сроки разработки ПП, устанавливает порядок выполнения работ, ответственных за их выполнение и проч. Разработанный план управления проектом представлен на Рис. 7.



Рисунок 7 - План разработки ПП

На основе вышеуказанного плана была сформирована диаграмма Ганта, представленная в двух частях на Рис. 8 и Рис. 9:

Рисунок 8 - Диаграмма Ганта



Рисунок 9 - Диаграмма Ганта

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

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



2. ПРОЕКТИРОВАНИЕ

Проектирование - процесс жизненного цикла программы, во время которого исследуется ее структура и взаимосвязи элементов. Осуществляется проектирование на основе анализа требований к системе.

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

2.1 Выбор фреймворков

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

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

В качестве второго веб-фреймворка был выбран Vue.js, на данный момент менее востребованный на рынке труда, но не менее амбициозный. Начать использование Vue.js большинству веб-разработчиков достаточно просто, что обусловлено высокой популярностью использования в течение достаточно длительного промежутка времени библиотеки JQuery, являющейся, по сути, “синтаксическим сахаром” JavaScript (синтаксические возможности, применение которых не влияет на поведение программы, но делает использование языка более удобным для человека[10]), однако, предоставляющей достаточно широкий спектр возможностей, какие, в общем и целом, предоставляет и Vue.js. Их принцип действия похож, но JQuery работает непосредственно с состояниями DOM-дерева, тогда как Vue.js работает со своими внутренними состояниями.

2.2 Выбор программных средств для разработки

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

IDE (Integrated Development Environment) - интегрированная среда разработки - комплекс программных средств, используемый программистами для разработки программного обеспечения. По сути - редактор, который расширен большим количеством плагинов, умеет работать со вспомогательными системами, такими как багтрекер, контроль версий, и прочие дополнительные возможности.

Как правило, IDE загружает весь проект целиком, поэтому может предоставлять автодополнение по функциям всего проекта, удобную навигацию по его файлам и т.п.

Для разработки веб-приложений на языке JavaScript чаще всего используются такие IDE как WebStorm, Visual Studio, Netbeans. Их популярность обусловлена простотой в освоении, удобством в использовании и огромным инструментарием как непосредственно для разработки, так и для настройки среды под свои эстетические пожелания.

WebStorm и Netbeans являются кроссплатформенными решениями, тогда как Visual Studio нет. Каждая из вышеуказанных сред разработки позволяет непосредственно через её терминал работать с системой контроля версий, что, несомненно, является важным моментом в современной разработке, особенно когда над продуктом трудится команда разработчиков.

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

Для реализации ПП в рамках данной работы в качестве редактора кода была выбрана не среда разработки, а чуть менее функциональный, но более легковесный и быстрый Visual Studio Code, ресурсов которого вполне хватает для полноценной разработки программных продуктов. Он является бесплатным, позволяет работать с системой контроля версий, имеет удобную подсветку кода, навигацию как внутри файла, так и внутри всего проекта, автодополнение в соответствии с выбранным синтаксисом и проч.

В качестве основного веб-браузера для разработки был выбран Google Chrome, так как он является быстрым, современным, поддерживает все современные стандарты веб-разработки. Также к данному браузеру имеются удобные дополнения для разработки и отладки на ReactJS и Vue.js. Помимо основного веб-браузера, в соответствии с требованиями, программный продукт должен корректно работать на других современных браузерах, соответственно, для тестирования приложения применяются также такие браузеры как: Yandex.Браузер, Mozilla Firefox, Microsoft Edge и Opera.

В качестве локального сервера для данного приложения выступает Node.js, так как разработка на основе веб-фреймворков предполагает подключение к проекту различных пакетов (библиотек), которые устанавливаются непосредственно с помощью менеджера пакетов (npm/yarn) Node.js, что позволяет использовать Node.js как в качестве транслятора языка JS, установщика библиотек проекта, так и в качестве локального сервера.

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

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

Подробные анализ и сравнение менеджеров состояний были произведены мною в одном из исследований и представлены в статье “Менеджеры состояний в веб-приложениях”[11]. На основе данного исследования для реализации выбранного приложения решено было использовать библиотеку Redux, так как управление состоянием приложения с помощью стандартного менеджера состояний затруднительно, использование в Redux “чистых” функций исключает появление побочных эффектов и все результаты работы с Redux являются предсказуемыми, широкий функционал для разработчиков позволяет быстро отлавливать ошибки при работе с Redux.

Хранение данных на стороне клиента -- это отличный способ быстро повысить производительность приложения, который заключается в том, чтобы пропустить получение информации от сервера каждый раз, когда пользователь нуждается в ней. Хранение на стороне клиента может быть организовано с использованием cookies, Local Storage (технически “Web Storage”), IndexedDB и WebSQL.

В качестве хранилища данных разрабатываемого ПП используется localStorage.

LocalStorage нужен только для одного -- хранить определенные данные пользователя. LocalStorage - это свойство глобального объекта браузера (window), которое позволяет браузеру сохранять данные пользователя прямо в браузере, при этом при последующих входах на доменный адрес веб-приложения localStorage не очищается, а сохраняет все внесенные в него данные. Привязывается localStorage к доменному адресу. Это особенно полезно в офлайн-режиме, но даже для онлайн-пользователей будет польза от использования данных локально в противовес удалённому серверу.

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

2.3 Проектирование архитектуры приложения

В начале своей истории все программы строились без каких-либо архитектурных принципов, программа состояла из множества следующих друг за другом строк: без классовых зависимостей, наследований и других современных возможностей языков программирования. Однако, стремление к упрощению разработки, а также к структуризации как кода, так и всего приложения могло являться предпосылкой к появлению такого понятия как «архитектура ПО».

Существует три подхода к архитектурному проектированию веб-приложений:

1) монолитный подход;

2) модульный подход;

3) SOA или Сервис-ориентированный подход.

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

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

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

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

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

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

В общем, схему модульной архитектуры для стандартного веб-приложения можно представить на Рис. 10:



Рисунок 10 - Модульная архитектура веб-приложения

В представленной на Рис. 10 схеме, в рамках диссертационной работы, исследуется модуль FrontEnd, который как сказано выше, разрабатывается на основе компонентного подхода, из чего следует необходимость создания схемы, отображающей компоненты клиентской части приложения. Компоненты, по сути, аналогичны функциям JavaScript, они хранят состояние с помощью свойств и возвращают элементы, которые затем появляются на странице. Преимуществами компонентов является то, что их проще обновлять и использовать повторно, также между ними есть возможность удобно и практично наладить взаимоотношения через “стейты”, т. е. с помощью внутренних возможностей React или Vue.js. Схема компонентов приложения представлена на Рис. 11:



Рисунок 11 - Схема компонентов приложения

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

Каждый разработчик при проектировании клиентской части приложения сталкивается с задачей разработки его структуры, ведь когда над продуктом работает не один создатель, то файловая структура определяет львиную долю скорости разработки[13].

Разрабатываемые на HTML, CSS и JQuery простейшие веб-сайты обычно имеют линейную структуру: одна страница ссылается на следующую и так далее, соответственно и иерархия файлов таких сайтов будет представлять собой html-файлы отдельных страниц, стилевые, скриптовые и прочие файлы в соответствующих папках. Для примера такая структура проекта представлена на Рис. 12:

Рисунок 12 - Пример файловой структуры простого веб-сайта

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

Данные компоненты могут формировать более крупные компоненты и переиспользоваться.

Строить структуру приложения можно различными способами, например:

1. Выделять отдельные папки для каждой страницы и хранить все используемые элементы внутри них:

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

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

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

3. Выделять отдельные папки для каждой страницы и хранить внутри них все, кроме мультимедийных файлов и элементов управления состоянием дополнительной библиотеки (по аналогии с п. 2).

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

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

В данной диссертационной работе была разработана файловая структура, описанная следующим образом:

1. На первом уровне корневого каталога находятся папки public и src. В папке public хранятся все статические мультимедийные файлы. В папке src находятся все файлы, содержащие код.

2. Внутри папки src производится разбиение на следующие директории:

a. папки с файлами для работы с REST API;

b. папки с файлами многократно переиспользуемых внутри всего проекта компонентов;

c. папки с файлами многократно переиспользуемых внутри всего проекта вспомогательных функций;

d. папки с модулями, представляющими собой набор внутренних компонентов отдельных страниц.

3. Внутри папки-модуля располагается корневой файл модуля, файл с маршрутами внутри него (в случае разработки SPA) и папки отдельных компонентов, разбитых в соответствии с атомарным дизайном (это система маленьких элементов? - атомов, которые можно использовать повторно и комбинировать друг с другом)[14]:

a. в папке atoms находятся самые мелкие компоненты модуля, такие, например, как кнопки, чекбоксы, тугглы и проч;

b. в папке molecules находятся некрупные используемые неоднократно в рамках модуля компоненты, составленные из атомов;

c. в папке organisms находятся более крупные, чем в molecules используемые неоднократно в рамках модуля компоненты, составленные из молекул и атомов;

d. в папке templates находятся полноценные крупные компоненты, состоящие из атомов, молекул и организмов, отвечающие за отображение страницы по текущему маршруту;

e. в папке pages находятся компоненты, вызывающие соответствующие им темплейты и передающие в них данные.

Пример предложенной структуры приложения представлен на Рис. 13:

Рисунок 13 - Разработанная структура приложения на примере отдельных папок

Для каждого компонента создается собственная папка, содержащая файл с кодом компонента, именуемом в camelCase и стилевой файл компонента.

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

2.4 Проектирование пользовательского интерфейса

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

1) он должен быть узнаваемым, а его назначение? ?очевидным для пользователя;

2) люди должны понимать, с чем они взаимодействуют через интерфейс;

3) процесс взаимодействия с интерфейсом должен быть предсказуемым.

Ясность рождает в пользователях уверенность и готовность продолжать работу с интерфейсом[15].

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

Рисунок 14 - Интерфейс главного экрана

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

Рисунок 15 - Окно добавления события при клике на дату

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

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

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



3. РЕАЛИЗАЦИЯ И ТЕСТИРОВАНИЕ

Данный программный продукт имеет небольшой функционал по планированию событий на выбранные даты, в интерфейсе отображен непосредственно календарь со всеми днями текущего месяца. Основной функцией приложения является создание события и привязка его к выбранной дате, также в указанном программном продукте реализована возможность просмотра списка событий, привязанных к определенной дате, а также удаление их из списка. Работу веб-приложения, разрабатываемого в рамках диссертации, можно описать с помощью блок-схемы, представленной на Рис. 16:

Рисунок 16 - Блок-схема работы ПП

Программный продукт разрабатывается на фреймворках React и Vue.js.

Разработка приложения начинается с его создания. Для создания React приложения можно создать папку с проектом, установить туда React, добавить систему сборки, транспилятор и вручную прописать настройки проекта, или же воспользоваться утилитой CLI (интерфейс командной строки[16]) - Create React App (CRA).

Create React App -- отличный инструмент для быстрого старта React-приложений, так как разработчику не нужно тратить время на настройку системы сборки (Webpack), транспилятора не везде поддерживаемого синтаксиса ES6 в ES5 (Babel) и других привычных инструментов. Они заранее настроены и спрятаны, так что разработчики могут сфокусироваться на коде и бизнес-логике приложения.

Для создания приложения на React необходимо лишь установить Node.js с менеджером пакетов (npm или yarn, в данной работе - npm[17]). С помощью менеджера пакетов установить пакет create-react-app, создать свой проект, установить дополнительные библиотеки и зависимости. Временные затраты при использовании create-react-app минимальны, обновление версий пакетов производится в автоматическом режиме после подтверждения установки разработчиком, тогда как при ручном создании проекта все обновления и настройки придётся проверять и изменять вручную.

Код создания приложения на React:

npm install -g create-react-app

create-react-app react-calendar

cd react-calendar/

npm start

Создание проекта на Vue.js, по сути, ничем не отличается от создания проекта на React, только утилита CLI называется vue create. Таким же образом устанавливаются система сборки, после чего предлагается установка стандартного пресета (включающего линтер[18] и транспилятор) или ручная настройка инструментов разработки, и код выглядит следующим образом:

...