суббота, 12 октября 2013 г.

Code review в Visual Studio 2012 - часть 2

Продолжение (часть 1)
(с)

Идея начать использовать Code Review возникла еще до перехода на TFS 2012. И в качестве первого инструмента позволяющего делать это удобно (с точки зрения самого процесса ревью) попробовали довольно экзотическую комбинацию Crucible & Fihseye (экзотическую, потому что сама по себе TFS она не поддерживает).
Комбинация понравилось, но косячки все равно нашлись:
  • Так как мы работаем в TFS в качестве системы контроля версий, то пришлось все исходники каждую ночь мигрировать в Git (хотя, естественно, это было ожидаемо). 
  • Смотреть и анализировать изменения удобно в привычном тебе виде/инструменте. Для меня это пожалуй студия: можно перейти на реализацию метода, класса и посмотреть что-там-как.
  • Сам процесс Code Review отделялся от среды разработки, комментарии ревью отделялись от оригинального места хранения исходников.
В общем не пошло.
Тем временем переход на TFS 2012 опять отложился. Посмотрев по сторонам нашли интересую утилиту, которая встраивается в студию и позволяет запрашивать Code Review своего кода.
Утилита называется Review Assistant. Выглядит инструмент очень симпатично и для команды до 3 человек бесплатен.

просмотр изменений и обсуждение в Review Assistant
Комментарии по коду подсвечиваются, и при наведении курсора мышкой становятся видны полностью.
Запрос на ревью
Позволяет делать post-checkin запросы на несколько changeset'ов (Visual Studio так не умеет). Есть нотификация по почте. Разворачивается очень просто: сервер и клиенты-плагины к студии. Подключается не только к TFS. Есть возможность создавать своих пользователей или добавлять пользователей из AD.
К сожалению, был обнаружен дефект, который заставил отказаться от применения инструмента: ответы на комментарии не обновлялись в студии автоматически. Для этого нужно было переподключаться к серверу. На мой взгляд ошибка неприятная и заставляет задуматься о качестве всего кода. Но обещали пофиксить в ближайших версиях. Может, когда вы будете это читать, проблема будет решена (нашли мы ее в конце сентября 2013 года, билд 2.0.108).

Но тут подоспела миграция на TFS 2012 и понеслось...
Первоначальная эйфория развеялась быстро: основной workflow Code Review в студии несколько отличался от того, на который мы настраивались. Ребята из MS похоже не доверяют друг другу и основной упор сделан на том, что Code Review проводится до check-in'а в TFS. То есть ты что то сделал, создаешь запрос на ревью (через Team Explorer). Код обсуждается и только после этого чекинится в основную ветку. Подробно и со скриншотами описано здесь. Проверяемый код (до чекина) при этом тоже хранится в TFS, я так подозреваю с использованием механизма shelve (update: так и есть, автоматически создается shelveset вида "CodeReview_TIMESTAMP").
Нас подобный процесс не устраивал. Хотелось проводить ревью после чекина.  Начали копать дальше. Собственно копали немного, почти сразу наткнулись на подобный вопрос в форуме MSDN. Выяснилось, что запрашивать ревью можно и после чекина, выбрав нужный changeset в History. К сожалению только один (см. картинку чуть выше). Подумав, рассудили, что не так уж и страшно и стартанули.
просмотр изменений (тут новый файл) и обсуждение в Visual Studio.
Комментариев прямо в коде нет (плюсик в карму Review Assistant), но место отмечается. Поиск реализации функции по F12 работает. Visual Assist к сожалению не справляется.

Огромным плюсом ревью в TFS является то, что ты делаешь его прямо в самой студии. Сам ревью (для него в TFS используется отдельный Work Item type) привязан к исходникам, его можно привязать к таске. В итоге все хранится в одном месте и можно быстро восстановить историю. Как и любой тип в TFS, Code Review work item type можно настроить под себя: добавить новые поля, изменить workflow и тд.

