К основному контенту

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.

Комментарии

  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. И да, можно комментить прямо в коде, через веб: знай и люби свой инструмент. Плохо, что оповещения не приходят :(

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

Отправка комментария

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объек

План "Б" или как прикольно провести субботний день

Всем привет. Вчера состоялась конференция " План Б ". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек. Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля. Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера) Здесь приведу лишь те вещи, которые мне запали в мозг Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а" Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно ча

Переключите тумблер или умные люди дурного не посоветуют

Навеяно интересными вопросами про TDD после  вчерашнего выступления . Uncle Bob : " Flipping the Bit " Подробнее постараюсь перевести чуть позже, пока только это: Как определить, что у коллеги (или у вас) ТУМБЛЕР переключен?  Если ваши ответы на вопросы ниже совпадают с приведенными - то все хорошо :) Мантра: Сможете ли вы выполнить работу быстрее используя TDD? ДА Существуют ли какие-либо задачи, которые вы можете выполнить быстрее без TDD? НЕТ Я понимаю, что TDD может помочь в долгом проекте, а что если у вас короткая задача? Будете использовать TDD? Да, потому что TDD быстрее даже в короткой перспективе Что если времени реально не хватает, и босс стоит над душой, будете ли вы использовать TDD? ДА В любом случае? ДА Есть ли случаи, когда вам не нужно использовать TDD? НЕТ Представьте себе что вы на звездном корабле Enterprise ( Star track ) и осталась всего секунда до взрыва антиматерии. Все что вам нужно, чтобы избежать этого, поменять один IF. Будете ли вы и