Например?

Типа если работает над кодом больше двух человек одновременно, то начинаются проблемы с целостностью

Давайте фотку

477

А вы говорите споры бесполезны

Щас найдем аргументы за кодревью

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

Ну фоткните разворот, это будет корректное цитирование или как там это называется

Со ссылкой на исследования *полный список на стр. 489*, инспекции позволяют выявить 60%дефектов

Ага. Формальные инспекции. Их имплементации как описано в книге я не встречал. Там приведен пример с NASA, в NASA я не работал. А вы уверены что у вас формальные инспкции имплементированны именно так как указано в книге?

Не говоря уже о том что "формальные инспекции != код-ревью"

На мой вкус как раз код ревью и создает тут проблему-ложное ощущение что команда владеет кодом. Смотрите - у вас на ревью всплыло что то серьезное. У меня сразу 2 вопроса: почему оно всплыло? Автор не знает чего то что знает реаьюер? Проблемас документацией? Дизайном? Тестами? Типизацией в конце концов? Как то сто заметили глазом смогло дожить до ревью.
И второй момент: ревьювер заметил только то что заметил, но если он глазами заметил что то критичное то сколько еще есть того что он не заметил? И насколько архитектурно остались проблемыв незамеченном коде?

*Взыдыхает* Я где-то писал, что у меня они есть? Про неформальное ревью на соседней странице.

Я опровергаю лозунг Виктора о том, что

Любая проверка сделанная после работы, а не до нее никакой пользы принести не может

Вот описание проверки, вот исследования.

У вас тоже стоимость проверки почти равна стоимости запуска в эксплуатацию. А цена одной ошибки равна стоимости всего проекта?

Но как устроен процесс? Проектируют ли они сначала? Как они программируют и т.п.

Но там речь о формальных инспекциях. Там приведены цифры для них

А не для того код-ревью которое мы обсуждаем

Это то что линтеры делают?