- PVSM.RU - https://www.pvsm.ru -
Я постоянно делаю коммиты в проекты open source (Red Hat и др.). И заметил, что больше всего времени отнимают негативные код-ревью, субъективные по сути. Чаще всего такое происходит с коммитами, где мейнтейнеру по какой-то причине не нравится ваше изменение. В лучшем случае такая стратегия код-ревью приводит к потере времени в бессмысленных спорах; в худшем случае он активно препятствует коммиту, создавая враждебную и элитарную среду.
Код-ревью должен быть объективным, кратким и, по возможности, содержать только определённые факты. Это не политический или эмоциональный спор, а технический. Его цель — продвижение вперёд, развитие проекта и всех участников. Любой коммит должен оцениваться только по существу, а не по субъективному мнению.
Вот несколько стратегий, которые следует иметь в виду при рассмотрении кода, которые вам (как мейнтейнеру) по какой-то причине не нравится:
Просто высказывайте свои опасения и задавайте вопросы, чтобы помочь достичь желаемого результата.
Некоторые мысли лучше держать при себе. Если вы не можете сказать вежливо, лучше промолчите.
Может, у вас было другое представление о том, как решить проблему? Если вы действуете позитивно, то в конечном итоге найдёте решение, которое лучше, чем любой из исходных вариантов.
Во всех остальных отношениях абсолютно компетентный инженер может годами не знать некоторых фактов, которые вы принимаете за здравый смысл. Нет ничего зазорного в том, чтобы сказать очевидную вещь, если только вы не покровительствуете или ехидствуете.
Помните, что очевидные для вас вещи могут быть очевидны не для всех. Предлагая альтернативные подходы и указывая на полезные примеры, вы поможете всем синхронизироваться.
Иногда коммит просто не соответствует минимальному стандарту качества. Вполне нормально сказать об этом, но проявить уважение не требует дополнительных усилий.
Если коммит слишком большой и его нельзя быстро рассмотреть, то нормально сразу об этом сказать. Затем ищите вариант решения.
Просто сказав «Пожалуйста», вы показываете, что уважаете время отправителя, особенно когда хотите изменить форматирование или стиль, что может показаться незначительным изменением. Примеры:
Если после всего этого вам всё ещё что-то не нравится, но вы не уверены, почему, возможно, придётся просто смириться. Или сказать: «Мне это не нравится, но я не уверен, почему, можем поговорить об этом?» Это разумный вопрос, и даже хотя это может занять немного времени, но часто стоит того, потому что теперь у вас два человека, и оба учатся (объяснять и слушать), а не два человека, которые противостоят друг другу.
Даже квалифицированные и опытные инженеры должны быть в состоянии сказать: «Я не понимаю, почему мне это не нравится». Это не приглашение атаковать позицию рецензента, а скорее честный поиск знаний.
Избегайте гиперболических или напыщенных утверждений, избегайте споров, элитарных или унижающих выражений и конструкций вроде «очевидно» и «почему бы вам просто...». Используйте чёткие, фактические утверждения и поддерживающие формулировки, задавайте вопросы и продвигайтесь вперёд. Помните, что коллеги и контрибуторы — тоже люди. Их время заслуживает такого же уважения, как и ваше.
Автор: m1rko
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/open-source/323657
Ссылки в тексте:
[1] Источник: https://habr.com/ru/post/459718/?utm_campaign=459718&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.