Подход к разработке корпоративных систем

1.Вступление

В этой статье мы рассмотрим наш подход в области Front-End разработки программных продуктов.

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

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

Взаимодействие нескольких клиентских (Front-End) частей и серверной (Back-End) части должно быть четко организовано, на их слаженную работу будет влиять грамотно продуманная архитектура системы. Над этой задачей трудится вся команда разработчиков.

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

2.Техническое задание

Первое и основное, от чего будут отталкиваться все те, кто участвует в разработке ПО (аналитики, разработчики и тестировщики) - это грамотно составленное техническое задание.

Можно разобрать понятие “Техническое задание” по критериям авторства и по уровню детализации описываемых задач:

• Первичный документ – поступает к нам от заказчика. Это может быть глубоко проработанное специалистами IT-подразделения заказчика Техническое задание. А может представлять собой простой перечень функциональных требований от будущих пользователей программного продукта.
• Вторичный документ– детализированное техническое предложение. Разрабатывается аналитиком проекта на основе первичного документа. Оно гораздо более подробное, может содержать внутреннюю терминологию, отходить от общепринятых стандартов.

  В нем должно быть описано все задуманное:

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

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

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

3.Проектирование дизайна

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

Онлайн-сервис Figma (Фигма) популярен среди дизайнеров и разработчиков web-студий. Программа имеет невысокие требования к подготовке пользователей, с ним относительно несложно работать, но при этом он отличается большим функциональным наполнением. Также у Figma есть не только онлайн-режим, но и десктопная версия, которая является кроссплатформенной и малотребовательна к системным ресурсам.

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

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

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

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

3.1.Адаптивный дизайн

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

Если не позаботиться об адаптивности дизайна, то на другом устройстве важные элементы будут скрываться, могут ‘съезжать’, отображаться не правильно. А страницу с большим количеством информации просто невозможно будет прочитать.

Figma позволяет делать дизайн адаптивным несколькими разными способами:

• Во-первых, можно воспользоваться имеющимися заготовками различных фреймов. Что позволяет ‘примерять’ дизайн к самым распространенным экранным разрешениям. В общем случае дизайнер должен отработать три интерфейса – для персонального компьютера, для планшета и для смартфона.
  
• Во-вторых, обязательно нужно учитывать, что мобильные устройства имеют два вида ориентации – вертикальную и горизонтальную. В простых случаях, достаточно использовать только два фрейма необходимого размера, только разной ориентации.
• Модульная сетка используется, чтобы адаптировать макет к определенному окну просмотра. Элементы макета ‘привязываются’ к модульной сетке. При сдвижении-раздвижении окна просмотра они остаются на своих местах до очередной контрольной точки (или точки останова).
  
• Контрольные точки (или точки останова). По умолчанию используется шесть стандартных контрольных точек:
  
  

  При сдвижении-раздвижении окна просмотра, как только экран достигает определенной точки останова – меняется структура и расположение элементов на странице.

3.2.Мокапы разных устройств

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

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

3.3.Полезные мелочи

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

• Желательно сразу найти или сгенерировать иконки и иллюстрации, которые войдут в библиотеку иконок приложения. Figma дает возможность работать не только с растровой, но и с векторной графикой. Можно установить плагины, которые позволят генерировать иконки или экспортировать их в любых размерах и форматах.
  
• Важно использовать названия элементов графического дизайна (макетов, кнопок, иконок, таблиц и т.д.), которые будут не только понятны всей команде разработки данного продукта, но и будут использоваться непосредственно в коде. К примеру, параметры макетов для ввода данных рекомендуется называть так же, как и в соответствующих запросах/процедурах, описывающих работу этих макетов.
• Необходимо присваивать экранам последовательную нумерацию в таком порядке, как они описаны в технической документации к проекту.
• Использовать в дизайне только те шрифты, которые хорошо читаются на различных устройствах. Чтобы пользователи приложения одинаково комфортно видели информацию, как на большом экране компьютера, так и на экране небольшого смартфона.

4.Техническая документация

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

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

Рассмотрим некоторые их них:

4.1.User flow diagram

В процессе разработки, еще до начала разработки графического дизайна, аналитиком или менеджером проекта должен быть продуман User flow diagram. Переводится как “путь (поток) пользователя” или “Диаграмма пользовательского пути”. По сути - это наглядное представление “пути пользователя”, его последовательное движение из начальной точки входа ПО в конечную точку выхода из него.

User flow diagram представляет из себя блок-схемы переходов (условий переходов) с экрана на экран, а также движение по смысловым этапам. То, что было концептуально описано в техническом задании, должно быть переведено на пошаговый сценарий, который пользователь проходит по цифровому продукту.

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

4.2.Style Guide или Руководство по стилю

Написание данного руководства – обязательная часть процесса разработки дизайна.

По сути это набор требований к стилю, который будет использован в данном программном продукте:

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

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

4.3.Руководство по прототипированию

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

Здесь можно воспроизводить работу с интерфейсом:

• переходить с экрана на экран,
• нажимать кнопки,
• двигать элементы на экране и пр.

После прорисовки всех действий на всех экранах, разобраться в множестве переходов довольно сложно.

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

В данном руководстве должны быть описаны:

