Code Review

[nyekimov]

прекратить... что именно? Поломки билдов, баги в софте или раздоры между группами?

для этого совета совсем недостаточно данных.
как можно давать совет по ср если проблемы похоже глубже?
ответ верхнего уровня - нужен правильный хороший деятельный менеджер. поставить туда.

Вопрос никак уладить раздор. Вопрос о существующих практиках в других местах

Ну практики как бы очевидны. От полной анархии и вольницы, до увольнения за сломанный билд (наверное где-то и такое есть). По статистике скорее всего практики где-то посередине. IMHO знание того что делается в другом месте никак не поможет решить вашу конкретную проблему. Ваша проблема не в технической области, а в области менеджмента и authority. Короче, кулаком надо стукнуть, сказать как надо (вы и сами сможете сообразить как надо) и наказывать за как не надо (а вот тут у вас authority-то и нет). Так что проблема не решаемая на вашем уровне.

Хороший коммент; поддерживаю.

Если sme выкатить идеальный pull request, то в чем проблема?

Чаще я вижу проблемы, когда человек не удосуживается исправляться, поработать над читательбностью. Оперативно не реагирует на вопросы или просьбы исправить код. Вместо этого бежит жаловаться, что его прессуют. И тут уже очень сильно зависит от менеджмента, кто то соображает поставить «спеца» на место, а некоторые менеджера даже начинают ругать ревьюверов. И вот для этого кстати не мешал бы свод правил, чтобы все знали критерии хорошего pull request -а. Свод правил будет позволять поставить и «вахтёра» на место.

[Херовимчик]

прекратить... что именно? Поломки билдов, баги в софте или раздоры между группами?

для этого совета совсем недостаточно данных.
как можно давать совет по ср если проблемы похоже глубже?
ответ верхнего уровня - нужен правильный хороший деятельный менеджер. поставить туда.

Вопрос никак уладить раздор. Вопрос о существующих практиках в других местах

мать, пора валить

Да ладно, и не таких мочили

[Херовимчик]

прекратить... что именно? Поломки билдов, баги в софте или раздоры между группами?

для этого совета совсем недостаточно данных.
как можно давать совет по ср если проблемы похоже глубже?
ответ верхнего уровня - нужен правильный хороший деятельный менеджер. поставить туда.

Вопрос никак уладить раздор. Вопрос о существующих практиках в других местах

Ну практики как бы очевидны. От полной анархии и вольницы, до увольнения за сломанный билд (наверное где-то и такое есть). По статистике скорее всего практики где-то посередине. IMHO знание того что делается в другом месте никак не поможет решить вашу конкретную проблему. Ваша проблема не в технической области, а в области менеджмента и authority. Короче, кулаком надо стукнуть, сказать как надо (вы и сами сможете сообразить как надо) и наказывать за как не надо (а вот тут у вас authority-то и нет). Так что проблема не решаемая на вашем уровне.

У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point

[Херовимчик]

Был в разных ситуациях.
…

Вот, вы меня хорошо поняли! Одно дело пара инвалидов и 3 PR в месяц, другое дело пол сотни народу, с десятками PR в день и частыми релизами

[KVA]

У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point

Тогда усядемся получше и бум наблюдать шоу.

[mister-X]

:

У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point

Тогда усядемся получше и бум наблюдать шоу.

+1
Компетишен внутри теамс, когда амбиции девелоперов заставляют работать их больше и быстрее. Отличная стратегия. Пилите Шура, пилите

[Херовимчик]

:

У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point

Тогда усядемся получше и бум наблюдать шоу.

+1
Компетишен внутри теамс, когда амбиции девелоперов заставляют работать их больше и быстрее. Отличная стратегия. Пилите Шура, пилите

Ну вот оппозиция также как и вы мыслит похоже что если согнать по-больше крутых перцев, то все можно решить в пользу «сильнейших». При этом их не смущает что вопрос с годами встал только острее

[mister-X]

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

[Херовимчик]

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

Мне за обязанность Бабы-Яги/Миротворца как раз хорошо доплачивают а нормальному начальству как раз нужно перенаправить излишки энергии в продуктивное русло, а не устраивать rat race на ровном месте

[alex_127]

У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point

