Существуют ли известные альтернативы код-ревью?

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

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

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

Существуют ли какие-либо альтернативные процессы, которые могли бы заменить проверку кода с целью улучшения качества кода? Можно ли вместо этого процесса иметь что-то другое? В то время как проверка может потребоваться, когда программные ошибки убивают людей, может ли быть достаточно более слабого метода, когда ситуация далека от критической?

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

Вы можете просто развернуть его и дождаться отчетов об ошибках.
Это не устранит ни одной ошибки в исходном коде перед развертыванием. Нужно больше идей.
Парное программирование?
Какую конкретную проблему вы пытаетесь решить? Что разработчики плохо воспринимают отзывы об обзоре кода? Проверка кода занимает слишком много времени?
Проблема с силовыми играми.
Это звучит как гораздо более глубокая проблема командной/корпоративной культуры, которую не может решить простое отсутствие проверки кода. В идеале менеджер людей, использующих код-ревью, чтобы играть в силовые игры, должен очень твердо поговорить с ними о приемлемом поведении.
Отказ от разработки программного обеспечения также является «очевидной альтернативой», но я не об этом спрашиваю.
Я согласен с Мэлом. Вы пытаетесь решить неправильную проблему. Если товарищи по команде переигрывают друг друга, значит, что-то не так в вашей культуре, а не в код-ревью.
Я голосую за то, чтобы закрыть этот вопрос как не по теме, потому что он должен быть на codereview.stackexchange как на более актуальном сайте.
У вас XY-проблема. У вас нет проблемы с просмотром кода. У вас проблемы с неправильным управлением и планированием. Если существуют четкие рекомендации по обзору кода и руководитель проекта следит за тем, чтобы обзоры были конструктивными, то проблем нет.
Проверка кода @TheWanderingDevManager предназначена для публикации кода и его проверки, а не для обсуждения теории проверки кода.
@jwodder - тогда хорошо программисты, но я хочу сказать, что это не вопрос рабочего места, мы не ориентированы на разработчиков, и это очень специфично.
@TheWanderingDevManager: в этом вопросе есть детали, специфичные для отрасли, но он касается рабочего места, а не кода или даже проверки кода. В конце концов, в компании ОП есть две конфликтующие группы работников, и она ищет способ разрешить этот конфликт.
Я удивлен, что никто не упомянул статический анализ кода. Конечно, не заменой, так как цель проверки кода заключается в том, чтобы убедиться, что код соответствует дизайну (у вас ведь есть проектная документация, не так ли? ;-), но статический анализ кода является своего рода проверкой кода и может найти то, что пропускаются как компилятором, так и рецензентами (по моему опыту, всегда так). Опять же, это не помогает с этим конкретным вопросом, но всегда стоит упомянуть, когда упоминается проверка кода (и не заставляйте меня начинать модульное тестирование ;-)
Альтернативой код-ревью является глючный код.
Интересно, как это получилось

Ответы (4)

ИМО, вы неправильно поняли технический процесс, и это вызывает проблемы в бизнесе. Я коснусь обоих, потому что они взаимосвязаны.

Техническое недоразумение: Код-ревью — это не проверка начальником работы подчиненного. Код-ревью — это вторая (или более) пара глаз, смотрящая на то, что сделано, что не сделано, как сделано и как решает поставленную задачу, а также как это вписывается в текущий код и соответствует текущему. стандарты кодирования. Это признание того, что наш мозг запрограммирован на заполнение недостающих деталей (поиск психолингвистов и заполнение пробелов, чтобы найти детали).

Бизнес-проблема: ваши старшие играют в силовые игры. Вероятно, это частично вызвано вашим неправильным использованием проверок кода. Имея «старший проверяет код младшего», вы установили, что (а) младший код нуждается в проверке, а старший нет (фактически неверно), и (б) что старшие делают обзоры. Это связало обзоры с позициями внутри компании. Ваши старшие рецензенты почти должны найти серьезные проблемы, иначе они говорят, что младшие так же хороши, как и они.

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

Проведение надлежащих обзоров кода, обзоров, сделанных коллегами, а не начальниками, вероятно, будет трудным. Старшие не захотят, чтобы их код проверяли младшие, младшие не решатся исправлять код старшими. То, что младшие проверяют младших, а старшие — старших, только усугубит ситуацию. Единственное решение, которое я вижу, — это удвоить усилия, провести проверку всего кода несколькими независимыми экспертами в течение некоторого времени, пока вы не будете уверены, что все согласны с новым процессом.

LGTM (мне кажется хорошим) от одного должно быть достаточно для фиксации, если у другого рецензента нет конкретного примера, когда код не работает по спецификации.

Я полностью согласен - чтобы расширить техническую природу обзора кода, он действительно должен противоречить заранее установленному руководству по коду, которое включает в себя то, как намерение/использование скобок, как модульное тестирование и т. д. - любые ошибки могут быть отмечены, но их не обязательно исправлять (стоимость их исправления может быть выше, чем та, которую готов потратить руководитель проекта, или их влияние может быть незначительным). Может быть даже полезно начать проводить слепую или двойную слепую проверку кода, чтобы исключить из проверки кода силовые игры, поскольку это снижает ценность фактической проверки кода.
Этот правильный ответ на вопрос в том смысле, что он четко указывает, что нужно делать по-другому (следовательно, альтернативным способом). Проблемные ситуации, с которыми я сталкивался, всегда включали высокий уровень асимметрии процесса рецензирования. Я принимаю этот ответ как ответ, который мне нужен.

