Не я один построил свою систему-вспомогашку поверх гитлаба, приятно знать :) У нас всё с одной стороны похоже, а с другой - совсем не похоже, но суть 100% та же. Удачи в развитии проекта!
Отдельные камиты никак не мешают быстро получать обратную связь от юнит (и других) тестов. Просто упаковывайте в каждый камит не только код, но и тесты, что в общем, и рекомендуется. Подход проверялся на практике, работает. Программисты принимают его умеренно-позитивно, умеренно - те, кто не хочет осваивать в гите искуссиство слияния и разделения камитов, а позитивно - тем, кому это интересно освоить.
Хоть статья и рекламная, добавлю еще одно соображение: делить работу на N МРов обычно не работает, если приняты строгие стандарты оформления МР - просто слишком трудоемко и само собой эта практика сходит на нет, если, конечно, тимлид не зверь (а зверем быть не надо).
С другой стороны, и автор тут транслирует старую истину, большие МРы проверяют а) долго б) поверхностно.
Есть ли компромисс? Компромисс есть: надо создавать один МР, но в нем организовывать камиты так, чтобы каждый камит имел отдельный, четкий, понятный смысл, описанный в камит-мессадже.
Тогда ревьювер может не проверять весь МР, а проверять МР по камитам и делать между ревью паузу, осталяя в МР сообщения типа "камит 3 - ОК".
Это всё равно требует хлопот от автора МРа (двигать камиты, объединять камиты), но сие есть гораздо более реалистичный сценарий, чем 10 МРов на задачу.
Представляется, что предложенный подход всё же лучше, хотя бы тем, не нужно переписывать методы выше по стеку на использование указанного враппера.
Генератор - не мой, но у нас он покрыл все случаи, а таких методов было несколько сотен. Да, генератор не всесилен, но он достаточно хорош для решения обсуждаемой задачи.
Про деградацию склонен согласиться, может быть допустимо в каких-то случаях, но зачем, если можно без неё?
Если я правильно Вас понял, в кодовой базе есть два метода, один асинк, второй синк с обсолетом. Это не означает одного источника правды! Если исправляется баг в асинк методе, его же надо будет исправить и в синк, несмотря на обсолет.
В любом случае, Ваши сомнения понятны, но ценность данной заметки в том, чтобы поделиться опытом, предложенная миграция - это ретроспектива реального опыта, а не теоретическое предложение. Работает.
Не я один построил свою систему-вспомогашку поверх гитлаба, приятно знать :) У нас всё с одной стороны похоже, а с другой - совсем не похоже, но суть 100% та же. Удачи в развитии проекта!
Отдельные камиты никак не мешают быстро получать обратную связь от юнит (и других) тестов. Просто упаковывайте в каждый камит не только код, но и тесты, что в общем, и рекомендуется. Подход проверялся на практике, работает. Программисты принимают его умеренно-позитивно, умеренно - те, кто не хочет осваивать в гите искуссиство слияния и разделения камитов, а позитивно - тем, кому это интересно освоить.
Удачи!
Хоть статья и рекламная, добавлю еще одно соображение: делить работу на N МРов обычно не работает, если приняты строгие стандарты оформления МР - просто слишком трудоемко и само собой эта практика сходит на нет, если, конечно, тимлид не зверь (а зверем быть не надо).
С другой стороны, и автор тут транслирует старую истину, большие МРы проверяют а) долго б) поверхностно.
Есть ли компромисс? Компромисс есть: надо создавать один МР, но в нем организовывать камиты так, чтобы каждый камит имел отдельный, четкий, понятный смысл, описанный в камит-мессадже.
Тогда ревьювер может не проверять весь МР, а проверять МР по камитам и делать между ревью паузу, осталяя в МР сообщения типа "камит 3 - ОК".
Это всё равно требует хлопот от автора МРа (двигать камиты, объединять камиты), но сие есть гораздо более реалистичный сценарий, чем 10 МРов на задачу.
Я не понял до конца Ваш комментарий, но методов несколько сотен. Основное - БД, есть также диск и сеть.
Представляется, что предложенный подход всё же лучше, хотя бы тем, не нужно переписывать методы выше по стеку на использование указанного враппера.
Генератор - не мой, но у нас он покрыл все случаи, а таких методов было несколько сотен. Да, генератор не всесилен, но он достаточно хорош для решения обсуждаемой задачи.
Про деградацию склонен согласиться, может быть допустимо в каких-то случаях, но зачем, если можно без неё?
Если я правильно Вас понял, в кодовой базе есть два метода, один асинк, второй синк с обсолетом. Это не означает одного источника правды! Если исправляется баг в асинк методе, его же надо будет исправить и в синк, несмотря на обсолет.
В любом случае, Ваши сомнения понятны, но ценность данной заметки в том, чтобы поделиться опытом, предложенная миграция - это ретроспектива реального опыта, а не теоретическое предложение. Работает.
Спасибо за мнение!
Вероятно, Вы неправильно поняли смысл статьи. Как раз микроменеджментом в классическом понимании тут и не пахнет.
да, я это указал.
если под этим мы понимаем количество МР в единицу времени, то нет, такого не наблюдается.
спасибо за комментарии!
конечно, не обладая ресурсами и властью, реализовать такие реформы не получится.
к счастью, не на бумаге =)
Полагаю, если бы это писала нейросеть, то было бы как раз ЗС =) Да, МР это запрос за слияние.