Комментарии 31
У меня не бывает конфликтных ситуаций на работе. Где угодно, но не на работе. Что я делаю не так?
Любое разногласие мнений это конфликт.
Полагаю, что не всякое разногласие — тема этой статьи.
То есть когда я на code review прошу внести изменения, это конфликт? Ого, какой я конфликтный, оказывается, я и не знал!
Полагаю, Вы слегка преувеличиваете.
Более того, есть интересная психологическая методика при самопроверке своей работы — представить, что её делал твой злейший враг, чтобы очень захотелось докопаться. Мне она помогала несколько раз в ответственных работах.
P.S. Разумеется, я понимаю, что все люди разные и у каждого свой порог чувствительности к замечаниям.
если, конечно, это реальные косяки, а не фигня, высосанная из пальца
А если ревьювер считает, что это серьезный косяк, а вы, что это фигня? А если ревьювер при этом еще и прав, а вы нет?
Если ревьюер прав — значит код надо исправить, а не конфликтовать.
Если ревьюер не может доказать, что он прав… То, может он и не прав?
Если на code review обсуждают видение прекрасного, значит, что-то не так в консерватории.
Если я запрашиваю изменения, я всегда формулирую объективную причину для их внесения. Понятно, что часто бывает, когда на первый взгляд просто "не нравится", но если я не могу четко сформулировать проблему, значит, есть вероятность, что проблема не с кодом, а у меня в голове. В этом случае можно обсудить в Slack-e ("а расскажи, почему тут вот так сделал? Мне что-то не нравится, но не пойму что :-)"), а можно просто забить и апрувнуть.
Другое дело, что кто-то может быть не согласен с архитектурными решениями и принципами, принятыми в проекте (то есть, речь о "холиварных" вопросах). Но холиварщики отсекаются на этапе интервью :-)
Ревьюер просто ничего с ним не делает, ни decline, не approve. А через некоторое время пм начинает терзать вас, почему тикет висит и что там такое.
Ну, что значит "терзать"? Он задаёт мне вопрос: "Что с задачей?"
Я отвечаю как есть, и задержка становится проблемой ревьюера.
Т.е., например, если вы не можете доказать антипрививочнику необзодимость привтвок, значит вы не правы?
Это сейчас не могу. А 20 лет назад у меня был непробиваемый аргумент: "Непривитых не принимают в ВУЗ".
На работе картина именно такая: если код не соответствует корпоративным стандартам — разраб не прав. А если соответствует — прав. Хотя мелочи можно и пообсуждать.
Отличная у вас работа. Но не всем так повезло, большинству приходится жить в реальном мире, где все стандартизировать невозможно, люди имеют разную квалификацию, обладают разными компетенциями и частенько руководствуются эмоциями, а не логикой :)
все стандартизировать невозможно
На случай, когда не удаётся придти к общему мнению, в компании существует должностное лицо, обладающее полномочиями принять волевое решение о том, какой вариант будет использоваться (и станет корпоративным стандартом).
Какую должность это лицо занимает — от компании зависит, главное, что оно есть.
Ага, а когда я сам прошу мой код побыстрее отревьюить — это, видимо, форма мазохизма. Понятно :-)
Если пулреквест не тривиальный, то всегда найдется, что обсудить.
Можно разделить на 3 категории:
1) очевидные ляпы, которые удивляешься, как сам не заметил, либо ляпы, которые допустил из-за слабого знакомства со стеком (скажем, до этого не работал с некоторой библиотекой), на которые укажет более опытный в нем коллега;
2) предложения по упрощению/увеличению понятности кода, чтобы он был понятнее с первого взгляда (я иногда люблю хитровыпендриться и не замечаю этого за собой);
3) предложения по улучшению архитектуры. Такое часто даже не оформляется в review, а сразу обсуждается в slack.
Всякие там code style issues ловит линтер, до код-ревью не доходит. (Бывают проблемы с неймингом, но это можно отнести к п.2).
Все это крайне продуктивно, если у кого-то от этого стресс, то у человека явно проблемы с психикой.
Понятно, что может быть такой PR, на который сложно ответить что-то кроме "Миша, все ****я, давай по новой", но это уже ошибка найма, такое бывает только на испытательном сроке и быстро заканчивается его непрохождением (впрочем, такой случай припоминаю только один).
Я не опровергаю полезность Code Rewiew, а говорю о вообще другой вещи, приведя в пример Code Rewiew.
Такая проблема возникает, когда единственный фидбэк — это критика. Смысл код-ревью, конечно, именно в критике. Но есть и ретроспективы спринтов, на которых надо не забывать и похвалить за хорошо сделанную работу.
А почему бы не полагать, что работа оценена по умолчанию хорошо?
Вспоминая про тему «игры, в которые играют люди», иногда складывается впечатление, что это игры играют в людей.
Почему мои коллеги/сотрудники ведут себя как @%§?
«Уся рота, ч-черт бы ее побрал, идет не в ногу. Один п-подпоручик идет в ногу»
Почему мои коллеги/сотрудники ведут себя как @%§?