Хм. Имхо это организовывается через VCS. Потребности в регистрации "кто просмотрел" у меня не возникало, а все остальное делается на раз - ставится фильтр Files to checkout, и все сделанные изменения к моим услугам.

Один1Для проверки соответствия кода неким стандартам существует немыслимое число утилит.
Хм. Скажем так, я не верю в "тупые стандарты" - те, которых можно достичь за счет автоматических форматизаторов и автоматической же проверки. Согласен, меня будет несколько бесить, если половина кода написана с отступом в два пробела, а половина - в четыре, но подобные вопросы - это максимум 20% того, что по-хорошему должно быть стандартизировано.

Один1А "визировать" чужой код имеет смысл только для новых сотрудников, недавно принятых на работу. В дальнейшем - или человек пишет "правильно" и ему доверяют или покидает компанию.
Это идеальная ситуация, к которой хотелось бы стремиться, но. Скажу так: я работал с командой, с которой у меня не возникало потребности в code review. Я работал с парой людей, с которыми я крупно ошибся, не делая code review. Наконец, я работал с командой, где у меня было сильное желание пойти к начальству и сказать, что я хотел бы заниматься в первую очередь code review, потому что отлавливать и давить сразу же оказывается гораздо быстрее, чем ждать, пока я наткнусь на "это" в ходе решения какой-либо другой задачи.

Разумеется, я бы предпочел всегда и везде иметь первый случай. Сейчас - я бы очень хотел найти работу с перспективой собрать свою команду, и собирал бы ее под первый случай. Но...

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

Один1Кроме того ответственный за "визирование" кода как правило быстро тонет в количестве изменений, и спускает это дело на тормозах. У него ведь есть и другая работа.
Это да. Визирование кода должно быть адекватно организовано, иначе его не стоит и начинать.

PVPПроверка исходных текстов - это одно из основополагающих положений структурного программирования,
Хм. Простите, а не дадите ли какую-либо ссылку? Это идеи примерно одного времени, но вроде в моих книгах по структурному программированию такого основополагающего принципа не встречалось.

PVPХочу напомнить тем, кто по старше, или просто сообщить, тем кто тогда еще не работал, что цель этой работы - не только проверка. Главная цель - устранение ошибок программирования на самой ранней стадии, т.е. кодирования программы.
Я бы добавил, что в те времена машинное время стоило существенно дороже, и поэтому посидеть с карандашом и листингом и найти тупые ошибки "до того, как" было весьма выгодно. Сейчас этот аргумент менее важен. Что же до поиска серьезных, глубоких ошибок - не уверен в эффективности такой круговой любительской проверки.

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

PVPОбычно рекомендации состояли в том, что бы проверка текстов шла по кругу, т.е. ты мои, он твои, а я - его. Тогда постоянной ошибке деваться не куда - ее кто нибудь обязательно обнаружить.
С точки зрения поиска ошибок стоит именно так. С точки же зрения соблюдения стиля - я таки за единоначалие. Причина - такое желание сейчас возникает, если проверяемые слабы. Ну а тогда они друг у друга напроверяют...

PVPPS. Всю свою практическую работу (блин, всегда был начальником у программистов) пытаюсь это наладить, и никогда это не вживалось. Только теория.
Да в общем-то неудивительно. Какие у человека стимулы это делать? Грубо говоря, от человека требуют тратить свои силы на улучшение чужой работы. При этом если он проверит быстро и пропустит ошибку - ничего страшного; если же он потратит кучу времени, достанет автора уточняющими вопросами и ничего не найдет - никто ордена не даст. Плюс бытующая у многих нелюбовь отдавать свои исходники и копаться в чужих, плюс внутренние отношения типа "вот этот, сволочь, все время у меня ошибки находит".

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

М.ГоловановВо всех же остальных случаях для того, чтобы узнать, хороша программа или плоха, достаточно ее протестировать.
Недостаточно - если только не расширять понятие "тестировать" до вещей, этому процессу обычно не свойственных. Грубо говоря, если мы говорим, что тестируется исполняемый код, если результатом тестирования является оценка соответствия данного exe-шника выдвинутым требованиям, то недостаточно.

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

Как пример.... у меня был один коллега, парень потрясающей работоспособности. Он приезжал на работу, работал, работал, работал, если не изменяет память, не обедал, работал, работал, оставался в офисе один и работал, потом ехал домой и там работал - примерно так.

За то время, что мы вместе работали, он дважды чуть ли не полностью переписал программу, которую изначально разработал. То есть дважды появлялся заказчик, которому показывали "более-менее похожую программу" и он садился вот в таком режиме за ее переделку. Начальство очень его ценило и надеюсь, ценит до сих пор. Но по моему знакомству с ее исходниками скажу так - если бы изначально уделить больше внимания проектированию, результаты - те, которые по-Вашему являются единственным критерием и которые он показывал - обошлись бы раза в четыре дешевле.

М.Голованов
Хм. Мы все говорим, опираясь на тот или иной личный опыт. И создается впечатление, что у Вас этот опыт - оттоптанная кем-то мозоль.