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

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

(с) отсюда
Дошли у нас наконец-то руки до миграции на TFS 2012.
И сразу начали осваивать новые
штуки, которые он с собой принес.

Одним из таких новшеств VS/TFS 2012 является возможность проводить Code Review, как это говорится "не отходя от кассы".

Первая часть этого опуса скорее о том, зачем оно (Code Review) вообще нужно. (Кому теория неинтересна, тому можно сразу сюда). Я не буду дублировать здесь то, что и так можно найти на просторах интернета. Здесь собраны ссылки на те, показавшиеся мне интересными, ресурсы, которые я находил, пока сам изучал этот вопрос.

В июне 2011 на встрече AgilePiter в офисе Яндекса мы обсуждали инженерные практики. Меня тогда сильно удивило, как много людей используют Code Review. У меня к тому времени сложилось несколько другое, скорее даже, негативное к нему отношение. Давайте попробуем разобраться.

Вообще, по жизни, есть разные практики проведения Code Review:
  • до / после check-in'ов (плюсы - минусы каждого из подходов)
  • участвует вся команда / только один человек, как правило менеджер или роль переходит
  • если участвует вся команда, то ревью по отдельности / митинги 
  • обязательно / по желанию / как получится
И так далее.

Также существует много мнений на тему пользы самого Code Review.

(c) proof
Mark Seemann (автор многих интересных книг про программированию) считает, что code review убивает процесс творчества. Хмм, творчество то у нас должно быть созидательным, а плохо/неправильно работающий код скорее деструктивен. Так что это или сарказм, или..., или мой английский недостаточно хорош? ;)


Отдельно проскакивала интересная статистика по коллегиальному code review (формат в виде митинга). Такой формат позволяет найти дополнительные 4% к проблемам уже найденным при индивидуальном ревью. Зато эти проблемы самые "хитрые" и сложно обнаруживаемые.

Еще пару интересных, на мой взгляд, размышлений на этот счет: "Code Review is not about..." и Code Reviews Mindmap
(с) Tomek Kaczanowski
Хорошая инструкция к Code Review на GitHub, а именно к тому, как именно писать комментарии, как правильно настроить себя на получение позитива от процесса.

Также мне понравилась статья из 2-х частей про процесс Code Review от Саши Калугина. Там как раз и про объективность / субъективность, и про проблемы, которые могут возникать в процессе.

Итого, будем исходить из того, что:
  • Code Review должно помогать, а не мешать
  • Это сложно
  • Но возможно :)

Мы все же оптимисты и решили попробовать, а там видно будет насчет пользы-вреда-бесполезности.

Продолжение...

Комментарии

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

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-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем то экзотическим и забавным.

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