Блядь, я работала в таком месте. Ну ОК, там продвинулись уже до понимания бранчей и мерджей. Но каждый хотел анально отгородиться навсегда на своем бранче, на несколько месяцев. Потому что если continuous integration, то ОНИ будут все время портить мой красивый код ИХ тупыми изменениями. Но я их постепенно заставила родину любить осознать, что защищать свой красивый код от чужих уродств надо тестами, а не бранчами.
от уродств к сожалению никакие тесты не помогают. скорее усугубляют, поскольку уродовать будуть до тех пор, пока тесты не пройдут. так что только reviews.
Ревьюз - это они умели, да. Вот так через три месяца вываливали на тебя все написаное - проверяй, родной, ни в чем себе не отказывай. А что там от ближайшего общего предка и бранч, и latest уже так далеко уехали, что ни один дифф не справляется - ну такая судьба наша горькая.
Если серьезно, то уродство же только условное. Каждый считал других врагами, которые только спят и видят, как поломать его код. На самом деле все были довольно неплохие программисты, и с современным процессом вокруг себя довольно быстро все переменилось.
Но я как вспомню эти споры с начальством (что? мы и так умираем на каждом мердже, ты хочешь мерджить ЧАЩЕ?!!), так до сих пор плакать хочется.
К сожалению так складывалась карьера, что дошла до черного пояса в виде боевых искусств influencing without authority.
Начальство переубеждается картинками - вот так будет выглядеть новый процесс, вот здесь сэкономим время на двухдневной "интеграции", вот здесь - можно будет отказаться от stabilization phase, aka "а теперь со всей этой хуйней мы попробуем взлететь".
Еще полезно с фактами в руках рассказывать про industry best practices, к примеру, про version strategies есть отличная книжка с картинками: http://www.bradapp.com/acme/branching/
Когда можно сказать - вот научный диагноз нашей болезни, вот методы лечения, вот истории успешно исцеленных - это действует лучше, чем просто возмущение "мне так не нравится".
Кроме картинок и медицинских энциклопедий, начальство любит страшные истории. Например, про неуловимый semantic conflict.
Это все относится к относительно вменяемому и не злокозненному начальству, совсем уж злокачественные случаи переубедить нельзя.
>Что большое изменение может быть и смёржится, но в нём могут появиться баги, которых не было ни в одной ветке до мёржа?
Да, потому что конфликты на уровне, который дифф не отловит. Ну вот адский пример, но не могу сходу лучше придумать: на одном бранче в функцию добавили side effect, и даже правильно это обработали в единственном вызове этой несчастной функции. А в это время в другом бранче добавили три новых вызова. Из другого файла. И все смержится чистенько.
Я к svn и Perforce хорошо отношусь. Git пробовала, у него те же концептуальные проблемы, если использовать feature branch. Только он почему-то дает людям иллюзию, что проблем меньше. Допускаю, что я просто не была в ситуации, где его преимущество в смысле D для чего-то важно. А когда оно не важно, то это просто добавляет сложности.
Спасибо, это хорошая иллюстрация semantic conflict. У меня это всё воспринималось на невербальном уровне - что если merge большой, то проблемы при merge - ещё больше. Собственно, это не только merge касается, но и простых commits.
no subject
Date: 2015-04-30 04:57 pm (UTC)навсегдана своем бранче, на несколько месяцев. Потому что если continuous integration, то ОНИ будут все время портить мой красивый код ИХ тупыми изменениями. Но я их постепенно заставилародину любитьосознать, что защищать свой красивый код от чужих уродств надо тестами, а не бранчами.no subject
Date: 2015-04-30 09:15 pm (UTC)И то, и другое - можно без хлеба
Date: 2015-04-30 09:26 pm (UTC)Если серьезно, то уродство же только условное. Каждый считал других врагами, которые только спят и видят, как поломать его код. На самом деле все были довольно неплохие программисты, и с современным процессом вокруг себя довольно быстро все переменилось.
Но я как вспомню эти споры с начальством (что? мы и так умираем на каждом мердже, ты хочешь мерджить ЧАЩЕ?!!), так до сих пор плакать хочется.
Re: И то, и другое - можно без хлеба
Date: 2015-04-30 09:42 pm (UTC)хе-хе.. ну так отправить делать бранч апгрейд самостоятельно to the latest trunk.. И еще три месяца покоя есть ;)
А вообще feature branches это как атомное оружие. Дикарям в руки лучше не давать. Ну или только под полным контролем.
Re: И то, и другое - можно без хлеба
Date: 2015-05-01 12:07 am (UTC)Как вам удалось переубедить начальство?
Re: И то, и другое - можно без хлеба
Date: 2015-05-01 11:25 pm (UTC)Начальство переубеждается картинками - вот так будет выглядеть новый процесс, вот здесь сэкономим время на двухдневной "интеграции", вот здесь - можно будет отказаться от stabilization phase, aka "а теперь со всей этой хуйней мы попробуем взлететь".
Еще полезно с фактами в руках рассказывать про industry best practices, к примеру, про version strategies есть отличная книжка с картинками: http://www.bradapp.com/acme/branching/
Когда можно сказать - вот научный диагноз нашей болезни, вот методы лечения, вот истории успешно исцеленных - это действует лучше, чем просто возмущение "мне так не нравится".
Кроме картинок и медицинских энциклопедий, начальство любит страшные истории. Например, про неуловимый semantic conflict.
Это все относится к относительно вменяемому и не злокозненному начальству, совсем уж злокачественные случаи переубедить нельзя.
Re: И то, и другое - можно без хлеба
Date: 2015-05-01 11:47 pm (UTC)Я уже забыл про это чудо.
Но ведь было, было такое в моей карьере.
> неуловимый semantic conflict
Что большое изменение может быть и смёржится, но в нём могут появиться баги, которых не было ни в одной ветке до мёржа?
Кстати, это всё про SVN и ему подобные.
Вы не пробовали Git (или другой DVCS)?
Re: И то, и другое - можно без хлеба
Date: 2015-05-01 11:56 pm (UTC)Да, потому что конфликты на уровне, который дифф не отловит. Ну вот адский пример, но не могу сходу лучше придумать: на одном бранче в функцию добавили side effect, и даже правильно это обработали в единственном вызове этой несчастной функции. А в это время в другом бранче добавили три новых вызова. Из другого файла. И все смержится чистенько.
Я к svn и Perforce хорошо отношусь. Git пробовала, у него те же концептуальные проблемы, если использовать feature branch. Только он почему-то дает людям иллюзию, что проблем меньше. Допускаю, что я просто не была в ситуации, где его преимущество в смысле D для чего-то важно. А когда оно не важно, то это просто добавляет сложности.
Re: И то, и другое - можно без хлеба
Date: 2015-05-02 12:12 am (UTC)Спасибо, это хорошая иллюстрация semantic conflict.
У меня это всё воспринималось на невербальном уровне - что если merge большой, то проблемы при merge - ещё больше.
Собственно, это не только merge касается, но и простых commits.
no subject
Date: 2015-04-30 09:09 pm (UTC)no subject
Date: 2015-04-30 11:29 pm (UTC)no subject
Date: 2015-05-01 07:25 am (UTC)