как вы преодолеваете срач в ревью?
слышал что в каких-то компаниях бывают такие жосткие ревью
могу токо посочувствовать
у нас ревью - по желанию
сделал какуето изменение которое может затронуть что-либо о чем ты мог не сообразить - просишь коллегу сделать ревью
он делает
но смотрит не на твой код стайл, типа не там пробел поставил
а на логику, на то как ты решил задачу, что ты возможно забыл учесть
бывает он видит что ты неоптимальное решение придумал
тогда он те и говорит свои доводы, если он тебя убеждает - ты переделываешь
ни о каких конфликтах речи быть не может
могу токо посочувствовать
у нас ревью - по желанию
сделал какуето изменение которое может затронуть что-либо о чем ты мог не сообразить - просишь коллегу сделать ревью
он делает
но смотрит не на твой код стайл, типа не там пробел поставил
а на логику, на то как ты решил задачу, что ты возможно забыл учесть
бывает он видит что ты неоптимальное решение придумал
тогда он те и говорит свои доводы, если он тебя убеждает - ты переделываешь
ни о каких конфликтах речи быть не может
что можете посоветовать?твоя ситуация не нормальна и решается лично. Либо говоришь с человеком, либо говоришь с ним же, но в присутствии начальника. Если проблема не решается, она уже не твоя, а твоего начальника. После этого начинаешь не париться и стараешься перейти на другой проект (если это возможно) или другую работу (если это имеет смысл)
Либо говоришь с человеком, либо говоришь с ним же, но в присутствии начальника.разговор был
все остались при своем. начальник был на стороне ревьюера в том плане, что это ценный сотрудник, он с нами давно и тд (я в этом проекте чуть менее года) и он мой формальный лид.
После этого начинаешь не париться и стараешься перейти на другой проект (если это возможно) или другую работу (если это имеет смысл)сегодня был разговор с другим манагером. его позиция такая, что "умный всегда уступает", работа не только для себя, но и для команды, нужно усмирить гордыню, в данном вопросе истины нет, поэтому нет смысла ее отстаивать. убежать с работы - это всегда побег от проблем, но не решение (короче, это всегда успеется).
совет професионала:
подходиш к нему и громко заявляеш:
- Мне похуй чо вы там задумали, но всю систему я перепишу через хаскель
он канечно прихуеет, но вы твердо добавте:
- и меня неебут ваши сроки, я человек творческий!
подходиш к нему и громко заявляеш:
- Мне похуй чо вы там задумали, но всю систему я перепишу через хаскель
он канечно прихуеет, но вы твердо добавте:
- и меня неебут ваши сроки, я человек творческий!
ЗЫ как ты в МГУ с такой грамматикой поступил?
когда я поступал на физфак по олимпиаде я по мат/физике набрал максимум.
из 400 поступивших на физфак таких было всего 5 человек.
Но ща ворвется пофигист и будет орать что я насосал
из 400 поступивших на физфак таких было всего 5 человек.
Но ща ворвется пофигист и будет орать что я насосал
ты работаешь в иностранной компании, я прав?
// мне вот интересно, как вы "договариваетесь" в ревью?
Применяю логику.
// бывают ли у вас такие моменты, когда автор и ревьюер утыкаются рогами о какую-то "незначительную хрень" ?
Хотелось бы пример "незначительной хрени" в студию. Всё-таки фигурные скобки в той же или следующей строке - это одно (хотя даже это должно быть регламентировано а вот уже даже выбор между std::vector или std::deque может быть нетривиальным.
// каким образом достигается консенсус? умеете ли вы идти на компромиссы? или ожидаете это от напарника?
Применяю логику. У нас главное - дело. Капризюки, неконструктивное нытьё, склоки - никого не интересуют.
// вот у меня сейчас такой этап, когда есть взаимное расхождение взглядов. я постоянно взвинчен, нервы расшатываются. летают глупые мысли, что надо не здороваться с человеком, игнорировать, в морду дать, саботировать разработку (например, при наличии "странных" требований изменить код, ревью висит сутки, а затем перестраивается под ревьюера) и тд
что можете посоветовать?
интересно мнение как авторов, так и ревьюеров
спасибо
Ну я - как автор, так и ревьюер. Для мнения нужны какие-то подробности - телепатии не обучен.
Применяю логику.
// бывают ли у вас такие моменты, когда автор и ревьюер утыкаются рогами о какую-то "незначительную хрень" ?
Хотелось бы пример "незначительной хрени" в студию. Всё-таки фигурные скобки в той же или следующей строке - это одно (хотя даже это должно быть регламентировано а вот уже даже выбор между std::vector или std::deque может быть нетривиальным.
// каким образом достигается консенсус? умеете ли вы идти на компромиссы? или ожидаете это от напарника?
Применяю логику. У нас главное - дело. Капризюки, неконструктивное нытьё, склоки - никого не интересуют.
// вот у меня сейчас такой этап, когда есть взаимное расхождение взглядов. я постоянно взвинчен, нервы расшатываются. летают глупые мысли, что надо не здороваться с человеком, игнорировать, в морду дать, саботировать разработку (например, при наличии "странных" требований изменить код, ревью висит сутки, а затем перестраивается под ревьюера) и тд
что можете посоветовать?
интересно мнение как авторов, так и ревьюеров
спасибо
Ну я - как автор, так и ревьюер. Для мнения нужны какие-то подробности - телепатии не обучен.
У нас всё просто:
1. Автор пишет код
2. Ревьюер делает ревью и пишет свои замечания
3. Автор читает замечания и принимает к сведению
4. Автор по собственному усмотрению вносит исправления на основе замечаний ревьюера
В принципе, если автор хочет, он может задать ревьюеру уточняющие вопросы. Автор не обязан исправлять выявленные недочёты и не обязан объяснять кому бы то ни было, почему он проигнорировал какие-то замечания.
В конечно итоге за качество результат отвечает автор, а не ревьюер.
Исправления, внесённые по результатам ревью, если они существенные, могут сами быть предметом ревью, если так решит начальник или автор.
1. Автор пишет код
2. Ревьюер делает ревью и пишет свои замечания
3. Автор читает замечания и принимает к сведению
4. Автор по собственному усмотрению вносит исправления на основе замечаний ревьюера
В принципе, если автор хочет, он может задать ревьюеру уточняющие вопросы. Автор не обязан исправлять выявленные недочёты и не обязан объяснять кому бы то ни было, почему он проигнорировал какие-то замечания.
В конечно итоге за качество результат отвечает автор, а не ревьюер.
Исправления, внесённые по результатам ревью, если они существенные, могут сами быть предметом ревью, если так решит начальник или автор.
спасибо
возникает вопрос другого рода
1) в чем ответственность ревьюера? (у нас есть понятие мантейнеров либы, то есть человек. который знает либу, всегда ее ревьюит)
2) представим себе реальную ситуацию - один человек любит ставить скобки близко, другой ставит их чуть подальше. первый создал файл, его спокойно отревьюили, а второй стал переделывать скобочки под свой личный стиль, затем первый снова стал менять скобочки. надо ли это регулировать или пускай скачут скобки, да и фиг с ним?
зы: у нас в компании есть кодинг-стайл, однако, очевидно, он не покрывает всех возможных случаев, поэтому бывает столкновение субьективных вкусов. иногда работает метод "а в этой либе принято так, не мешай стили". причем у каждого, очевидно, найдется пачка аргументов в пользу его стиля. тут логика не работает.
возникает вопрос другого рода
1) в чем ответственность ревьюера? (у нас есть понятие мантейнеров либы, то есть человек. который знает либу, всегда ее ревьюит)
2) представим себе реальную ситуацию - один человек любит ставить скобки близко, другой ставит их чуть подальше. первый создал файл, его спокойно отревьюили, а второй стал переделывать скобочки под свой личный стиль, затем первый снова стал менять скобочки. надо ли это регулировать или пускай скачут скобки, да и фиг с ним?
зы: у нас в компании есть кодинг-стайл, однако, очевидно, он не покрывает всех возможных случаев, поэтому бывает столкновение субьективных вкусов. иногда работает метод "а в этой либе принято так, не мешай стили". причем у каждого, очевидно, найдется пачка аргументов в пользу его стиля. тут логика не работает.
// второй стал переделывать скобочки под свой личный стиль, затем первый снова стал менять скобочки.
Очаровательная контора!
Менять скобочки следует только там, где есть другие изменения, по существу. Иначе история вливов будет показывать изменения при отсутствии существенных изменений.
Очаровательная контора!
Менять скобочки следует только там, где есть другие изменения, по существу. Иначе история вливов будет показывать изменения при отсутствии существенных изменений.
// 1) в чем ответственность ревьюера?
В том, что если на ревью подали херню, а он её заревьюил, отношение к нему соответствующее.
В том, что если на ревью подали херню, а он её заревьюил, отношение к нему соответствующее.
в чем ответственность ревьюера?Ответственности нет. Обычно автор просит ревьюера проревьюить, чтобы получить мнение со стороны. У кого-то хорошо получается ревьюить, у кого-то плохо. Тех, у кого получается хорошо, просят чаще.
как говорят, плюсадин
у нас ревью - по желаниюсколько у вас прогеров?
мне кажется, что при большом кол-ве это неразумно
как по мне, самое хуевое, это когда навязывают свой кодестайл. Например, некоторые ненавидят иннерклассы и локал классы и вообще любые классы внутри классов и пропагандируют свою ненависть. Или еще, например, заставляют заменять пару вызовов методов объявлением локальной переменной. Я не считаю это критичным, также как считаю что иннер классы удобнее, также, я считаю что с твердолобыми мудаками лучше не связываться и сделать спокойно и с улыбкой так как они просят. Очень забавно потом наблюдать, как напыщенный недоумок растерянно уходит так и не получив ожидаемого им срача.
// Например, некоторые ненавидят иннерклассы и локал классы и вообще любые классы внутри классов и пропагандируют свою ненависть.
[представляет себе этих пропагандистов, ревьюирующих шаблоны, шаблонно зависящие от шаблонов...]
[представляет себе этих пропагандистов, ревьюирующих шаблоны, шаблонно зависящие от шаблонов...]
сколько у вас прогеров?ой
мне кажется, что при большом кол-ве это неразумно
я не знаю как отвечать
у нас разделение по модулям идет
то есть всего прогеров в команде - около 50
но вот если взять какойто модуль то коммитит в него 2-3 человека, еще двое смогут проревьювить потому что когда то разбирались в этом модуле
остальные не смогут - не будут понимать что там внутри
Да, кстати, дело происходило в конторе, еблище чейрмена которой смотрит с твоего юзерпика.
зы: у нас в компании есть кодинг-стайл, однако, очевидно, он не покрывает всех возможных случаевпочему бы не обсудить и не покрыть данный конкретный случай? У нас так делали и не раз при мне.
почему бы не обсудить и не покрыть данный конкретный случай?сказали, что дело локальное и нет смысла раздувать на всю контору
короче, сделал, как просит многоуважаемый ревьюер и ревью закрыли
вот так и живем
а в чем дело-то было?
а в чем дело-то было?все дело в волшебных пузырьках
а по сути?
за весь тред мне не стало понятнее, в чем проблема
я пока не сталкивался с проблемой, о решении которой двое разумных, адекватных разработчиков не смогли бы договориться
за весь тред мне не стало понятнее, в чем проблема
я пока не сталкивался с проблемой, о решении которой двое разумных, адекватных разработчиков не смогли бы договориться
а по сути?суть была изложена ранее
за весь тред мне не стало понятнее, в чем проблема
я пока не сталкивался с проблемой, о решении которой двое разумных, адекватных разработчиков не смогли бы договориться
проблема тоже описана : интересовали методы решения ситуаций, при которых не совпадают взгляды отдельных людей проекта и это может негативно повлиять на общую атмосферу, прогресс проекта и тд
столкнутся с подобными ситуациями несложно, если нет избыточного влияния (то есть власти) (для прорыва через административные барьеры) и наглости (для прорыва через человеческие барьеры). сколько людей - столько и мнений. умение общаться - это одно из центральных качеств современного разработчика, отличающего его от супер-кодера, который мастерски умеет проецировать мысль на код
вы готовы мне разъяснить границу между адекватностью и неадекватностью? разумностью и неразумностью? все в этом мире относительно
работа в команде протекает гладко благодаря множеству факторов (определить и зафиксировать их мне кажется сложным это и формализация процесса, это и иерархия проекта с четкими ответственностями\правами и обязанностями, это профессионализм\опыт сотрудников, умение общаться и договариваться (идти на компромиссы в угоду проекту и личным каким-то выгодам (спокойный сон, например
я задал конкретный (ревью, разрабы) абстрактный (ни скобочек, ни язык, ни строчек кода не сообщил) вопрос (хехе) и получил на него полезные конкретные ответы
у меня так много минусов, что всегда найдется куда расти
всем спасибо
// вы готовы мне разъяснить границу между адекватностью и неадекватностью?
Про скобочки вроде уже было.
// это профессионализм\опыт сотрудников
это ещё и порядочность сотрудников. Если все считают, что "наглость - второе счастье", мудаков считают "энергичными, пробивными, амбициозными людьми", почему программистская среда должна быть какой-то другой? Люди-то те же самые.
Про скобочки вроде уже было.
// это профессионализм\опыт сотрудников
это ещё и порядочность сотрудников. Если все считают, что "наглость - второе счастье", мудаков считают "энергичными, пробивными, амбициозными людьми", почему программистская среда должна быть какой-то другой? Люди-то те же самые.
Оставить комментарий
Maurog
мне вот интересно, как вы "договариваетесь" в ревью?бывают ли у вас такие моменты, когда автор и ревьюер утыкаются рогами о какую-то "незначительную хрень" ?
каким образом достигается консенсус? умеете ли вы идти на компромиссы? или ожидаете это от напарника?
вот у меня сейчас такой этап, когда есть взаимное расхождение взглядов. я постоянно взвинчен, нервы расшатываются. летают глупые мысли, что надо не здороваться с человеком, игнорировать, в морду дать, саботировать разработку (например, при наличии "странных" требований изменить код, ревью висит сутки, а затем перестраивается под ревьюера) и тд
что можете посоветовать?
интересно мнение как авторов, так и ревьюеров
спасибо