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

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): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

Полезные ресурсы для молодых (и не только) тестировщиков

Уже 3 месяца провожу собеседования тестировщиков.
Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем то экзотическим и забавным.

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.