Comments 18
Чем дольше код стоит на инспекции, тем больше шансов, что код в репозитории изменится, придется мерджить и вновь выставлять на инспекцию. Такой процесс может затягиваться на недели. Пока у нас нет стандартного решения этой проблемы и каждый подобный случай решаем индивидуально. Возникают ли у вас такие ситуации?
0
Мы для избежания таких проблем стараемся во-первых, ставить задачам по инспекции более высокий приоритет по сравнению с обычной разработкой, а во-вторых разрабатывать небольшими законченными кусками, что бы инспектору не приходилось неделями сидеть и разбираться что же там такое написали.
+1
Мы решаем эту проблему так же, как описали здесь:
1. Мы реализуем новый функционал в отдельных ветках.
2. Каждая большая задача всегда разбивается на подзадачи.
3. Разработчик отдаёт код на инспекцию вменяемыми законченными частями.
4. Приоритет на инспекцию у нас ниже только критических уязвимостей.
1. Мы реализуем новый функционал в отдельных ветках.
2. Каждая большая задача всегда разбивается на подзадачи.
3. Разработчик отдаёт код на инспекцию вменяемыми законченными частями.
4. Приоритет на инспекцию у нас ниже только критических уязвимостей.
+2
Все верно. Не представляю как вообще можно мержить чью-то ветку, не просмотрем код и не прогнав тесты.
У нас в команде принято так:
До ревью отвечает за код разработчик, после ревью за возможные проблемы отвечает тот, кто просматривал и мержил код. В таком случае ответственность за свои действия на достаточно высоком уровне и народ перестает писать что попало.
У нас в команде принято так:
До ревью отвечает за код разработчик, после ревью за возможные проблемы отвечает тот, кто просматривал и мержил код. В таком случае ответственность за свои действия на достаточно высоком уровне и народ перестает писать что попало.
+1
Я правильно понял, что вы написали, что разработчик перестает нести ответственность за свой код после ревью? Так что тогда ему мешает писать код таким образом, лишь бы он прошел ревью, а если будет глючить потом, то и так сойдет?
+3
У нас всё проще — в системе контроля версий стоит pre-commit hook, который проверяет наличие строки «reviewer: %username%» или «pending-reviewer: %username%». При её отсутствии коммит не проходит.
Соответственно, если изменения кода существенны, ты зовёшь на ревью человека, который хорошо разбирается в коде, с которым ты работал. Если же это какие-нибудь незначительные поправки — вписываешь этого человека как pending-reviewer, а затем с помощью FishEye генерируется post-commit review.
Соответственно, если изменения кода существенны, ты зовёшь на ревью человека, который хорошо разбирается в коде, с которым ты работал. Если же это какие-нибудь незначительные поправки — вписываешь этого человека как pending-reviewer, а затем с помощью FishEye генерируется post-commit review.
+1
CodeCollaborator — отличная штука. На прошлом проекте купили лицензию и с удовольствием пользовались.
Справедливости ради стоит отметить, что если ваша система контроля версий поддерживает shelving (как, например, Perforce), то ревью кода можно проводить и просто через электронную почту, эффективность это не слишком убавляет.
Справедливости ради стоит отметить, что если ваша система контроля версий поддерживает shelving (как, например, Perforce), то ревью кода можно проводить и просто через электронную почту, эффективность это не слишком убавляет.
+2
Мы в команде практикуем pre-commit review: написал код -> сделал патч -> отправил на группу (email) -> получил два одобрения -> commit. По патчу, однако, сложно судить об общей логике изменений. Лучше всего проверяется стиль кодирования :) Но и ошибки находятся, так что практика однозначно полезная.
+2
pre-commit review на практике оказывается уж очень напрягающим
Мы просто задачу из in progress перевешиваем в review, и только потом в test/done. review проходят обычно на следующий день, в редких случаях — через неделю.
Мы просто задачу из in progress перевешиваем в review, и только потом в test/done. review проходят обычно на следующий день, в редких случаях — через неделю.
0
А насколько это удобно работать через патчи если quilt не используется? Ну то есть — есть таск в трекере, кто то сделал бранч, поработал, получил патч, выложил в трекере, его посмотрел ревьювер, ок, потом запушили. Не очень удобно для не больших проектов.
Вот другой случай — идет большая монотонная работа по разработке, дескритизация тасков низкая. Хочется ревьювить ежедневные комиты. Чем удобно пользоваться?
Вот другой случай — идет большая монотонная работа по разработке, дескритизация тасков низкая. Хочется ревьювить ежедневные комиты. Чем удобно пользоваться?
0
Мне кажется что мы с Колей Алименковым достаточно хорошо раскрыли тему практики Code Review. Не буду много писать — если интересно, посмотрите запись нашего доклада на AgileDays 2011 vimeo.com/22736643
0
Исходя из заголовочной картинки, Code Review оставит вас без штанов!
0
Sign up to leave a comment.
Внедрение инспекций кода в процесс разработки