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


В этой статье:

1. Введение
2. Три вида командного обзора кода:
   1. Обзор маленького кусочка кода (Snippet)
   2. Дискуссия вокруг одной ревизии
   3. Подробный анализ кода:
      1. Код из репозитория
      2. Код отдельных файлов
      3. Поиск фалов
      4. Код с вашего компьютера (pre-commit review)
      5. Загрузка отдельного файла
3. Crucible and Jira
4. Activity view
5. Выводы

Введение

В классическом варианте у каждого задания (таска) есть три стадии выполнения:
«To Do» > «In progress» > «Done»
Но в последнее время всё чаще команды вставляют в эту череду ещё одну фазу, которая называется «Review»
«To Do» > «In progress» > «Review» > «Done»
Смысл сводится к тому, что перед тем, как закончить таск, как минимум один другой член команды должен просмотреть всю сделанную работу и сказать своё веское слово. В случае обнаружения каких-то косяков, таск возвращается в фазу «В процессе». Таким образом, качество кода очень сильно увеличивается.
Проводить обзор кода довольно муторное дело для большинства программистов, так как нужно в самом простом случае отвлекаться от своих дел, в худшем — восстанавливать чужой таск на своём компьютере и пробовать воспроизвести всё то, что требовалось сделать в таске. Это неудобно. Поэтому сейчас появились некоторые инструменты для проведения этой операции. Кстати говоря, самые популярные хостинги проектов с открытыми исходниками, типа GitHub (если я не ошибаюсь, с него всё и пошло), а так же code.google и, я уверен, другие тоже имеют нечто подобное. Они ввели такую систему, где пользователи могли бы оставлять свои комментарии к коммитам и обсуждать проведённые изменения. Иными словами, образовывалось так называемое «социальное программирование»

Social coding is an approach to software development that places an emphasis on formal and informal collaboration.
Although the term is often associated with social coding websites such as GitHub, BitBucket, CodePlex and Google Code, the term can be used to describe any development environment that encourages discussion and sharing.

отсюда

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

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

Три вида командного обзора кода

Crucible принадлежит компании Atlassian, той самой, что сделала очень ныне популярный баг-треккер Jira. Ну и, как нетрудно предположить, их очень легко можно друг с другом подружить. Но об этом потом.
В этом инструменте можно сделать три разные операции с кодом. Рассмотрим каждую отдельно.

1) Обзор маленького куска кода (snippet review)

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


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

2) Дискуссия вокруг одной ревизии (changeset discussion)

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

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

3) Подробный анализ кода (formal code review)

Именно такое ревью будет составлять большую часть вашей работы в Crucible. Потому как когда вы создаёте ревью, в ней нужно обязано указать:

• Одного или нескольких участников обзора, кто должен просмотреть ваш код («ревьюеры», reviewers)
• Дату окончания обзора (дэдлайн)
• Если у вас установлена так же и Jira, то ссылочку на соответсвующий тикет — так будет проще проследить в будущем, что вы делали и для чего
• И самое главное — что именно нужно просматривать ревьюерам

На следующем скриншоте видно, как создаётся один обзор и все перечисленные выше поля нужно заполнить


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


Как выглядит ревью кода?

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

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

В зависимости от статуса вашего коммента, дискуссия по-разному будет отображаться в ленте. Плюс ко всему, для репорта бага можно будет сразу создать тикет )


Все ваши обзоры будут складываться в вашем «ящике»


А теперь мы поговорим про контент. Что именно можно отсылать на ревью? Когда вы создаёте ревью, первое что вас просят сделать — это выбрать контент вашего обзора. Проще говоря, что именно будут ваши ревьюеры смотреть.

3.1) Код из репозитория

Самый первый и часто используемый — это ревью ревизии или ревизий. То есть вы просто появляется окошко с вашими проектами, выбираете вашу репу, ищите нужный бранч, отмечаете нужные (как правило, последние) ревизии и всё. Ревью создан.

3.2) Код отдельных файлов

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

3.3) Поиск файлов

Ничего особенного — просто удобная форма поиска по файлам и их содержаниям

3.4) Код с вашего компьютера (pre-commit review)

А вот тут я остановлюсь на подольше. Представим себе ситуацию, когда вам нужно написать какой-то новый код, причём это что-то из разряда researching. Ну то есть тестовый образец, который немного страхово коммитить в публичный репоизторий. То есть новый код есть только у вас на компе. И вы хотите его показать коллегам, что бы те заценили. Как быть?

