Миф о документации, продолжение

[gaperton]

И самое интересное - стоит сказать про "документацию" правду, которую в глубине души и так все знают, - и это обычно провоцирует бурление говн, и поток самых невероятных высказываний.

Давайте посмотрим, почему же люди пишут документы тогда, когда они их действительно пишут, а не рассуждают о том, как бы хорошо было, если бы они были, и как плохо,

Comments

[melkus]

>Достаточно запретить все коммиты, в комментариях к которым не указана фамилия проверяющего.

А как технически осуществляется доставка кода проверяющему, его же может быть много? Или просто позвать за свой комп?

[gaperton]

Например - через систему контроля версий, привязку коммита к тикету, и переназначение тикета на проверяющего, который перенесет коммит в главную ветку.

Есть и другие варианты с использованием спецсредств, например, Atlassian Crucible.

А можно показать изменения с экрана своего компьютера, и заодно объяснить их - это самое простое.

[melkus]

Меня пугает сложность всего этого, коммит в спец ветку, потом переброс кода в основную. Он конечно гарантирует то что код будет просмотрен, но нужна ли нам эта гарантия за эти накладные расходы?

[gaperton]

Первая схема опирается на схему репозитория с параллельными ветками dev/release. Ровным счетом ничего страшного. dev - это trunk, туда делается коммит с пост-коммит ревью.

Накладных расходов почти нет - ревью делается тычками в файлы коммита в описании задачи в трекере. Ссылки ведут на diff в вебморде VCS. Это - результат интеграции трекера и VCS. И это действительно удобно. Людям нравится.

Crucible, и прочие тулы для code review, позволяет реализовать более гибкие схемы.

[melkus]

Ага понял, т.е. заранее закладывается в накладные расходы что есть отдельно dev/release и вечный merge. Согласен, тут мало накладных расходов, это не слияние двух веток после 3 месяцев независимого существования.

Я правильно понимаю что dev ветка заводится только под багфиксинг?
Потому что если там колбасить новый код или например менять архитектуру то может пойти сильное расхождение с release веткой, что сделает невозможным быстрый перенос кода по некоторым модулям.

[dr_cha0s]

Ну для этого как минимум раз в неделю надо в отдельную ветку всасывать изменения из главной ветки.

[gaperton]

> Я правильно понимаю что dev ветка заводится только под багфиксинг?

Нет. Под все.

> Потому что если там колбасить новый код или например менять архитектуру то может пойти сильное расхождение с release веткой, что сделает невозможным быстрый перенос кода по некоторым модулям.нто

Для длинных изменений как и в обычной ситуации надо заводить feature branch, И никаких вариантов здесь нет. Невозможно делать "быстрый перенос" не тестированного кода с "изменениями архитектуры" ни в какой схеме.

[melkus]

Ага, понятно.
Немного не по теме:
Мне кажется или Вы работает в крупных проектах?
Я просто пытаюсь на себя примерить и понимаю что некоторые вещи полезны, но не сейчас, а когда скажем будет человек 20 в команде.

[gaperton]

Я работал в самых разных проектах начиная с 96 года. Вас интересует, начиная с какого объема команды перечисленное начинает приносить практическую пользу?

Начиная с 6-10 человек уже целесообразно. И надо добавить, что я говорю про случай, когда работа не носит заказной и разовый характер, а подразумевает последующую поддержку и развитие написанного.

[hedgeov]

Если есть соглашение "тикет на отдельной ветке" -- проверяющему высылается имя ветки, которую надо смотреть. При этом процесс может выглядеть так: Тикет имеет состояния "решено", "ревьюировано" и "интегрировано". Ревью имеет свой собственный жизненный цикл с состояниями "создано", "состоялось", "отклонено", "исправлено", "закрыто". Ревью разрешается инициировать когда у тикета состояние "решено". Ревью создается, при этом указывается имя ветки, в которую надо смотреть. После того как ревьюер посмотрел в указанную ветку и налабал массу замечаний, ревью считается "состоявшимся". После того как автор все замечания устранил на той же самой ветке, ревьюер смотрит на результат и либо меняет состояние на "исправлено", либо на "отклонено". Если "отклонено", то автор продолжает исправлять, пока ревьюер не согласится. Если состояние "исправлено", то автор закрывает ревью (переводит в состояние "закрыто"). После этого, когда тикет в состоянии "исправлено" и ревью в состоянии "закрыто", можно мержить изменения с ветки в trunk, после чего

[melkus]

В случае если фикс занимает 10 минут, что иногда встречается, проще позвать человека к своему монитору. Ваш вариант мне нравится когда я начинаю думать о больших изменениях, а использовать ветки для багов и мелких тикетов мне кажется расточительством.

[hedgeov]

Я за унифицированный процесс вне зависимости от сложности изменений. "В каждом безобразии должно быть единообразие" -- когда процесс один и без исключений -- его проще запомнить и применять. Опять же, не всегда ревьюер физически способен к монитору подойти (из другой страны он например). На самом деле не так много времени это веткотворение занимает.

Самый большой плюс веток на мой взгляд -- простота разбора коллизий, возможность быстро и безболезненно выкинуть кривой багфикс если что-то пошло не так. Если все изменения на mainline -- просто так середину не выкинешь и придется сравнительно долго согласовывать между авторами откаты и перевнесение изменений.