Software & Systems

С усложнением проектируемых систем инспекция, или обзор кода, приобретает все большее значение для программистов, менеджеров и заказчиков. При разработке сложных систем, задействующих большое количество ресурсов, качество программного кода оказывает большое влияние на качество проектируемой системы [1]. Применительно к управлению качеством зачастую используются термины «верификация» – подтверждение соответствия нормам, стандартам и «валидация» – проверка на соответствие требованиям и нуждам заказчика [1–4].

Классификация методов верификации кода представлена на рисунке 1.

Инспекция с помощью специальных средств появилась относительно недавно, однако активно развивается и внедряется различными компаниями. Среди методов управления и инспекции можно отметить визуальные методы [5–7], методы реинжиниринга кода и его сертификации [8, 9].

Одним из таких специальных средств является инструмент фирмы Atlassian – Crucible, а также FishEye.

В данной статье описана работа системы Atlassian Crucible. Code review – это процесс анализа и проверки кода, проводимый с целью выявления ошибок в его написании, стилевых недо- четов, а также соответствия написанного кода поставленной задаче. Часто Code Review выполняется старшими разработчиками для контроля за работами по написанию кода. Использование специальных средств для проведения обзора кода делает процесс более гибким и надежным.

Code Review помогает привести весь код к единому стилевому оформлению, позволяет быстро выявить опечатки, совершенствует навыки командной работы, что очень полезно для начинающих разработчиков [2].

Анализ системы Atlassian Crucible

Пакет Crucible предлагает разработчикам удобные и эффективные инструменты для взаимного рецензирования кода. В новой версии пакета реализована концепция так называемого итеративного рецензирования (iterative code review), когда один и тот же участок кода подвергается многократному рецензированию и переработке. С помощью Crucible процедура рецензирования всегда останется простой и действенной, несмотря на постоянные изменения в условиях разработки.

Веб-интерфейс пакета Crucible предлагает простые и быстрые инструменты для создания новых заметок к коду. Для дополнительного удобства поддерживаются навигация в заметках с помощью клавиатуры, изменение параметров отображения и вставка комментариев напрямую в код. Для интеграции с существующими процедурами комментирования кода пакет Crucible поддерживает загрузку уже созданных замечаний к коду из таких систем управления версиями, как Subversion, Perforce, Git и ClearCase. Синхронизация новых замечаний (Pre-commit) поддерживается абсолютно для всех платформ. Кроме всего прочего, пакет Crucible отлично интегрируется со вспомогательными инструментами разработчика FishEye и JIRA, со средами разработки Eclipse и IntelliJ, а также с любыми другими инструментами, поддерживающими интерфейс REST (Representational State Transfer) API с четырьмя базовыми операциями (GET, PUT, POST и DELETE) или работу с плагинами.

Рассмотрим работу в Crucible более подробно. В большинстве случаев разработка какого-либо продукта проходит три базовые стадии (рис. 2). Однако в последнее время все чаще разработчики добавляют еще одну стадию, которая называется Review (рис. 3).

Смысл ее в том, что перед окончанием определенного задания или какого-либо компонента кода как минимум еще один член команды должен просмотреть всю сделанную работу. В случае обнаружения ошибок задание возвращается на стадию In progress. Таким образом, качество кода заметно улучшается.

Анализ основных операций системы Atlassian Crucible

С помощью инструмента Crucible над кодом можно совершить три различные операции. Рассмотрим каждую из них.