Можно использовать т.н. патчи — то есть список всех изменений в diff формате, сохранённые в одном текстовом файле. Насколько мне известно, такую функцию поддерживают почти все системы контроля версий. Многие клиенты позволяют экспортировать патчи. Вот, например, как это делается с помощью Eclipse Mercurial plugin (которую я, кстати, очень сильно рекомендую, если вы пользуетесь Меркуриалом!). Правы клик на проекте и — экспорт патча

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

После этого вам остаётся только открыть Crucible, создать новый ревью и выбрать четвёртый пункт Pre-commit и загрузить только что созданный вами файл с патчем. Ревью будет выглядеть абсолютно так же, как и в первом случае с ревизиями. То есть именно так, как все привыкли. НО! Все изменения будут лишь исключительно на вашем комрьютере. Ни в публичном репозитории, ни даже в вашем локальном клоне репозитория, только в качестве незакоммиченных изменений! Весьма крутая штука, надо сказать ;)

Ну и пятый пункт

3.5) Загрузка отдельного файла

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

Ну и ещё парочку скриншотов на затравочку, чтобы «придавить» прочитанное.

Crucible and Jira

Я писал выше, что Crucible имеет тесную интеграцию с Jira. Ну вот, например, как это будет выглядеть в вашем баг треккере.



То есть все ревью будут сохранены в отдельном табике и вы через год когда будете думать глядя на код «чё я этим хотел сказать?», то можете открыть соответсвующий тикет и почитать в ваших обсуждениях. Тем Crucible и хорош, что все ваши обсуждения расположены рядом у кода и само собой они все по делу.

Activity view.

Ещё приведу пример, как выглядит «стена» проекта. Ну или лента. Как угодно называйте. Тут отображаются все коммиты и все события, включая все комментарии и созданные ревью.


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


Ну и теперь немного от себя.

Выводы.

Хотел бы поделиться впечатлениями. Важно понимать, что Crucible, да как, впрочем, и другие его конкуренты — это всего лишь средства. Всё очень сильно зависит от команды. Поясню:

1. если в команде только один человек, который заинтересован в том, чтобы как-то изменить работу команды к лучшему, а остальные инертные люди, то ничего не получится. Потому как никто просто не будет пользоваться этим и на инициатора будут косо смотреть…
   
   Всем будет просто лень этим заниматься, потому как «итак своих проблем полно, а тут ещё чьи-то нужно решать». Поэтому моё мнение, что нужно хотя бы 3-4 заинтересованых лиц, они всех остальных перезаражают.
2. обзор чужого кода это в той или иной степени критика работы. А мы все знаем, что каждый человек по-разному относится к критике. Есть люди, которые придираются к каждой строчке, просто из-за самого процесса «пожурить». Ну как жешь, начальник, нужно дать понять, кто тут главный… Я, конечно, утрирую, но просто хочу сказать, что команды разные. Crucible нужно использовать не для того, чтобы как-то ограничивать или контроллировать программиста, а чтобы его поощрять работать ещё лучше! Когда идёт постоянная положительная обратная связь, то это мотивирует лучше всего. Я поработал в разных командах и лучше всего работается с молодыми ну просто молодой разум открыт всему новому ))) так что всё индивидуально.

Из плюсов могу сказать, что оно работает. Всмысле то, ради чего ввели ревью кода — а именно, к качеству результата продукта и качество действительно растёт. Во-первых, ты постоянно думаешь, что каждая строчка твоя будет просмотрена несколькими другими людьми и не хочется опозориться. Поэтому самодисциплина повышается в разы. "А вдруг не заметят" не прокатывает. Когда ты коммитишь код в пустоту, когда нет обратной связи ни от начальника, ни от клиента, ни от пользователей, то мотивация пропадает мигом. Ревью вырывает пофигизм накорню. Любая глупость становится мгновенно фольклёром ;) Во-вторых, это учит. Когда тебе указывают на ошибку, ты её исправляешь и уже больше никогда её не допустишь. Ежели ты коммитишь код «в пустоту», то ты даже не сможешь узнать, верно ли ты сделал. «Вроде работает, а правильно ли?»
Кстати, такой подход также искореняет начисто вероятность «логической бомбы». Слышали странные истории, когда обиженый программист уходит из конторы и внедряет в код либо бэкдор, либо т.н. «логическую бомбу», которая срабатывает в заданное время и чего-то там уничтожает?.. Ни разу с этим не сталкивался лично, но всё равно, когда вся команда следит за всем кодом, а не каждый за своим, то получается очень качественный результат.
Вот и всё! Надесь, вам было интересно читать. Удачи!
Пыс-пыс. Все скриншоты взял с сайта Crucible. Не свой же проект выкладывать!