Пока, лично у меня, впечатления позитивные: я стал больше смотреть на код, что мы пишем :) У команды, как мне кажется, тоже негатива пока нет. Есть идея по автоматической генерации запросов на ревью. Функциональность TFS можно расширять плагинами. Я нашел заготовку, которая автоматом создает запрос после чекина. Пока времени проверить идею не было. Если разберемся, обязательно здесь отпишусь.

Надеюсь, наш, небольшой пока, опыт будет полезен еще кому-нибудь.

Update:
Комментарии (жирным) от коллег и мои ответы:

Уж что-то что, а продукты от Atlassian куда менее экзотические чем TFS!
Хмм, ну в чем именно экзотичность я постарался объяснить. Но то, что косяков и в студии хватает - это факт.

Сам процесс Code Review отделялся от среды разработки, комментарии ревью отделялись от оригинального места хранения исходников - "а это вообще фича, а не минус, поскольку удобно code-review делать в web-интерфейсе, особенно для больших и распределённых команд."
Да удобно, причем именно сама реализация ревью в Crucible удобней, а не то, что это веб или не веб: если студия есть, и она подключена к общему TFS, то в чем проблема использовать такой code review workflow для больших и распределенных команд?  Мой минус был не про это, а про то, что я теряю возможность делать ревью в том же инструменте, что и кодирую. И комментарии студии хранятся там же, где и исходники. Я по файлу в TFS, могу посмотреть все комментарии, которые были по нему сделаны. Опять же в TFS (правда через одно место ;) )

Смотреть и анализировать изменения удобно в привычном тебе виде/инструменте. Для меня это пожалуй студия: можно перейти на реализацию метода, класса и посмотреть что-там-как - "При использовании Git эта проблема отпадает – студия (равно как и другие распространённые IDE и редакторы) отлично поддерживает Git"
Обоснование перехода на новую систему хранения исходников (при наличии живого и продолжительное время используемого TFS) – это тема отдельной дискуссии. 

Так что все проблемы надуманные, в связи с привязкой, и изначальным желанием выставить TFS в хорошем свете. В отличие от Microsoft, для компании Atlassian создание инструментов разработки – профильный бизнес, и у них больше возможностей и ресурсов для их улучшения и развития.
Проблемы не надуманные, они просто есть. А насчет желания выставить TFS в хорошем свете -  плохо, если так выглядит. Буду стараться исправиться :)) – вообще ожидания от новой студии и TFS были большими, а на деле все сыро. Очень сыро.
И пока мой единственный аргумент в защиту - это «все в одном флаконе».

Еще немного полезностей про тюнинг TFS.

