The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Обзоры кода (также известные как обзоры с соавторами) должны стать обязательной практикой для каждой серьезной команды разработки программного обеспечения. Надеюсь, что в этом нет споров. Некоторые проводят обзоры кода перед слиянием, защищая свою основную/разработочную ветку от случайных ошибок. Другие проводят регулярные обзоры после слияния, чтобы обнаружить ошибки и несоответствия, которые были внесены авторами. Некоторые даже делают и то, и другое: обзоры перед слиянием и регулярные после. Обзоры кода очень похожи на технику тестирования по белому ящику, когда тестировщик ищет дефекты, имея полный доступ к исходным кодам программного обеспечения. В любом случае, обзор кода - отличный инструмент для повышения качества и стимулирования команды.
Однако, правильно их провести не так просто. Я бы даже сказал, что очень легко и удобно сделать это неправильно. В большинстве обзоров кода и среди рецензентов, которых я видел, присутствуют схожие ошибки. Вот почему я решил подвести итоги четырех основных принципов хорошего рецензента, как я их вижу. Надеюсь, что они окажутся полезными для вас.
У серьезного рецензента кода есть несколько страхов, от которых нужно отказаться. Первый и самый популярный - это страх обидеть автора кода. “Мне лучше закрыть глаза и притвориться, что я не видел его ошибки сегодня, чтобы завтра она проигнорировала мои ошибки” - Такое отношение порождает такой вид страха. Не нужно говорить, что это непродуктивно и снижает качество кода и мораль команды. Вот мой совет: будьте прямыми, честными и прямолинейными. Если вам не нравится код, вам он не нравится. Вам не следует беспокоиться о том, как ваше мнение будет воспринято автором кода.
Если у вас есть такие чувства к своим коллегам, то что-то не так с моделью управления. Вы боитесь быть отвергнутыми командой за “неспособность работать в команде”, что является ярлыком, присоединенным к вам самыми слабыми членами команды, а не спонсором проекта. Спонсор платит вам за создание программного обеспечения высокого качества. Спонсору не важно, насколько ваше намерение повысить качество обидно для других, кому все равно. Спонсор хочет, чтобы его деньги создавали результаты, которые можно продать клиентам и вернуть в виде прибыли. Спонсор платит вам не за то, чтобы заводить друзей в офисе.
Следующий вид страха звучит так: “Если я отклоню этот код, я задержу выпуск” Опять же, не нужно говорить, что такое отношение значительно наносит вред всему проекту. Вы примете код и закроете глаза на то, что вам в нем не нравится. Код попадет в следующий выпуск, и мы отправим его раньше. Вы не будете узким местом, и никто не скажет, что из-за этого догматического рецензента кода мы задержали выпуск и потеряли деньги. Вы будете хорошим игроком в команде, верно? Нет!
Как я уже упоминал ранее, профессиональный игрок в команде понимает свою личную роль в проекте и не прикрывает задницы других. Если отклонение плохого кода задерживает выпуск, это вина его автора. Ваша профессиональная ответственность состоит в том, чтобы сделать эту ошибку видимой. Так вы помогаете команде учиться и совершенствоваться.
Я думаю, очевидно, что образование и улучшение команды в первую очередь требует избавления от плохих программистов и продвижение хороших. Честные и бесстрашные рецензенты кода помогают команде учиться и совершенствоваться.
Еще один страх выражается следующим образом: “Я могу ошибиться, и они будут смеяться надо мной” Еще хуже, они могут заметить мою неполноценность. Они могут увидеть, что я не знаю, что делаю. Было бы лучше промолчать и притвориться, что в коде нет ошибок. По крайней мере, тогда я не унизил бы себя глупыми комментариями. Вы знаете, что намного проще казаться умным, если держите рот на замке, не так ли? Нет!
Проект не платит вам за то, чтобы вы выглядели хорошо. Вы получаете свои зарплаты не потому, что команда вас любит, а потому что вы создаете результаты ежедневно. Ваша профессиональная ответственность состоит в том, чтобы делать то, что лучше всего для проекта и игнорировать мнения всех, включая мнение вашего начальника. Подобно тому, как Счастливый начальник - ложная цель, я бы сказал, что уважение команды - ложная цель. Не пытайтесь заслужить уважение. Вместо этого создавайте чистый код, и уважение придет автоматически.
Позвольте мне повторить: не бойтесь принести вас в замешательство, сделав неправильные и глупые комментарии о чьем-то коде. Будьте верны проекту, а не ожиданиям окружающих вас людей. Они ожидают, что вы будете умными и яркими, но проект ожидает, что вы скажете, что вы думаете о коде. Так что забейте на их мнения; сделайте правильное дело и скажите, что вы действительно думаете.
Хорошо, вы бесстрашно выразили свои мысли о коде и просто отвергли его. Ветка, которую вы рассматривали, плохая, и вы объяснили, почему. Вы попросили автора переработать здесь и переписать там. Что дальше?
Он или она попытается договориться с вами. Это естественно и происходит практически в каждой ветке, которую я вижу в наших командах. Автор кода также профессиональный разработчик, и он тоже не боится. Поэтому он настаивает, что его подход к реализации правильный, а ваши идеи неправильные. Что должен сделать профессиональный рецензент кода в этом случае?
Самое худшее (как и в любом разрешении конфликтов) - это компромисс. Это то, что разрушает качество быстрее плохого кода. Компромисс - это техника разрешения конфликтов, при которой обе стороны соглашаются не получить то, что хотели, ради прекращения конфликта. Другими словами, “Давайте заключим мир, чтобы прекратить борьбу”. Это самый плохой подход.
Вместо плохого компромисса есть три профессиональных выхода из борьбы за кусок кода:
“Я никогда не приму это, точка!” Некоторый код заслуживает такого, и нет ничего плохого в том, чтобы разрешить конфликт таким образом. Противник может принять ситуацию и переписать все. И тоже что-то из этого извлечь.
“Давайте делать то, что говорит архитектор!” В каждом проекте есть программный архитектор, который принимает финальные решения. Обратитесь к его мнению и получите его окончательное решение. Пригласите его принять участие в обсуждении и попросите его занять одну сторону в конфликте. Как только он скажет вам, что вы не правы, примите его решение и постарайтесь извлечь из этого урок.
Таким образом, либо стойте крепко на своей позиции и боритесь за нее, либо признайте, что вы ошибаетесь. Так или иначе. Но не идите на компромисс!
Не поймите меня неправильно; дело не в том, чтобы быть упрямым и держать карты в руках, несмотря на то, насколько они плохи. Будьте гибкими и учитесь на месте. Ваша позиция может и должна измениться во время переговоров, но не принимайте ничего, что вам не нравится. Вы можете выйти из конфликта только в двух случаях: полностью убеждены, что оппонент прав, или когда архитектор так скажет. Нет ничего промежуточного.
Опять же, вы бесстрашно заявляете, что метод должен быть спроектирован иначе. Ваш оппонент, автор кода, отвечает, что не согласен с этим. Вы снова взглядываете и решаете придерживаться своей позиции. Вы все еще считаете, что правы, и не собираетесь идти на компромисс. Что делать теперь? Слишком рано обращаться к архитектору, поэтому попробуйте убедить своего оппонента.
В большинстве случаев убеждение - это обучение. Вы знаете то, чего он не знает. Вот почему он создал этот метод так, как вам не нравится. Один из вас нуждается в дополнительном образовании. Здесь у вас есть возможность стать учителем для вашего коллеги. Чтобы быть эффективным учителем, вам нужно предоставить доказательства. Вам нужно обосновать свою логику и убедиться, что он понимает и принимает ее.
Будьте готовы предоставить ссылки, статьи, книги, отчеты, примеры и т. д. Просто “Я знаю это, потому что пишу на Java уже 15 лет” недостаточно. Более того, такой тип аргументации только делает вас менее убедительным.
Если у вас нет достаточно убедительных доказательств, подумайте еще раз - возможно, вы ошибаетесь.
Также помните, что ваша задача - доказать, что код, который вы рассматриваете, плохой. Автор кода ничего не должен доказывать. Его код по умолчанию отличный. Задача рецензента - показать, почему и как это на самом деле не так. Другими словами, вы являетесь истцом, а он - защитником. А не наоборот.
Это последний и самый сложный принцип, который нужно соблюдать. Независимо от того, насколько плох код и насколько упрям ваш оппонент, вы должны оставаться профессионалом. Честно говоря, я иногда нахожу это очень трудным. В Zerocracy мы работаем в распределенных командах и каждую неделю нанимаем несколько новых людей. Некоторые из них, несмотря на наши критерии отбора, оказываются довольно сложными в общении.
Год назад мне попалась забавная ситуация, когда новый парень должен был создать небольшую (20-30 строк кода) новую функцию в существующей библиотеке Java. Он прислал мне запрос на добавление (я был код-ревьюером), после того, как внес несколько сотен строк кода. Этот код был абсолютным мусором и очевидно не написан им. Я сразу понял, что он нашел его где-то и просто скопировал. Но что я мог сделать? Как отклонить его код, не сказав, что его отношение неприемлемо для профессионального разработчика? Мне пришлось потратить некоторое время на объективную критику его кода по его стилю, дизайну и т.д. Мне пришлось оставить много серьезных комментариев, чтобы показать ему, что чтобы исправить все это, он должен удалить мусор и переписать его заново. После того задания я его больше не видел.
Мой посыл заключается в том, что легко быть профессионалом, когда вы имеете дело с профессионалами. К сожалению, это не всегда так. Независимо от того, насколько плохой код перед вами, будьте терпеливыми и убедительными.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 14:51