• Фрейм - на каком экране (фрейме) происходит описываемое событие.
• Элемент интерфейса – на что нужно нажать или произвести любое другое воздействие, при котором происходит некое событие. Это может быть кнопка, позиция списка или любой другой элемент на экране.
• Триггеры– какое воздействие на элемент интерфейса нужно произвести, чтобы произошло связанное с ним событие. В качестве триггера можно привести следующие примеры:
  • On Click/On Tap – клик мышкой/нажатие пальцем на сенсорных экранах.
  • On Drag – перетаскивание элемента с помощью зажатой кнопки мыши или пальцем на сенсорных экранах.
  • While Hovering – при наведении.
  • Keyboard and Gamepad Shortcuts – при нажатии на клавиатуре.
  • Mouse enter – курсор мыши наведен на определенную область.
  • Mouse Leave – курсор мыши покидает определенную область.
  • и т.д.
• Условие перехода – при каком условии выполняется описанное действие. Это условие нельзя описать в графическом редакторе, только если добавить комментарий к элементу.
• Действие– что именно должно произойти, какое событие. В качестве одного из возможных вариантов событий можно наcтроить:
  • Instant – без анимации, мгновенное отображение.
  • Move In / Move Out – фрейм будет плавно выезжать поверх исходного.
  • Open Overlay – отображение всплывающих окон.
  • Close Overlay – закрыть всплывающее окно.
  • Navigate – навигация от одного фрейма к другому.
  • Open URL – открыть страницу по ссылке URL.
  • и т.д.
• Действие (сервисы) – описание запросов или процедур, которые должны вызываться в данный момент. Здесь могут быть описаны примеры вызовов процедур.
• Переход на фрейм – на какой экран должен произойти переход.

Руководство по прототипированию (описание работы с фреймами) является связующим звеном между проектированием интерфейса в графическом редакторе и написанием кода Front-End-разработчиками.

Все возможные примеры запросов/ответов веб-сервисов, которые понадобятся Front-End-разработчикам, должны быть собраны в отдельном документе.

5.Разработка Front-End

5.1.Программные инструменты

Для разработки клиентской части понадобятся такие инструменты, как:

1. Язык гипертекстовой разметки HTML — позволяет наполнить страницу содержанием, расположить данные в заданных частях страницы, упорядочить их.
2. Инструментарий CSS – позволяет красиво оформить HTML-страницу, задает описание стилей.
3. Язык программирования JavaScript — позволяет использовать интерактивные элементы дизайна, описывает логику действий.
4. Фреймворки CSS и JS – программные платформы и библиотеки, упрощают написание кода за счет готовых решений.
5. Контроль версий GitHub/GitLab– система контроля версий используется для хранения версий и взаимодействия с другими разработчиками.

5.2.Фреймворки и библиотеки

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

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

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

Условно различают CSS-фреймворки и JS-фреймворки:

• CSS-фреймворки созданы для упрощения и ускорения работы верстальщика. Это целый комплекс готовых элементов дизайна и интерактивных компонентов, наборов правил, которые можно использовать для создания web-интерфейсов.

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

  Среди самых известных можно перечислить:

  1. Bootstrap (от разработчиков Twitter),
  2. Foundation,
  3. Materialize,
  4. Bulma,
  5. Tailwind CSS,
  6. CSS-framework.
• Фреймворки и библиотеки JavaScript. Созданы на языке программирования JavaScript, который широко используется для разработки клиентской (Front-End) и реже для серверной (Back-End) частей.

  Используются для придания динамики пользовательскому интерфейсу, делает web сайт ‘живым’, отзывчивым на действия пользователей.

  Позволяют FrontEnd-разработчикам использовать готовые анимированные компоненты, такие как: открывание пользовательского меню, вызов всплывающих окон, перелистывание карточек, динамическое обновление данных и прочее.

  Наиболее популярными являются:

  1. React – библиотека Front-End от Facebook,
  2. Vue.js – Front-End фреймворк,
  3. Angular – Front-End фреймворк от Google,
  4. Svelte – фреймворк,
  5. jQuery – библиотека JavaScript (считается уже устаревшей),
  6. Web Components – фреймворк от GitHub.

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

Важными критериями выбора будут:

• Требования к проекту – что лучше подходит для решения задач данного проекта, насколько проект масштабен и сложен.
• Функциональность фреймворка, наличие полноценной документации и поддержки со стороны сообщества.
• Насколько просто можно найти разработчиков. Чем более популярен фреймворк, тем проще будет собрать команду на разработку.
• Как быстро можно обучить разработчиков. Порог входа может сильно разниться. Некоторые являются довольно простыми для ознакомления и использования, а некоторые имеют высокий порог входа и требуют имеющихся навыков.
• Фреймворки также обладают разной производительностью, что может быть важным показателем при определенных задачах проекта.
• Также заказчик может предъявить свои требования к фреймворку, если у него уже есть своя команда на поддержку.

5.3.Фреймворк Bootstrap

На этапе создания Front-End интерфейсов мы используем фреймворк Bootstrap. По сути это библиотека CSS и JavaScript файлов, разработанная специально для упрощения процесса верстки.

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

Состоит из таких полезных компонентов как:

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

Фреймворк Bootstrap имеет открытый исходный код, а это значит, что его можно использовать под свои задачи и частично переработать.

6.Заключение

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

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

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

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

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