18 комментариев:

  1. Мы уже несколько лет пользуемся для ревью кода pull реквестами в GitHub - достаточно удобно. Так же ребята из других команд присылали мне свои changeset'ы из TFS ,там вполне адекватная сравнивалка кода. Но в отличии от GitHub нельзя писать прямо в коде комментарии. Приходится копипастить кучки в письмо , что тяжко.

    ОтветитьУдалить
  2. Я так понимаю у вас еще TFS 2010 (если не 2008). Сейчас в TFS 2012 можно настроить возможность Code Review для сторонних участников (не только команды) и посылать запросы. Со всеми вытекающими удобствами: студия, комменты привязанные к коду. Ну это для тех кто "не пацаны" и не используют GitHub ;)

    ОтветитьУдалить
  3. Опять же, я не хочу делать это в студии (помоему там интеграция с ТФС сделана не для людей). Мне удобно делать это на вебе, а веб морда у ТФС (черт знает какая у нас версия) пока еще до гитхаба не дотягивает. И самое важное я не могу на вебе писать коменты к коду, а копипастить его в письма меня бесит. Вытскивать же их многогиговый проект себе чтобы сделать ревью 20 строк - мне лень.

    ОтветитьУдалить
  4. а еще хочу крови того творца ,который делал ветвление в ТФС (бренчи) ... Проект с размером кода в 1Г, с 10 бренчами занимает на винте 10Г. А если бренчи заводятся порелизно, то одно изменение (багафикс) нужно делать как минимум в 2х местах . ТФС ужасен!

    ОтветитьУдалить
  5. 1:1 с комментом от коллег. Да, отсутствие возможности сделать ревью через веб при наличии этого самого веба в TFS, это серьезный прокол :(

    ОтветитьУдалить
  6. я всегда знал, что ты кровожаден :) Но посмотри на новый TFS, там стало лучше. До идеала далеко - но уже можно использовать.

    ОтветитьУдалить
  7. Кстати фраза "посмотри на новый TFS" звучит как издевательство, его надо ставить пол дня вникая во всякие хитрости ,тогда как сравнить тот же GitHub и BitBacket я могу за 5 минут зарегистрировав бесплатные аккаунты.

    ОтветитьУдалить
  8. Привязка к коду комментариев даже на твоих сткриншотах выглядит жутко. Коментарии ,типа граждане второго сорта, где то в уголке мелким шрифтом. В Гитхабе это полноценная дискуссия как бы внутри кода. Причем как ты верно заметил ничего кроме браузер мне для этого ревью не надо.

    ОтветитьУдалить
  9. и будешь там хранить исходники продуктов по безопасности? ;)

    ОтветитьУдалить
  10. кстати не обратил внимание: для ревью не надо вытаскивать исходники себе локально. подтаскивается только 2 версии файла, который смотрится, для diff'а

    ОтветитьУдалить
  11. Макс, для того чтобы попробовать ты можешь юзать любые исходники. А для продакшена покупается приватная подписка. И например некоторые маленькие софтверные компании, типа моей, хранят там исходники небольших по ее меркам продуктов. ;)

    ОтветитьУдалить
  12. Попробовать github то я могу, дальше то что? Надо представлять плюсы/минусы всех решений. Для этого надо пробовать и TFS тоже. А насчет хранения, даже платного, исходников продуктов по безопасности в облаках - это (пока) выше моего понимания :)

    ОтветитьУдалить
  13. Макс, исходники они у любых продуктов исходники. Никто не предлагает хранить там приватные ключи для подписей. Их и в локальном TFS хранить не следует.

    ОтветитьУдалить
  14. :) я искренне рад, что тебя эта тема зацепила. Я постараюсь посмотреть то, что ты рекомендуешь. Но если ты сделаешь подобный обзор по своим тулам - будет супер. Очень поможет :)

    ОтветитьУдалить
  15. Да не столько ты зацепил, тебе просто досталось. :) Просто у нас тоже есть адепты "единых стандартов", в стиле "да пусть херово выглядит и работает зато все в одном месте" . На счет написать, то че то я обленился (могу попробовать спрятаться за фразой "много работы") ,но мысли написать про то что я юзаю у меня давно есть.

    ОтветитьУдалить
  16. Спасибо что поделились опытом. Мы сейчас тоже эксперементируем. Пока есть трудности с подходом re-review.

    ОтветитьУдалить
  17. Спасибо за комментарий :) А под re-review понимается трекинг того, как был изменен код по комментариям из первого ревью? Если так, то да - с этим проблемы. Получается, что пока нужно заводить следующее ревью, на след chanset или shelve. Но это неудобно: нет связи с предыдущим. Основная проблема ревью в студии+TFS, это невозможность просматривать изменения между пачками changeset'ов. Это бы решило проблему, хотя и частично. Review Assistant это умеет. Общался с товарищами из MS на эту тему, обещали, что в след версии будут улучшения code review в студии. Но пока публичных новостей на эту тему не слышал.

    ОтветитьУдалить
  18. И да, можно комментить прямо в коде, через веб: знай и люби свой инструмент. Плохо, что оповещения не приходят :(

    ОтветитьУдалить