Здравствуйте, Qbit86, Вы писали:
Q>«Сделанная фича» может быть на разных уровнях готовности. Между «собирается и вроде как работает» и «вычищена так, что FxCop носа не подточит» может пролегать много времени. Запрет не коммит до выполнение этих задач — это как запрет автору статьи нажимать Save в Word'е, пока текст не прочитает корректор. Вы предлагаете, перед уходом работы не сохранять рабочую копию? Я не хочу так рисковать дневными наработками.
Я предлагаю писать в сорс контрол тогда и только тогда, когда вы можете выразить суть изменения осмысленной записью в логе. Запись "рабочий день кончился" не является осмысленной, как и отсутствие какой-либо записи.
Если программисты не могут выразить суть своей деятельности записями в логе, значит у вас что-то не так, либо у них в голове, либо в вашей организации.
А если вы боитесь потерять файлы, вам нужна система бакапов, а не сорс контрол.
Pzz>>Это значит, что у вас слишком много бюрократии в текущей ветке. Разработчики должны свободно коммитить в текущую ветку при условии, что они предпринимают разумное количество усилий не сломать программу. Т.е., как минимум, перед коммитом надо убедиться в том, что программа собирается, и если изменения затрагивают уже работающий код, хоть слегка его оттестировать.
Q>В изолированной ветке разработчика бюрократии нет, она прикручена только к транку. Но при желании допустимо прикрутить бюрократию к какой-нибудь feature branch. И это называется не бюрократия, а планка качества.
Если у вас планка качества поднята столь высоко, что постоянно мешает работать, это не планка качества, а бюрократия.
Я очень рекомендую доверять разрабочикам коммитить в общий сорс контрол, а всякие там code review делать в режиме постмодерирования. Осознание того факта, что ошибка разработчика станет проблемой для многих людей, очень повышает уровень ответственности в коллективе и способствует профессиональному росту ваших людей (кроме очень редких исключений, но от тех, кто не хочеть взрослеть, надо постепенно избавляться).
Pzz>>...при условии, что они предпринимают разумное количество усилий не сломать программу. Т.е., как минимум, перед коммитом надо убедиться в том, что программа собирается, и если изменения затрагивают уже работающий код, хоть слегка его оттестировать.
Q>«Убеждаться» должна машина. Проверка условий должна выполняться автоматически. Как я могу доверить коллегам не забывать следить за качеством их кода, если я не доверяю даже себе?
В этом заключается ваша огромная проблема. Если вы поручаете что-то людям, вы должны им доверять. Несмотря на тот факт, что они 1) ошибаются 2) делают все не так, как сделали бы вы 3) не понимают, что идеальная модель жизни, существующая в вашей голове, воистинну идеальна
Важно добиваться не того, чтобы не было ошибок (так не бывает). Важно добиваться того, чтобы последствия ошибок быстро исправлялись
Здравствуйте, Pzz.
Q>>«Сделанная фича» может быть на разных уровнях готовности. Между «собирается и вроде как работает» и «вычищена так, что FxCop носа не подточит» может пролегать много времени. Запрет не коммит до выполнение этих задач — это как запрет автору статьи нажимать Save в Word'е, пока текст не прочитает корректор. Вы предлагаете, перед уходом работы не сохранять рабочую копию? Я не хочу так рисковать дневными наработками.
Pzz>Я предлагаю писать в сорс контрол тогда и только тогда, когда вы можете выразить суть изменения осмысленной записью в логе.
1) Предположим, я могу выразить суть изменения осмысленной записью в логе, например: «Для задачи A выполнены подзадачи A1, A2, A3», и, закономерно, хочу сохранить историю своей работы. 2) Но к концу дня подзадачи A4, A5, A6 ещё не сделаны, я не хочу публиковать фрагменты недоделанной задачи A, так как она помешает другим. Из вашего критерия и из (1) следует, что коммитить надо. Из (2) следует, что коммитить надо не в транк (или общую ветку). Ч.т.д.
Pzz>А если вы боитесь потерять файлы...
Я боюсь потерять не только файлы, но и историю их изменений.
Pzz>вам нужна система бакапов, а не сорс контрол.
0_о Вы это всерьёз?
Pzz>Если у вас планка качества поднята столь высоко, что постоянно мешает работать, это не планка качества, а бюрократия.
Она не мешает работать.
Из-за переезда на другой сервер какое-то время работали без «бюрократии». Спасибо, но все хотят обратно.
Pzz>Я очень рекомендую доверять разрабочикам коммитить в общий сорс контрол, а всякие там code review делать в режиме постмодерирования.
Доверяй, но проверяй. И некоторые проверки кода автоматика делает гораздо эффективнее, чем человек.
Pzz>Осознание того факта, что ошибка разработчика станет проблемой для многих людей, очень повышает уровень ответственности в коллективе и способствует профессиональному росту ваших людей (кроме очень редких исключений, но от тех, кто не хочеть взрослеть, надо постепенно избавляться).
Да вам и тестеры не нужны! У вас разработчики же ответственные. И — да, ремни безопасности придумали трусы.
Q>>«Убеждаться» должна машина. Проверка условий должна выполняться автоматически. Как я могу доверить коллегам не забывать следить за качеством их кода, если я не доверяю даже себе?
Pzz>В этом заключается ваша огромная проблема.
В вашем предложении содержится ложная пресуппозиция.
Pzz>Если вы поручаете что-то людям, вы должны им доверять.
Не поручаю, потому что я не менеджер, я разработчик. И со своей стороны, я не требую, чтобы мне мне доверяли. Я хочу, чтобы проверяли и оспаривали. Это помогает совершенствоваться.
Pzz>...не понимают, что идеальная модель жизни, существующая в вашей голове, воистинну идеальна :-)
Так кто же из нас живёт в стране эльфов? Вы себе противоречите. И снова опираетесь на ложную пресуппозицию.
Pzz>Важно добиваться не того, чтобы не было ошибок (так не бывает). Важно добиваться того, чтобы последствия ошибок быстро исправлялись
Совершенно верно. Поэтому о любой ошибке (из довольно широкого класса), закомиченной в транк, разработчиков быстро оповестит сервер непрерывной интеграции.
Здравствуйте, Qbit86, Вы писали:
Q>1) Предположим, я могу выразить суть изменения осмысленной записью в логе, например: «Для задачи A выполнены подзадачи A1, A2, A3», и, закономерно, хочу сохранить историю своей работы. 2) Но к концу дня подзадачи A4, A5, A6 ещё не сделаны, я не хочу публиковать фрагменты недоделанной задачи A, так как она помешает другим. Из вашего критерия и из (1) следует, что коммитить надо. Из (2) следует, что коммитить надо не в транк (или общую ветку). Ч.т.д.
Я бы провел A1, A2 и А3 отдельными коммитами. Это почти всегда возможно.
Pzz>>А если вы боитесь потерять файлы...
Q>Я боюсь потерять не только файлы, но и историю их изменений.
Ну, если пункты в вашей истории проставлены так же случайно, как люди нажимают кнопку Save, то что в ней ценного?
Pzz>>вам нужна система бакапов, а не сорс контрол.
Q>0_о Вы это всерьёз?
Да, я это всерьез. Если вы коммитите в сорс контрол с целью не потерять, вы используете его в качестве бакапа. Сорс контрол, конечно, обладает кроме всего прочего функцией бакапа, но это далеко не самое важное его свойство и даже не одно из основных.
Pzz>>Если у вас планка качества поднята столь высоко, что постоянно мешает работать, это не планка качества, а бюрократия.
Q>Она не мешает работать. Q>Из-за переезда на другой сервер какое-то время работали без «бюрократии». Спасибо, но все хотят обратно.
Если у вас поход в туалет требует сложного 20-минутного ритуала, это бюрократия. Однако если туалет вовсе закрыть, все будут хотеть его обратно. Не потому, что заскучают по бюрократии, а потому, что совсем без туалета еще хуже.
Pzz>>Я очень рекомендую доверять разрабочикам коммитить в общий сорс контрол, а всякие там code review делать в режиме постмодерирования.
Q>Доверяй, но проверяй. И некоторые проверки кода автоматика делает гораздо эффективнее, чем человек.
Все хорошо вмеру. Если рутиный коммит предполагает двухчасовые прогоны теста, у вас проблема: никто не захочет делать рутиные коммиты.
Pzz>>Осознание того факта, что ошибка разработчика станет проблемой для многих людей, очень повышает уровень ответственности в коллективе и способствует профессиональному росту ваших людей (кроме очень редких исключений, но от тех, кто не хочеть взрослеть, надо постепенно избавляться).
Q>Да вам и тестеры не нужны! У вас разработчики же ответственные. И — да, ремни безопасности придумали трусы.
Это вам тестеры не нужны, вы их функцию пытаетесь переложить на разработчиков. Советую еще выдать разработчикам веник и тряпочку, тогда и уборщицы станут не нужны
Здравствуйте, Pzz, Вы писали:
Pzz>Я бы провел A1, A2 и А3 отдельными коммитами. Это почти всегда возможно.
Наоборот. Это почти всегда нарушает инварианты транка.
Q>>Я боюсь потерять не только файлы, но и историю их изменений.
Pzz>Ну, если пункты в вашей истории проставлены так же случайно, как люди нажимают кнопку Save, то что в ней ценного?
Во-первых, не так же случайно (к слову про осмысленный лог). Во-вторых, не хочется терять возможность откатиться назад, причём гранулярность шага не должна быть большой. Например, чтобы обнаружить момент возникновения ошибки, см. функцию «hg bisect».
Pzz>>>вам нужна система бакапов, а не сорс контрол.
С таким же успехом я могу сказать, что вам, судя по всему, нужна расшаренная папка, а не сорс контрол.
Pzz>Если вы коммитите в сорс контрол с целью не потерять, вы используете его в качестве бакапа.
Я коммичу с разными целями, которые иногда вступают в противоречие. Суть этого противоречия я изложил выше. Для решения этих противоречий в системах контроля версий предусмотрен механизм ветвления. Я не понимаю, почему вы так рьяно оспариваете его необходимость.
Pzz>Сорс контрол, конечно, обладает кроме всего прочего функцией бакапа, но это далеко не самое важное его свойство и даже не одно из основных.
Ну да, бэкап не основное, история не основное, ветвление не нужно — вам точно больше подойдёт расшаренная папка. (Прочувствовали всю бестолковость подобного рода импликаций?)
Pzz>Если у вас поход в туалет требует сложного 20-минутного ритуала, это бюрократия. Однако если туалет вовсе закрыть, все будут хотеть его обратно. Не потому, что заскучают по бюрократии, а потому, что совсем без туалета еще хуже.
Туалет-то всегда открыт, только он может быть грязным и зловонным. Скучают-то по чистоте и уюту.
Pzz>Все хорошо вмеру. Если рутиный коммит предполагает двухчасовые прогоны теста, у вас проблема: никто не захочет делать рутиные коммиты.
Ни в коем случае, рутинный коммит делается в свою изолированную ветку, быстро и надёжно, как автомат Калашникова. В том и соль.
Pzz>Это вам тестеры не нужны, вы их функцию пытаетесь переложить на разработчиков.
Чего? У меня начинают закрадываться смутные сомнения. Скажите, что такое модульные тесты? Кем они пишутся, для кого?
Pzz>Советую еще выдать разработчикам веник и тряпочку, тогда и уборщицы станут не нужны :-)
Так ведь это в вашем мире время разработчика не ценится. Он должен проверять, что коллега не забыл добавить файл в репозиторий (коллега не сможет отловить такую ошибку локально, в его рабочей копии всё на месте). Должен проверять, что регрессионные тесты проходят, что нет битых ссылок на библиотеки (работающих в окружении коллеги). Можно и тряпочку с веником ему заодно дать, программисты ж многопрофильные.
В моём мире — всё что может делать автоматика, лучше ей и доверить. Программист пусть свободное время на зарядку потратит.
Здравствуйте, Qbit86, Вы писали:
Q>Во-первых, не так же случайно (к слову про осмысленный лог). Во-вторых, не хочется терять возможность откатиться назад, причём гранулярность шага не должна быть большой. Например, чтобы обнаружить момент возникновения ошибки, см. функцию «hg bisect».
Если у вас hg, то для ваших целей, вероятно, лучше всего подходит hg mq.
Q>Ну да, бэкап не основное, история не основное, ветвление не нужно — вам точно больше подойдёт расшаренная папка. (Прочувствовали всю бестолковость подобного рода импликаций?)
Здравствуйте, Pzz, Вы писали:
Pzz>Если у вас hg...
У нас пока Svn, но происходит переход на Hg. Именно в связи с этим я и затевал последние пару-тройку топиков. Хочется настроить процесс оптимально, для того и консультируюсь с сообществом.
Pzz>...то для ваших целей, вероятно, лучше всего подходит hg mq.
Про Mq знаю. И то, что я про них знаю, говорит мне, что это почти ортогонально обсуждаемой теме :)
Q>>Ну да, бэкап не основное, история не основное, ветвление не нужно — вам точно больше подойдёт расшаренная папка. (Прочувствовали всю бестолковость подобного рода импликаций?)
Pzz>Ну это вы сейчас со своими фантазиями спорите.
по непрерывной интеграции. Транк в любой момент времени должен проходить перечисленные там проверки, это его инвариант.
Мы как-то пытались разрабатывать подобным образом — чтобы каждая ревизия в транке была идеальна чуть менее, чем полностью. В итоге отказались, т.к. в итоге разработка уехала в отдельные ветки, и легче оказалось поддерживать неидельный транк, решая проблемы по мере их возникновения (и возможности).
Здравствуйте, Qbit86, Вы писали: Pzz>>Я бы провел A1, A2 и А3 отдельными коммитами. Это почти всегда возможно. Q>Наоборот. Это почти всегда нарушает инварианты транка.
Значит задача А, разбитая на А1..Ан должна уйти в отдельную ветку.
Здравствуйте, Mr.Cat, Вы писали:
Pzz>>>Я бы провел A1, A2 и А3 отдельными коммитами. Это почти всегда возможно. Q>>Наоборот. Это почти всегда нарушает инварианты транка. MC>Значит задача А, разбитая на А1..Ан должна уйти в отдельную ветку. :xz:
Ну да, именно в этом я и пытался убедить Pzz. Чтобы можно было свободно коммитить, и при этом не интерферировать с пользователями транка.
Q>Не-не-не, так нельзя. «Коммит» выполняет функции кнопки «Save» в редакторах. Она всегда должна быть доступна, причём быстро, сохранение не должно быть многоэтапным. Сделал коммит, и ушёл домой. Сделал коммит, и приступаешь к рискованным операциям в рабочей папке. Сделал коммит — и спишь спокойно.
Q>Но в случае работы в транке, «Коммит» оказывается перегруженным, он выполняет ещё и функцию publishing'а кода. Со всеми вытекающими. Даже в случаях «мелких фич» быстрый комит уже сделать нельзя. Приходится делать апдейт, мерджить, разруливать конфликты — высокий риск потери незакоммиченных («несохранённых») данных. Если коммит прошёл гладко, то всё равно надо дожидаться отклика CI-сервера, прогона тестов, инспекции кода.
Меня уже удивляет как люди иногда, задавая вопросы, описывают множество деталей не описывая при этом какой результат надо получить.
Если нужен Save без publish, то вполне можно использовать такую фичу. В TFS она называется shelve, в SVN подобной нету, про другие СКВ не знаю.
по непрерывной интеграции. Транк в любой момент времени должен проходить перечисленные там проверки, это его инвариант.
"Должен проходить перечисленные там проверки" это как-то круто. Имеет смысл оценивать результаты билда с некоторой градацией. Напрмиер билды, которые не прошли проверки Stylecop — в релиз не пускать, но тестерам на ручное тестирование отдать можно.
Здравствуйте, Qbit86, Вы писали:
F>>ЗЫ. В случае разработки в транке такая ситуация разруливается автоматически — кто первый закоммитил — того и тапки. F>>Причём в 99% случаев такой конфликт обнаружится на раннем этапе — при первой же попытке коммита второго изменения.
Q>Ну и чем, в указанном тобой смысле, отличается «апдейт/коммит» от «синхронизация бранча с транком/синхронизация транка с бранчем»?
Не понял вопроса, поясни, плиз, что ты имеешь ввиду.
F>>А расскажи тогда, как при такой концепции разруливается ситуация исключающих друг друга изменений одних интерфейсов в двух бранчах?
Q>Во-первых, изменения интерфейсов (как наиболее уязвимых частей библиотеки, см. пункт Abstractions) всегда должны продумываться и согласовываться до внесения ломающих изменений. Q>Во-вторых, разруливаются примерно так же, как и при наличии исключающих друг друга изменений в разных рабочих копиях разных разработчиков при работе с единственным транком. В литературе по VCS такая штатная ситуация называется «Конфликт». Странно, что ты не слышал.
Тут фишка в том, сколько человек и на каком уровне должны продумывать такие изменения. Если требуется добавить дополнительный метод в класс или аргумент к методу, то это не обязательно требует участия Самого Главного Архитектора. А ещё — сколько человек должны заниматься интеграцией изменений. При разработке в транке нет необходимости в специальной роли "интегратор в транк". (Я не утверждаю, что это обязательно хорошо, но что это проще — да)
F>>И там и там в итоге имеется нехилый профит в функциональности — все довольны... до момента, когда это всё надо слить в trunk.
Q>Нет. Проблемы всплывут не во время вливания brahch→trunk, а во время синхронизации trunk→brahch. Последнее рекомендуется делать как можно чаще.
Совсем часто синхронизироваться не получится (вернее, делать содержательную синхронизацию) поскольку по твоей концепции изменения в транке должны полностью проходить все тесты. А это значит, что в случае изменения интерфейсов изменение будет довольно большим по объёму (соответственно, чем объёмней изменения, тем они реже).
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, gandjustas, Вы писали: G>Если нужен Save без publish, то вполне можно использовать такую фичу. В TFS она называется shelve, в SVN подобной нету, про другие СКВ не знаю.
В svn можно создать ветку и текущие изменения закоммитить туда.
Здравствуйте, frogkiller, Вы писали:
Q>>Ну и чем, в указанном тобой смысле, отличается «апдейт/коммит» от «синхронизация бранча с транком/синхронизация транка с бранчем»?
F>Не понял вопроса, поясни, плиз, что ты имеешь ввиду.
Имею в виду, что в приведённом тобой примере политика бранчевания работает как минимум не хуже, а по совокупности всех юз-кейзов — лучше, чем работа только в транке.
F>>>ЗЫ. В случае разработки в транке такая ситуация разруливается автоматически — кто первый закоммитил — того и тапки.
При branchy development синхронизация разработчиков тоже происходит через транк (только это не коммит в транк, а вливание ветви в транк). По тому же принципу приоритета тапок.
F>Тут фишка в том, сколько человек и на каком уровне должны продумывать такие изменения. Если требуется добавить дополнительный метод в класс или аргумент к методу, то это не обязательно требует участия Самого Главного Архитектора.
Упомянутое изначально добавление метода в интерфейс — требует, потому что это ломающее изменение. Код клиента твоего API перестанет компилироваться, если ты добавишь метод в интерфейс. И это безотносительно всяких систем контроля версий.
F>А ещё — сколько человек должны заниматься интеграцией изменений. При разработке в транке нет необходимости в специальной роли "интегратор в транк". (Я не утверждаю, что это обязательно хорошо, но что это проще — да)
Как правило, разработчик фичи и должен заниматься вливанием своей feature branch в транк. Ни о каком «интеграторе в транк» (в обсуждаемом простом случае) речи не идёт. Честно говоря, создаётся впечатления, что ты никогда не создавал ветки в Svn, и просто теоретизируешь чисто умозрительно. Ок, объясню. При коммите рабочей папки в транк ты _не_ разруливаешь конфликты. При вливании рабочей ветки в транк ты _не_ разруливаешь конфликты. Ты разруливаешь конфликты внутри рабочей папки при апдейте из транка. Ты разруливаешь конфликты в пределах рабочей ветки при односторонне направленной синхронизации с транком. В момент, когда ты готов влить ветвь в транк, твоя ветвь фактически содержит все наработки из транка плюс твои изолированные изменения. На момент вливания ветки в транк все конфликты уже разрешены.
F>>>И там и там в итоге имеется нехилый профит в функциональности — все довольны... до момента, когда это всё надо слить в trunk.
Q>>Нет. Проблемы всплывут не во время вливания brahch→trunk, а во время синхронизации trunk→brahch. Последнее рекомендуется делать как можно чаще.
F>Совсем часто синхронизироваться не получится (вернее, делать содержательную синхронизацию) поскольку по твоей концепции изменения в транке должны полностью проходить все тесты.
Ещё раз. Если я синхронизирую свой бранч с транком — вливаю (как можно чаще) чьи-то изменения из транка в свой бранч — как я при этом нарушу прохождение транком тестов? Под частой синхронизацией подразумевается частое чтение из транка, а не частое его изменение.
F>А это значит, что в случае изменения интерфейсов изменение будет довольно большим по объёму (соответственно, чем объёмней изменения, тем они реже).
Ну и? Конфликты — большие или маленькие — это объективная реальность, а не исключительная ситуация. Возможность конфликтов учтена во всех системах контроля версий. Вот только решать эти конфликты гораздо безопаснее в «чистой» рабочей копии изолированной ветки, чем в незакоммиченной рабочей копии, как это приходится делать при trunk only разработке. Количество же конфликтов, объём изменений и частота мерджей от этого не зависит.
Здравствуйте, Qbit86, Вы писали: Q>Под частой синхронизацией подразумевается частое чтение из транка, а не частое его изменение.
Вполне очевидно, что читать транк чаще, чем он меняется, невозможно. Поэтому высокая частота вливания из транка в бранчи подразумевает высокую частоту обратного процесса. В итоге, на мой взгляд, суперстабильный транк подходит для обмена изменениями только между супернезависимыми командами разработчиков.
Здравствуйте, Mr.Cat, Вы писали:
Q>>Под частой синхронизацией подразумевается частое чтение из транка, а не частое его изменение. MC>Вполне очевидно, что читать транк чаще, чем он меняется, невозможно. Поэтому высокая частота вливания из транка в бранчи подразумевает высокую частоту обратного процесса. В итоге, на мой взгляд, суперстабильный транк подходит для обмена изменениями только между супернезависимыми командами разработчиков.
Никто не отменял бранчи для обмена изменениями. У них могут быть более мягкие условия по отношению к стабильности.
Бранчи — они ж не только для изоляции, они ж ещё для коллаборации :)
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, gandjustas, Вы писали: G>>Если нужен Save без publish, то вполне можно использовать такую фичу. В TFS она называется shelve, в SVN подобной нету, про другие СКВ не знаю. MC>В svn можно создать ветку и текущие изменения закоммитить туда.
Только появляется геморрой со свитчем веток, их именованием и тому подобным. Это уже не работает как кнопка Save.
Здравствуйте, gandjustas, Вы писали: G>Только появляется геморрой со свитчем веток, их именованием и тому подобным. Это уже не работает как кнопка Save.
Ну не такой уж геморрой. Сделал ветку, свитчнулся, закоммитил. Имя можно выбрать любое, все равно это получается твоя приватная ветка.
