Введение
В больших командах разработки, где требуется обеспечивать чистоту и понятность кода и поддерживать масштабируемую архитектуру приложений [8], широко распространена практика проверки кода (Code Review). Проверка кода происходит после того, как какой-либо функционал разработан и протестирован, и позволяет на ранних стадиях выявить скрытые проблемы в реализации, уменьшить вероятность архитектурных ошибок и возможных проблем с производительностью при масштабировании системы. Кроме того, проверка кода помогает распространять опыт и знания среди членов команды, повышая общий уровень профессионализма в команде [2].
Однако, несмотря на пользу проверки кода, при неумелом подходе и неправильном выборе регламента она может стать узким местом в процессе разработки программного обеспечения. В компании «6th Grain», которая занимается разработкой веб-приложений, при анализе времени, потраченного разработчиками компании, было выявлено, что в среднем проверка кода занимает около 30% от общего количества. Таким образом, вместе с тестированием, проверка занимает столько же времени, сколько и разработка (около 50%). Данные получены в рамках внутреннего исследования в компании, основываясь на эмпирических данных и аналитике в системе управления задачами Jira, которая оценивает время нахождения той или иной задачи в каждом из состояний.
Учитывая высокую стоимость трудового времени разработчика, сокращение времени разработки напрямую ведёт к уменьшению затрат компании. Поскольку сложилась ситуация, в которой ПО создаётся быстрее, чем проверяется, было принято решение оптимизировать рабочие процессы, в частности - проверку кода. Главной точкой для оптимизации является автоматизация данного процесса, поскольку наиболее критические задержки вызваны человеческими ошибками, например, при назначении ответственных, при формировании карты ответственности или пропущенных файлах при проверке.
Объект исследования -- разработка ПО в компании «6th Grain».
Предмет исследования -- оптимизация процесса проверки кода.
Цель работы -- разработать сервис для оптимизации процесса проверки кода в компании «6th Grain».
Для достижения целей будет решен ряд следующих задач:
1. Проанализировать текущий процесс проверки кода.
2. Построить TO-BE модель процесса проверки кода.
3. Спроектировать сервис для автоматизации процесса проверки кода.
4. Разработать сервис для автоматизации процесса проверки кода.
Исследовательская деятельность направлена на анализ текущего процесса проверки кода, выявления его слабых мест и точек автоматизации, сравнения возможных решений для автоматизации проверки кода. Результатом исследования будет являться сервис для автоматизации процесса проверки кода, реализованный в соответствии с оптимизированной моделью процесса.
Во время исследования был проведён сбор и анализ эмпирических данных, рассмотрена профессиональная литература, посвящённая лучшим практикам в управлении процессом разработки. Также, с помощью нотации BPMN описаны AS-IS и TO-BE модели процесса проверки кода. В процессе проектирования приложения диаграммы последовательностей и классов построены используя средства UML.
Работа состоит из трёх глав, описывающих: анализ модели процесса проверки и сравнение решений для автоматизации этого процесса; проектирование и разработку сервиса для автоматизации.
1. Анализ процесса проверки кода
Для разработки сервиса автоматизации процесса проверки кода требуется, в первую очередь, проанализировать процесс разработки ПО в компании «6th Grain». В рамках данной главы анализируется процесс проверки кода и исследуется ИТ-инфраструктура предприятия. На основании полученных данных строится модель TO-BE процесса проверки кода и формируются требования к средству автоматизации, реализующему эту модель. Согласно требованиям, проводится сравнение существующих решений и собственного сервиса.
Анализ ИТ-инфраструктуры предприятия.
Общие сведения о предприятии.
Фирма «6th Grain» является международной компанией, предоставляющей услуги по оцифровке сельскохозяйственных полей. Предприятие специализируется на преобразовании данных, предоставленных фермером, в информацию, которая может быть использована для увеличения успеха и использования в предоставлении кредитов, высокопродуктивных семян, удобрений, фунгицидов и других услуг по защите растений. Головной офис предприятия расположен в Сингапуре, а подразделения расположены по миру: отдел исследований в США, отдел анализа данных в Индии и отдел разработки в России. Организационная структура предприятия отражена на рисунке 1.1.
Рисунок 1.1. Организационная структура предприятия
В рамках данной работы рассматриваются процессы, происходящие в отделе разработки, который состоит из менеджера проекта, ведущего разработчика, трёх старших разработчиков, шести рядовых разработчиков и трёх тестировщиков. Программисты также имеют различные области экспертизы, они пишут на различных языках и работают с различными платформами. Структура отдела разработки представлена на рисунке 1.2. Данная иерархия является условной, поскольку в команде применяются гибкие методологии разработки и динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп (Agile), где сотрудники в относительно равной степени участвуют в принятии решений [1].
Рисунок 1.2. Организационная структура отдела разработки
Описание используемых средств разработки ПО.
В отделе разработки используется стандартный для ИТ подразделения набор ПО: система управления задачами, система контроля версий и корпоративный мессенджер. Задачи и их состояние управляются с помощью Atlassian Jira Cloud (далее - Jira), который частично интегрирован с хранилищем исходного кода Atlassian BitBucket Cloud (далее - BitBucket) посредством внутренней шины сообщений Atlassian Connect. Интеграция между Jira и BitBucket информационно-справочная: задачи связаны посредством идентификационного номера с соответствующими ветками и запросами на включения изменений в BitBucket, обеспечивающая навигацию между двумя системами.
Atlassian также предоставляет интерфейсы для подключения сторонних приложений. В компании в качестве корпоративного мессенджера используется Slack. Slack - это облачный набор собственных инструментов и сервисов для совместной работы и коммуникации, обеспечивающий создание ботов и каналов. Так, Atlassian предоставляет доступ к jirabot и bitbucketbot, которые оповещают с помощью Slack об изменении статуса задач из Jira и сообщения о слияниях веток в основную (merge) из BitBucket.
Кроме использования готовых интеграций, BitBucket и Jira предоставляют точки подключения (API) для разработки собственных сервисов для взаимодействия с системами и создания собственных способов интеграции. Используемые технические средства представлены на рисунке ниже.
Рисунок 1.3. Технологическая среда предприятия
Анализ AS-IS модели процесса проверки кода.
Описание текущего процесса проверки кода.
С момента основания компании в процессе разработки применяется практика проверки кода (Code Review). Проверка кода происходит после того, как функционал задачи разработан и протестирован и осуществляется для выявления скрытых недостатков реализации и возможных архитектурных проблем, которые будут тормозить развитие приложения в будущем [2]. Полный сценарий разработки задачи представлен в Приложении А.
В целом, сценарий можно считать стандартным для компаний, занимающихся разработкой программного обеспечения [1]. Однако, несмотря на то, что процесс достаточно простой, при детальном рассмотрении этапов проверки кода видны недостатки текущей реализации. Подробная диаграмма проверки кода представлена в Приложении B.
Когда задача поступает на проверку кода, разработчик сверяет список изменённых файлов с картой ответственности и назначает проверяющих в BitBucket. Трудоемкость данного этапа пропорциональна количеству файлов, и может занимать от минуты до часа [3]. Далее, разработчик уведомляет о готовности задачи к проверке менеджера проекта. Тот, в свою очередь, назначает в Jira задачи на проверку кода для необходимых проверяющих. После того, как задача поступает проверяющему, тот в свою очередь также должен сопоставить список изменённых файлов с собственной зоной ответственности и перевести задачу на проверку в статус «В работе». Далее, если в результате проверки появляются замечания, исходная задача переводится в статус «Сделать», а задача на проверку - в отложенные. Если замечаний нет, то задача на проверку переводится в состояние «Сделано». Когда все ответственные закончили проверку и одобрили задачу, менеджер проекта принимает задачу и переводит её в «Сделано».
Слабые места в текущем процессе проверки кода.
Данный процесс, ввиду большого количества ручных операций, достаточно сложен и содержит множество недостатков, вызванных человеческим фактором[3]. Так, при сопоставлении списка файлов и карты ответственности, как разработчик, так и проверяющий, допускает ошибки, которые ведут к тому, что код оказывается непроверенным, или наоборот, тратится время проверяющего, не ответственного за блок. Когда критические участки кода не проходят должной проверки и это вскрывается, тратится дополнительное время на то, чтобы отменить изменения, исправить замечания и заново протестировать, проверить задачу.
Кроме того, отсутствует связь между проверкой кода в BitBucket и Jira, из-за чего приходится вручную назначать задачи, менять их состояния и так далее, таким образом увеличивается количество рутинной работы. Также участникам процесса требуется дополнительно коммуницировать между собой. К примеру, последний проверяющий должен уведомить менеджера проекта об окончании проверки. Таким образом, возникают точки для автоматизации процесса, которые позволят избежать ошибок и уменьшить количество дополнительных действий, требующихся от сотрудников.
Поскольку процесс разработки итеративный и развивается нелинейно, указанная модель процесса AS-IS не может учитывать все факторы [1]. Например, при исправлении замечаний могут быть изменены ранее не тронутые блоки, что требует повторной сверки с картой ответственности, назначением проверяющих и так далее. Более того, код может быть перебазирован (rebase), подвергнут «откату» (revert) или «слит» с основной веткой (merge) [9], в результате чего наличие некоторых проверяющих более не требуется. Это также требует повторного распределения в соответствии с картой ответственности, а следовательно - траты времени. В виду того, что разработка продукта компании ведётся в динамичном темпе, данные повторные рутинные действия складываются в большие затраты рабочего времени, что влечет за собой удорожание продукта и потерю прибыли [1].
Модель TO-BE процесса проверки кода.
Внедрив подход к проверке кода с использованием вспомогательных средств, разработчики смогут просматривать код за одну пятую времени, необходимого прежде [2]. Данный способ, представленный Коэном [3], определил концепцию к оптимизации процесса в данной работе. Этот подход базируется на том, что специальный инструмент должен автоматически проводить сравнение файлов, назначение проверяющих и управлять рабочим процессом.
Принимая во внимание проблемы текущей модели, описанные в предыдущем разделе, были выделены два основных пункта, требующих автоматизации:
Назначение проверяющих;
Смена состояния задач.
Таким образом, процесс проверки кода, с точки зрения участников, будет сведён к непосредственно «значимым» действиям, минуя этапы, являющийся рутинной работой и формальностями.
Автоматизация процесса позволяет более детально подходить к выбору проверяющих, также покрывая итерационные проверки кода (после повторных изменений и доработок). К примеру, учитывая изменения в новых блоках кодах, сервис определяет, необходимы ли дополнительные проверяющие и нужно ли изменить статус задачи на проверку кода у текущих проверяющих.
Диаграмма процесса, с учётом внедрения сервиса автоматизации, представлена в Приложении C. В результате сервис берёт на себя все рутинные и занимающие большое количество времени операции, назначая проверяющих и синхронизируя действия в BitBucket с задачами в Jira.
Формирование требований к средству автоматизации.
Согласно требованиям, предъявляемым выбранным подходом к оптимизации проверки кода, средство автоматизации должно обеспечивать:
Распределение проверяющих в зависимости от карты ответственности.
Назначение задач на проверку кода.
Отображение списка файлов по каждой задаче для каждого проверяющего.
Синхронизация состояния задач между BitBucket и Jira.
Оповещения в Slack.
Обработка дополнительных изменений в коде.
Назначение дополнительных проверяющих.
Сброс состояния проверки кода, если в результате изменений были затронуты соответствующие блоки.
Отображение не отслеживаемых файлов (новые файлы или те, для которых не назначен конкретный проверяющий).
Оповещение проверяющих о новых файлах, включённых в проект в результате выполнения задачи.
Кроме перечисленных функциональных требований, средство должно также отвечать следующим техническим параметрам:
Использование BitBucket Cloud в качестве системы контроля версий.
Использование Jira Cloud в качестве системы управления задачами.
Работа под управлением ОС Windows Server либо Ubuntu 14.04 или аналогичным дистрибутивом Linux.
Возможность размещения на сервере компании.
Наличие Веб-интерфейса.
Требование к размещению на собственном сервере продиктовано, в первую очередь, соображениями безопасности: исходный код приложения является одним из главных ресурсов компании и, следовательно, должен быть защищен от доступа третьими лицами, в данном случае, средству автоматизации.