мое мнение (может конечно неправильное) - как раз нужен authority. поскольку проблемы детского сада. вот если бы действительно непонятно было что и как делать то cr были бы одним из ваших наименьших проблем...

[Херовимчик]

У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point

мое мнение (может конечно неправильное) - как раз нужен authority. поскольку проблемы детского сада. вот если бы действительно непонятно было что и как делать то cr были бы одним из ваших наименьших проблем...

Однозначно ответа как делать правильно - нет. У всех подходов есть свои плюсы и минусы (наш продукт существует лет 8 уже, и много что было перепробовано, много шишек набито). Каждая сторона по-своему права.

Вообще удивительно что большинство воспринимает разногласия в процессах/мнениях между командами как конфликт, который требует вмешательства authority. Обычный рабочий момент

[alex_127]

У нас не принято пускать в ход authority (обе оппозиции имеют одинаковый вес тут). Верх инженерной мысли как раз найти совместное решение. И тут чужой опыт хороший data point

мое мнение (может конечно неправильное) - как раз нужен authority. поскольку проблемы детского сада. вот если бы действительно непонятно было что и как делать то cr были бы одним из ваших наименьших проблем...

Однозначно ответа как делать правильно - нет. У всех подходов есть свои плюсы и минусы (наш продукт существует лет 8 уже, и много что было перепробовано, много шишек набито). Каждая сторона по-своему права.

Вообще удивительно что большинство воспринимает разногласия в процессах/мнениях между командами как конфликт, который требует вмешательства authority. Обычный рабочий момент

Ну так как раз чтобы не было переливания и долгих бесполезных споров. "Мы посовещались и я решил"

[KVA]

Однозначно ответа как делать правильно - нет. У всех подходов есть свои плюсы и минусы (наш продукт существует лет 8 уже, и много что было перепробовано, много шишек набито). Каждая сторона по-своему права.

Вообще удивительно что большинство воспринимает разногласия в процессах/мнениях между командами как конфликт, который требует вмешательства authority. Обычный рабочий момент

Если за 8 лет не нашли согласия в процессах/мнениях, то и сейчас не найдете если будете nice. Если конфликт нужно решить сейчас, то это IMHO возможно только через authority (делай как я сказал, а не то ... )

[Vladimir Kr.]

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

- Если людей не хватает, то решается делегированием:
конкретно в вашем примере: (#2) должны проверять пре-апрувы доверенных TL&SME, a не ревьювить весь PR сами
- Вопросы архитектуры не должны всплывать на PR кода, архитектура решается до создания бранча
- самопиленные тулзы для линка систем? зачем, есть jira с прозрачной интеграцией процесса (тикет->бранч->PR->build->тикет), или аздо девопс gates, например https://docs.microsoft.com/en-us/azure/ ... -approvals (бранч->PR->deploy->test->merge)
- code style, code coverave, TDD/BDD, все это может SME/TL проверить - есть-ли покрытие фичи integration/functional test, или нет, соответственно апрувнуть, % покрытия и прочее; или автоматизировать - см. gates выше

вот если PR собираются, чтобы "научить и доказать", тогда надо звать authority

формализуйте правила PR не для бюрократии, а для удобства работы

[Херовимчик]

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

- Если людей не хватает, то решается делегированием:
конкретно в вашем примере: (#2) должны проверять пре-апрувы доверенных TL&SME, a не ревьювить весь PR сами
- Вопросы архитектуры не должны всплывать на PR кода, архитектура решается до создания бранча
- самопиленные тулзы для линка систем? зачем, есть jira с прозрачной интеграцией процесса (тикет->бранч->PR->build->тикет), или аздо девопс gates, например https://docs.microsoft.com/en-us/azure/ ... -approvals (бранч->PR->deploy->test->merge)
- code style, code coverave, TDD/BDD, все это может SME/TL проверить - есть-ли покрытие фичи integration/functional test, или нет, соответственно апрувнуть, % покрытия и прочее; или автоматизировать - см. gates выше

вот если PR собираются, чтобы "научить и доказать", тогда надо звать authority

формализуйте правила PR не для бюрократии, а для удобства работы

Так у нас и так делегирование - одни смотрят только со стороны архитектуры, другие только с точки зрения домена, остальные по желанию и усмотрению