Как стать автором
Обновить

Комментарии 17

Еще удобно использовать github для code review, можно оставлять комментарий на любую строчку кода
возможно, если команда распределённая, но если вы находитесь в одном помещении, то наиболее эффективным вариантом будет непосредственный просмотр кода у автора.
про минусы CR после коммита я написал.
используем пул реквесты на гитхабе для этих целей и :octocat:
Проводить ревью кода устно не всегда удобно. Бывает, что переделки нужны немаленькие. Каждый раз отслеживать и запоминать список того, что нужно изменить и что изменили тоже сложно. Выход: писать заметки по коду, следить за коммитами. На гитхабе это делать очень удобно.
И смотреть код должен обязательно более квалифицированный сотрудник, чем тот, кто писал этот самый код, иначе смысла от такого код ревью будет немного.
> Каждый раз отслеживать и запоминать список того, что нужно изменить и что изменили тоже сложно
Не очень понятно — мы просто смотрим исходящие изменения в Eclipse, ничего запоминать не нужно, все изменения видны.
Основная же суть review до коммита (как и тестирования до коммита) — разработчик не успевает отключиться от контекста задачи; ему не нужно тратить время, чтобы вспомнить чем он занимался.

> И смотреть код должен обязательно более квалифицированный сотрудник, чем тот, кто писал этот самый код, иначе смысла от такого код ревью будет немного
Т.е. у самого квалифицированного сотрудника код смотреть никто не будет? :) Как написал коллега в статье, мы рассматриваем code review ещё и как элемент парного программирования. И поверьте, более квалифицированному частенько есть чему поучиться у всех остальных.
смотреть каждый коммит тоже накладно. Мы проверяем фитчу целиком, когда она закончена и вносим поправки. Ведь бывает, что код не сразу формируется и некоторые участки могут быть изменены самим разработчиком несколько раз, прежде чем он решит, что код готов. Да и дергать каждый раз сотрудников, на то чтобы они посмотрели код, тоже не дело. Я смотрю код тогда, когда у меня есть время, а до этого момента пул реквест висит и никому не мешает (опять же это обычная ветка с которой можно в любой момент мержиться).
Насчет того что разработчику не нужно переключать контекст при вашем подходе, ошибаетесь, ему то не нужно, а тому кто будет смотреть код — нужно.
Если вашему более квалифицированному сотруднику приходится учиться у ваших низкоквалифицированных сотрудников, то у меня для вас плохие новости :).
т.е. я
пардон, опечатался.
Т.е. я правильно понимаю, что у вас на фитчу идет один коммит? И перед коммитом идет обязательный ревью? А если фитча содержит 10 коммитов?
Да, у нас на одну задачу идёт один коммит. А перед коммитом — обязательно проводится code review и тестирование. Только после этих двух операций код можно складывать в общий репозиторий.

> А если фитча содержит 10 коммитов?
Мы стараемся «распиливать» задачи таким образом, чтобы ни одна из них не занимала более трёх дней. Конечно, бывают исключения, но в целом мы справляемся.
По поводу количества коммитов — обычно это действительно один коммит.
позвольте я угадаю, вы используете svn, который отложил такой отпечаток на ваш процесс?
> Если вашему более квалифицированному сотруднику приходится учиться у ваших низкоквалифицированных сотрудников, то у меня для вас плохие новости :)

Например?

«приходится учиться» — какое-то странное определение. У каждого человека существует миллион привычек, выработанных годами, а работа в паре позволяет смотреть не только на код, но и даже на то, как человек работает с мышкой, например или какие хоткеи использует. Ну говоря уже о более сложных вещах.

Не понятно, что может быть плохого в том, чтобы узнать что-то новое — совершенно не важно, от кого эта информация исходит.

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

Именно поэтому у нас есть «дежурный по code review» — за одну итерацию переключением контекста страдает только один человек :)
дежурный по код ревью, такой бред мог породить действительно только процесс основаный на ущербности репозитория.
уважаемый uzver, позвольте поинтересоваться, каким образом Вы «встраиваете качество» в результат Вашей деятельности? какими практиками пользуетесь в процессе и для улучшения процесса разработки?
Практика, которой мы следуем описана здесь scottchacon.com/2011/08/31/github-flow.html.
Основной принцип: получить максимум продуктивности от всех участников проекта, а не привести всех в одному знаменателю. Под продуктивностью подразумевается кол-во «качественного» кода в единицу времени.
правильно ли я понимаю, что у Вас, отсутствует «команда» как таковая? есть разрозненные (географически или по другому принципу) участники проекта, которые никак не взаимодействуют, не обмениваются опытом кроме как через код?

как Вы меряете «качество», какие средства и подходы используете для подсчёта «качественного кода в единицу времени»?
Вся команда находится территориально в одном городе и офисе. Код пишется и из офиса и из дома и из другого города и даже когда нет соединения с сетью вовсе, днем/ночью, в любое время. В этом плане мы ничем не ограничены.
Качество кода мы измеряем кол-вом матных слов сказаных в единицу времени при ревью этого кода.
Обмен опытом у нас происходит в любое удобное время и когда есть желание, время и мотивация (обеих сторон).
Зарегистрируйтесь на Хабре , чтобы оставить комментарий