42
ГЛАВА 3. РАЗРАБОТКА ПРИЛОЖЕНИЯ
3.1. Выбор технологий
Перед началом работы над приложением необходимо было выбрать
технологии, которыми мы будем пользоваться при разработке. В первую
очередь необходимо было определить требования, которыми они должны
соответствовать.
3.1.1. Клиентская часть
Геймифицированная система управления разработкой – это
приложение, где пользователи регулярно просматривают Kanban, свои
задачи, открывают подробности. Предполагается использование
всплывающих окон для уведомлений пользователя об успехе совершенных
им действий, открытии конкретной задачи для быстрого редактирования и
т.д. Такого рода приложения известны в среде веб-разработки как Single
Page Applications, или, сокращённо, SPA. Поэтому для пользовательских
интерфейсов нам нужно было подобрать один из существующих
фреймворков, например Angular, React, Vue. Все эти фреймворки написаны
для упрощения работы с языком программирования ECMAscript, и именно
с ним мы будем работать на клиентской части, так как на сегодняшний
день широко поддерживаемых браузерами альтернатив в мире нет.
Во время обучения в МТИ магистрант проходил производственную
практику, в которой изучил и попробовал на практике пять современных
фреймворков: Angular.jsm Angular 2, React, Vue и Aurelia. Кроме того, во
время учебной практики у магистранта была возможность освоить
Backbone.js. Приобретённый опыт позволил магистранту принять решение
об использовании на клиентской стороне фреймворка Vue.js, который
показывает высокую скорость обработки данных и имеет самую
быстрорастущее профессиональное сообщество.
43
3.1.2. Серверная часть
В каждой конкретной команде разработки, бывает небольшое
количество участников (5-30 человек), поэтому не требуется уделять много
внимания проблемам высоконагруженности систем, поэтому можно
использовать не многопоточный язык программирования, а ограничиться
более простым и удобным для разработки языком, например node.js,
имеющий асинхронный принцип выполнения задач.
Для хранения данных была взята система управления базами данных
MongoDB. Эта система реализует новый подход к построению баз данных,
где не используются таблицы, схемы, запросы SQL и многие другие вещи,
обязательные для объектно-реляционных баз данных. MongoDB
предлагает документо-ориентированную модель данных, благодаря чему
работает быстрее, лучше масштабируется, и ее легче использовать.
3.2. Установка зависимостей
Для начала работы нам потребовалось установить ряд зависимостей,
с помощью которых мы могли начать создавать первые работающие
прототипы приложения, свои для клиентской и серверной стороны.
3.2.1. Зависимости серверной стороны
В первую очередь мы поставили пакет express, который позволяет
упростить работу по развёртыванию серверной части, уменьшает
количество строк кода и позволяет выполнять встроенные функции.
Вторым важным моментом была настройка работы с базой данных.
Для этого используется пакет Mongoose, напрямую работающий с
MongoDB, а также nodemon, с помощью которого мы можем отправлять
запросы к базе данных. Автоматически в наш файл настроек был добавлен
пакет morgan, необходимый для корректной работы с MongoDB.
44
Для запуска серверной стороны в процессе локальной разработки
нашего приложения, помимо зависимостей, нам нужно было настроить
файл server.js, в котором мы обозначали порт, который будет «слушать»
наш сервер. Сделав импорт пакетов ‘http’ и ‘morgan’ мы определили порт
среды, const port = process.env.PORT, либо, если доступа к нему нет, 3000.
В пакете http существует простой метод разворачивания сервера, и
занимающий одну строку, createServer, после чего последней строкой
файла начинается «слушание».
Отдельно рассмотрим ключевой на серверной стороне файл app.js, с
помощью которого создается server. В нём происходит подключение к
системе управления базами данных MongoDB. Сделано это с помощью
метода connect() библиотеки mongoose.
Рис. 3.1 Схема запуска сервера
Затем определяется, как обрабатываются входящие запросы: для
этого указаются заголовки, или headers. В первую очередь нужно
определить, какие методы мы будем рассматривать как заслуживающие
доверия, чтобы программа не отвергла их как подозрительные. В нашем
случае это стали 'OPTIONS', 'DELETE', 'PUT', 'POST', 'PATCH', 'GET'.
45
Кроме методов, обозначены доступные заголовки, приходящие с клиента:
'Origin, X-Requested-With, Content-type, Accept, X-Access-Token, X-Key, Z-
Key'. Также определено, что к ресурсам приложения могут обращаться
любые домены. Это не совсем правильно с точки зрения безопасности, но
на время разработки такое решение вполне допустимо. Это указывается
через res.header('Access-Control-Allow-Origin', '*').
Последней строкой файла настройки экспортируются, чтобы их
могли использовать другие файлы, как server.js, который на основе этих
настроек создал работающий сервер, как это и показано на рисунке 3.1.
3.2.2. Зависимости клиентской стороны
Для пользовательского интерфейса потребовалось намного больше
пакетов даже на самом первом этапе разработки. Для production-версии
устанавливаются vue, vue-router, vue-style-loader. Первый – это собственно
минимальный набор для работы с фреймворком, второй нужен для
реализации SPA-принципа, при котором можно настраивать различные
пути, которые создают для пользователя иллюзию работы с одной
страницей, при этом позволяя клиенту широко декомпозировать систему, а
также хранить все пути, по которым проходил пользователь, в истории
браузера. Третий пакет необходим для стилизации приложения и
корректной подгрузки различного формата файлов стилей.
Для удобной и корректной разработки приложения мы поставили
множество дополнительных пакетов:
axios, использующийся для быстрой работы с запросами на
сервер и обработки поступающих обратно ответов или ошибок.
autoprefixer, добавляющий префиксы для сложных css-стилей,
необходимых для работы в разных браузерах;
46
babel, состоящий из семи дополняющих корневой пакетов,
который требуется нам для использования современных
методов и нововведений ES6 и ES7;
eslint, состоящий из девяти пакетов, необходимый для тонкой
настройки требований к написанию кода в приложении и не
позволяющий сделать готовую сборку, если в написанном коде
будут найдены несоответствия;
webpack, который требуется vue,js, чтобы корректно собрать
приложения, что подробно описано ниже.
Помимо вышеозначенных, мы добавили ещё несколько
малозначимых пакетов, которые либо нужны для корректной работы
ключевых пакетов, либо являются дополнениями.
Для пользовательского интерфейса мы также создали два ключевых
файла: app.vue и main.js. Первый – это основной компонент приложения,
который представляет собой фундамент для надстройки на нём общих для
всего приложения вещей как меню и рабочей области. В нём, как и во всех
компонентах Vue, используются две части: представление, описанное
языком разметки HTML, и логика работы взаимодействия с пользователем.
Туда импортируются иные компоненты, например, меню или уведомления.
Файл main.js конфигурационный. В нём производится настройка
Vue-приложения: указывается необходимость использования библиотеки
axios, VueAxios и Vuetify – библиотеки компонентом для material-дизайна.
Туда же импортируется router, где описаны пути приложения, по которым
ходит пользователь, и store, хранящий состояние всех данных. Всё это
позволяет создать Vue-приложение командой new Vue({}), где
определяется Html-элемент, внутри которого будет развёрнут SPA,
добавляется ссылка на App.js как на основной компонент, указывается
47
название элемента, которым он будет представлен, внедряется router и
store. На этом настройка клиентской части была закончена, и осталось
только локально развернуть проект для наблюдения за разработкой.
Для этого используется пакет webpack: в файл webpack.config.js
обозначены два вида развертывания: build и dev. Для разработки нужен
dev. В нём указывается необходимость использования всех файлов с
расширением vue, js, а также картинок (jpg, svg…). Все обработанные
файлы складываются в папку dist в файл build.js. Наконец, в основном
конфигурационном файле package.js обозначается главная команда ‘npm
dev’, нужная для развертывания. Так, при запуске для мануального
тестирования указывается источником материала файл, собранный и
минифицированный сборщиком проектов, который получал основу
приложения из main.js, выдающий первый и главный компонент App.vue.
Рис. 3.2 Схема запуска пользовательского интерфейса
48
После выполнения этой команды приложение готово к работе и с
ним уже можно начинать работу на определённом конфигуратором адресе.
3.3. Создание клиентской части приложения
3.3.1. Подключение Vuex
Для полноценной работы с клиентской частью приложения решено
было подключить специальную библиотеку для приложения на Vue.js –
Vuex, с которой работа с данными становится наглядной. Этот паттерн
управления состоянием используется как центральное хранилище данных
для всех компонентов приложения, и с его помощью обеспечивается
предсказуемость изменения данных через определённые правила. Vuex
интегрируется с расширением инструментов разработчика Vue,
предоставляя такие возможности, как пошаговое рассмотрение событий в
каждый конкретный момент времени работы приложения при отладке.
Любое, даже самое простое приложение на Vue.js, состоит всегда из
состояния, представления и действий: data, template и methods. Состояние –
это набор данных, управляющих приложением; представление –
декларативно заданное отображение состояния, обычно в html-разметке;
действия – возможные пути изменения состояния приложения в ответ на
взаимодействие пользователя с представлением.
Разрабатывая сложное приложение на Vue.js, сложно не запутаться в
потоках данных: если несколько представлений имеют зависимость от
одной и той же части состояния или если действия из разных
представлений влияют на одни и те же участки состояния. Тогда нужно
выносить общее состояние приложения из компонентов в глобальный
синглтон, что превратит дерево компонентов в большое представление, и
любой компонент получает доступ к этому состоянию данных.
49
Рис 3.3 Схема взаимодействий Vuex в приложении
На схеме выше представлено, каким образом Vuex улучшает
взаимодействие всех участков приложения. Пример: пользователь нажал
на кнопку, что вызывает метод dispatch, запускающий action и обращание к
серверу. После получения ответа приложение делает поручение (commit)
на мутацию состояния, после которого происходит перерендеринг всех
компонентов, зависящих от этих данных. Actions, mutations и state – это те
неотъемлемые части vuex, которые составляют его основу.
В дальнейшем, работая с нашим приложением, мы будем основывать
разработку клиентской части приложения именно на этом принципе.
Для оптимизации процесса поиска и исправления ошибок в
приложении мы подключили к нашему браузеру специальное расширение
под названием “Vue.js devtools”, которое позволяет в режиме перемотки
времени видеть, в каком виде находилось состояние приложение в тот или
иной момент времени. Таким образом очень легко становится определить
проблемный участок и внести в нём исправления.
50
3.3.1. Создание системы роутинга
Так как в приложении не требуется большого количества различных
путей, ему не требуется создание многоуровневых или зависимых друг от
друга путей, и синтаксис настройки роутинга ограничивается созданием
нескольких объектов, каждый со свойствами ‘path’, ‘name’и ‘component’. В
свойстве path мы прописываем url-путь, который будет сохранён в истории
браузера пользователя и виден в адресной строке; name – название пути
для использования внутри нашего кода, а component – это ссылка на
компонент приложения, куда будет переведён пользователь при
определённых условиях. Чтобы роутинг работал, нужно каждый
компонент импортировать из соответствующего файла.
Синтаксис Vue.js позволяет делать пути, зависимые от выбранных
пользователем элементов. К примеру, если пользователю нужно будет
открыть подробности определённой задачи, то в конфигурации роутинга
это будет выглядеть как ‘/tasks/:id’. Свойство id, идущее после двоеточия,
означает, что при переходе на этот роут мы должны определить
идентификатор конкретной задачи, которая и будет показана
пользователю. По тому же принципу можно передать множество свойств,
ограниченных лишь длиной адресной строки, и все свойства могут быть
использованы компонентом как параметры объекта ‘this.$route.params’.
Наконец, в нужных местах приложения помещаются переходы по
сконфигурированным путям. Это делается двумя способами:
1. Внутри представления, обозначая специальный атрибут для тех
или иных html-компонентов, если нам требуется мгновенный
переход на новое представление сразу после нажатия ссылки.
2. Внутри действий, во время выполнения какой-то функции.
Например, если пользователь отредактировал какую-то задачу и
51
нажал кнопку «Сохранить», нужно дождаться ответа от сервера,
после чего уже возвращать пользователя обратно на список задач.
И в том, и в другом случае для перехода на новый роут мы
используем ключевое свойство path, о котором мы говорили чуть выше. С
его помощью приложение понимает, куда нужно перевести пользователя.
Рис. 3.4 Варианты возможных действий для перехода по роутам
Как уже обозначено выше, для подключения роутера в приложение
нужно импортировать его в файле main.js и добавить его в качестве
свойства router нового объекта класса Vue. Для этого он экспортируется
командой export default new Router({}), где внутри объекта указывается ряд
свойств-объектов наших путей.
3.3.2. Регистрация пользователей
После определения основных законов, по которым будем строится
приложение, нужно переходить к непосредственно воплощению
геймифицированной системы управления разработкой.
Как и работа пользователя с приложением, так и его разработка
начинается с регистрации пользователя. Планируется широкое