Обзор части кода (snippet review) – это простая операция, позволяющая вставить в специальное поле какой-либо код и тут же обсудить его с коллегами. Комментарии будут привязаны к строкам фрагмента кода (см. http://www.swsys.ru/up­loaded/image/2014-4-dop/4.jpg).

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

Дискуссия вокруг ревизии (changeset dis­cussion) – функция, позволяющая кому угодно из команды комментировать любую ревизию из репозитория. Авторы и другие члены команды тут же получат уведомления о новых комментариях (http://www.swsys.ru/uploaded/image/2014-4-dop/5.jpg). На форме слева показаны комментарии и общая информация, а справа – все изменения, которые были сделаны во всех измененных файлах. На экран выводятся только изменения. Также доступна общая информация о ревизии.

Подробный анализ кода (formal code review) – это основная функция Crucible. Для создания review необходимо указать одного или нескольких участников обзора (ревьюеры, reviewers), дату окончания обзора (дэдлайн), объект просмотра ревьюерами.

Каждый ревьювер должен просмотреть все указанные файлы и после этого закрыть review, иначе автор обзора не сможет завершить его. На форме (http://www.swsys.ru/uploaded/image/2014-4-dop/6.jpg) слева находится список всех файлов, которые изменил автор в рамках данной ревизии. Reviewer может оставить комментарий ко всему обзору (general comment), к одному определенному файлу или к строке кода.

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

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

Маршрут разработки программного модуля для системы Atlassian Crucible

Для сверки скриптов из различных веток репозитория проекта с возможностью выбора источника сверки при создании новой задачи Code Review используется модуль Crucible. Он обеспечивает ведение переписки изменений и доработок по скриптам проекта в единой системе Code Review, позволяет осуществлять выгрузку статистики по задачам Code Review (рис. 4).

На данный момент при использовании компонентов Crucible и FishEye разработчики не могут сравнивать изменения ответвления (branch) с текущей рабочей версией программы (trunk). Это лишает возможности проводить полный цикл Code Review непосредственно в рамках системы Crucible. Ответственному за Code Review приходится дополнительно сверять branch и trunk с использованием отдельной системы контроля версий и вести переписку с использованием почты с группой разработчиков.

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

–      сравнение версий скриптов различных веток репозитория;

–      добавление комментариев по замечаниям, возникшим при Code Review, между разработчиком и ответственным за Code Review непосредственно в задаче;

–      автоматизация выбора эталонной ветки (trunk) на этапе создания/изменения проекта и прикрепление к нему определенного репозитория;

–      выбор альтернативной ветки проекта (branch) для проведения сверки между двумя различными проектами, разрабатываемыми в едином репозитории;

–      оповещение участников Code Review об изменениях по электронной почте.

При выборе репозитория и эталонной версии программы (trunk) после заполнения поля Reposi­tory становится доступным список файлов, относящихся к репозиторию (дерево репозитория) (http://www.swsys.ru/uploaded/image/2014-4-dop/7.jpg).

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

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

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

Рассматривая вопросы качества программного обеспечения, необходимо не ограничиваться рамками отдельных процессов жизненного цикла. Качество программного обеспечения является постоянным объектом внимания программной инженерии и обсуждается во многих областях знаний [10–12].

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

Литература

1.     Блэк Р. Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование. М.: Лори, 2006. 566 с.

2.     Вигерс К. Разработка требований к программному обеспечению; [пер. с англ.]. М.: Русская редакция, 2004. 576 с.

3.     Иванов А.М., Власов А.И. Верификация программных моделей коммуникационных сетей // Наука и образование: электронное научно-техническое издание. 2012. № 10. С. 24.

4.     Власов А.И., Лыткин С.Л., Яковлев В.Л. Краткое практическое руководство разработчика по языку PL/SQL. М.: Машиностроение. 2000. Т. 2. 64 с. (Библиотека журн. «Информационные технологии»).

5.     Власов А.И. Пространственная модель оценки эволюции методов визуального проектирования сложных систем // Датчики и системы. 2013. № 9. С. 10–28.

6.     Власов А.И., Цыганов И.Г. Адаптивная фильтрация информационных потоков в корпоративных системах на основе механизма голосования пользователей // Информационные технологии. 2004. № 9. С. 12–19.

7.     Власов А.И., Цыганов И.Г. Архитектура корпоративной многоагентной автоматизированной системы фильтрации информационных потоков // Информационные технологии. 2005. № 1. С. 34–41.

8.     Doar M. Practical Development Environments. USA, O'Reilly Media Publ., 2005, 330 p.

9.     Бритов Г.С. Верификация, валидация и тестирование компьютерных моделей линейных динамических систем // Информационно-управляющие системы. 2013. Вып. 2 (63). С. 75–83.

10.  Власов А.И. Системный анализ технологических процессов производства сложных технических систем с использованием визуальных моделей // Междунар. науч.-исслед. журнал. 2013. № 10–2 (17). С. 17–26.

11.  Власов А.И., Журавлева Л.В. Визуализация творческих стратегий с использованием ментальных карт // Прикаспийский журнал: управление и высокие технологии. 2013. № 1. С. 133–140.

12.  Зворыкин Н.М. Реализация процессного подхода на промышленном предприятии // Методы менеджмента качества. 2004. № 1. С. 35–40.

References

1.  Black R.  Critical Testing Processes: Plan, Prepare, Perform, Perfect. Addison-Wesley Professional Publ.,
2003, 608 p. (Russ. ed.: Lori Publ., 2006, 566 p.).

2.  Wiegers K.E.  Software Requirements. Microsoft Press, 1999 (Russ. ed.: Russkaya Redaktsiya Publ., 2004,
576 p.).

3.  Ivanov A.M., Vlasov A.I. Verification of software models of communications networks.  Nauka i obrazovanie:
elektronnoe nauchno-tekhnicheskoe izdanie [Science and Education: Electronic Scientific and Technical Journ.]. 2012,
no. 10, pp. 24 (in Russ.).

4.  Vlasov A.I., Lytkin S.L., Jakovlev V.L.  Kratkoe prakticheskoe rukovodstvo razrabotchika po yazyku PL/SQL
[A Quick Manual of a PL/SQL Developer]. Moscow, Mashinostroenie Publ., 2000, vol. 2, 64 p.

5.  Vlasov A.I. A spacial model of complex systems visual design metods evolution estimation.  Datchiki &
Systemi [Sensors & Systems]. 2013, no. 9, pp. 10–28 (in Russ.).

6.  Vlasov A.I., Tsyganov I.G. The adaptive filtering of the information streams in corporate systems on the user
voting basis. Informatsionnye tekhnologii [Information Technologies]. 2004, no. 9, pp. 12–19 (in Russ.).

7.  Vlasov A.I., Tsyganov I.G. Multiagent Architecture of an Automated System for Corporative Information
Stream Filtering. Informatsionnye tekhnologii [Information Technologies]. 2005, no. 1, pp. 34–41 (in Russ.).

8.  Doar M. Practical Development Environments. O'Reilly Media Publ., 2005, 297 p.

9.  Britov G.S. Verification, validation and testing of computer models of linear dynamic systems.  Informatsionno-upravlyayushchie sistemy [Information and Control Systems]. 2013, vol. 2 (63), pp. 75–83 (in Russ.).

10. Vlasov A.I. System analysis of technological processes of producing complex technical  systems using visual
models. Mezhdunar. nauchno-issled. zhurnal [International Science and Research Journ.]. 2013, no. 10-2 (17), pp. 17–
26 (in Russ.).

11. Vlasov A.I., Zhuravleva L.V. Visualization of Creative Strategies: Application of Mental Maps.  Prikasp.
zhurn.: upravlenie i vysokie tekhnologii  [Caspian  Journ. Management and  High Technologies]. 2013, no. 1, pp. 133–
140 (in Russ.).

12. Zvorykin N.M. Implementation of process approach in industrial enterprise.  Metody menedzhmenta kachestva
[Quality Management Methods]. 2004, no. 1, pp. 35–40 (in Russ.).