Как выстроить культуру код-ревью? Наблюдения за десять лет

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

у нас выход такой: перед отправкой большого изменения пишем подход на одной странице и делимся. пять минут чтения экономят час споров на ревью.

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

Могу я как новичок кое-что сказать?

Для меня самое сложное — не воспринимать комментарии на свой счет. Когда приходит комментарий, который я не понимаю, мне стыдно переспрашивать, боюсь показаться тупым. Потом додумываю и правлю неправильно.

Не знаю, только у меня так или у других тоже бывает.

Не только у вас, это очень распространено, и исправлять это наша задача, а не ваша.

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

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

И вот что скажу: глупых вопросов не бывает. Тот вопрос, который вы задали, еще трое в команде хотели задать, но стеснялись. Спрашивая, вы делаете одолжение всем четверым.

Отдать споры о стиле инструментам — это само по себе самый большой выигрыш. Настраивается за неделю, экономит годы времени.

Предупреждение от проектного менеджмента: закладывайте время на ревью в план.

У нас было так: долго не считали ревью частью работы, в плане только время на разработку. Итог: каждое ревью воспринимали как «то, что тормозит работу», и делали для галочки.

С тех пор как мы внесли это в план, никто не саботирует ревью, потому что это больше не задержка, а часть плана.

Я сталкивался с тем же.

Именно так. Если не зафиксировать это письменно с самого начала потом возникнут споры.

Оставлю как заметку, пригодится.

Полностью согласен. То, что делают все, не значит, что это правильно.

Пишите, если есть вопросы, отвечу по мере возможности.

У меня было наоборот, поэтому и пишу. Главное не цифра, а то, на основе чего она получена.

Если напишете результат здесь, это поможет и другим.

Хочу предупредить. Прежде чем принимать решение, посмотрите, какие данные у вас есть.

Процесс, по которому не ведется учет, не улучшается, потому что вы не знаете, что именно улучшать. Интересно есть ли те кто делает иначе.

Слежу за темой.

У нас так же.

Сохранил.

Сведу тему в кучу, так как ответов было несколько разных. кстати начните с небольшого эксперимента не привязывайте всё сразу.

Я бы пошел этим путем.

Извините, но это верно не во всех случаях. Решения, работающие в малом масштабе, рушатся при росте я узнал это слишком поздно.

Исправьте, если я ошибаюсь.

Редко встретишь текст с такой ясностью изложения. Не стесняйтесь спрашивать молчание всегда обходится дороже.

Если скоуп растет, должен расти либо срок либо бюджет. Третьего не дано. Интересно есть ли те, кто делает иначе.

очень актуальная тема.

Взял на заметку, спасибо.