Сочетание код-ревью и мощных игр — рецепт катастрофы.

Вот худший случай: A и B имеют разные стили. А пишет код. Б отзывы. B жалуется, что вещи не в предпочтительном стиле B. A меняет стиль в соответствии с предпочтительным стилем B. Если бы Б написал код, а А просмотрел его, А пожаловался бы, что стиль не соответствует предпочтительному для А. B меняет стиль в соответствии с предпочтительным стилем A. Так что мы тратим время на то, чтобы привести код в стиль, который не понравился автору. Это ерунда, но так бывает.

Задолго до того, как код будет написан, следует коротко обсудить примерную стратегию. В результате в обзоре не должно быть сказано «это совершенно неправильно и нужно было сделать совершенно по-другому» — с этим нужно разобраться задолго до написания кода.

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

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

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

Согласованность очень трудно обеспечить любым другим способом. Скажем, у команды есть предпочтение стиля в отношении того, как создаются имена: это, например, AddItem() или NewItem() или ItemAdd(). Кому-то, кто пишет много кода, который все работает нормально, но не следует этому стилю, могут попросить исправить его, и он может подумать, что это большая трата времени. (Большинство инструментов могут вносить такого рода изменения тривиально, поэтому в целом реакция носит эмоциональный характер и выражается в том, что вам нравится, когда вас исправляют, или что вам не нравится чувствовать себя «неправильно».)

Обнаружение ошибок случается реже, но случается, что кто-то скажет: «Это не выглядит [поточно-ориентированным, масштабируемым, защищенным от исключений]; вы тестировали в [типичных производственных условиях, которых нет на машине разработки]?» и настоящая ошибка предотвращена. Как правило, это означает, что человек должен начать все сначала и чувствует себя очень униженным из-за того, что совершил ошибку новичка.

Недостатком код-ревью является то, что он может стать состязательным. Рецензенту трудно не подумать: «О чем вы вообще думали? Вы читали наше руководство по стилю? Вы хоть задумывались, на что похоже производство по сравнению с вашим ноутбуком?» и иногда они тоже говорят такие вещи. Делая это воротами для обзора, где старший человек может пройти или провалить вас, вы усиливаете эмоции. Разработчики часто пытаются опровергнуть исправления, говоря, что это вопрос личных предпочтений или что рецензент одержим крайним случаем, которого не будет, или просто придумывает опасения, чтобы почувствовать себя важным или унизить разработчика.

А теперь представьте, что сверстники все время просматривают вещи друг друга. Не как ворота, через которые нельзя пройти без золотой звезды, а как естественный способ работы. И они указывали друг другу на вещи рано, чтобы сэкономить работу и боль, а не причинять их. Это было бы намного лучше, правда? Точно так же, как непрерывная интеграция и непрерывное тестирование делают разработчиков более счастливыми, а код лучше по сравнению с кодом на два года-сейчас-можно-начать-тестирование, небольшие обзоры все время — много раз в неделю — сделают разработчиков лучше. счастливее и код лучше, чем один финальный обзор кода типа «вы думали, что закончили, но здесь находится The-Nitpicker».

Если вы хотите полностью отказаться от них, вы можете. Много кода было написано и отправлено без них. Но это риск. Прохождение тестов не означает, что код читаем и непротиворечив. Отсутствие взрыва в производстве в первую неделю не означает, что этого не произойдет, когда вы удвоите количество пользователей или у вас будет 5 лет данных в базе данных. Вам будет трудно найти замену просмотру кода, чтобы предотвратить подобные проблемы.

Не надо мне объяснять, насколько хорошими могут быть обзоры, если все хорошо настроено, вопрос в возможных альтернативах. Помимо сверхчувствительных людей, есть и явные силовые игры.
Да, есть много способов расстроить людей. Но никто не может предложить вам замену код-ревью, не установив предварительно преимущества код-ревью. Итак, первые три абзаца. 5-й предлагает замену «обзорам ворот», а последний обсуждает, что произойдет, если вы просто отбросите их.

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

Код разработчика А проверяет работу разработчика Б. Код разработчика Б проверяет работу разработчика А. Цикл обратной связи завершен. Если разработчик А решит быть очень придирчивым к работе разработчика Б, то ему лучше быть готовым принять такой же уровень критики в ответ.

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

Я согласен с тем, что руководитель проекта должен вмешаться, но я думаю, что это может легко стать политическим вопросом в достаточно большой команде, где более старшие разработчики просматривают код более младших разработчиков, а не наоборот. Это нелепо и является признаком дисфункциональной культуры, но я вижу, как это происходит.
Существуют ли известные альтернативы код-ревью?
СпросиСетьПолитика конфиденциальности1y, 0v