Там сравниваются формальные инспекции и анализ проекта/кода

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

Как выглядит книга? Подскажите плз, пойду куплю

Другими словами: Формальные инспекции противопоставляются код-ревью, на сколько я могу видеть.

Что было бы, если бы код в таком виде уехал на прод?

Стив Макконел "Совершенный код." Достаточно хорошая книга с кучей первоисточников которые тоже можно проанализироват в книге.

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

Там есть и про простое чтение кода. 486 страница.

Есть и оно противопоставляется тому примеру что вы привели. Вы использовали аргумент в пользу код-ревью подменив понятие на формальную инспекцию

Дак вот эти моменты и надо лечить. А что еще в тот момент показалось понятно и просто, но ревьювер этого не вспомнил?

Нене, нормальный аргумент

Я про проверки же говорил

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

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

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

Я не топлю за ревью.

Короче, поинт в том, что очень желательно понимать чего мы хотим получить и в конце просто выполнить сверку, полученное == ожидаемое?

Я встречал. Там цена критической ощибки была - отзыв всей партии телефонов по всему миру

А я признаю свою неправоту 😅

Просмотрел по диагонали главу про инспекции кода в Совершенном коде
тлдр:
- есть формальные инспекции где мы задействуем кучу ролей (автор, координатор, секретарь, руководители, инспектор), есть четкий флоу как его проводить
- есть анализ кода, когда несколько разработчиков собираются и смотрят на код\проект
- есть чтение кода. Когда автор дает код, а люди смотрят его и дают фидбек (кажется ближе всего к типичному код ревью)

в выводах:
- эффективны формальные инспекции
- парное программирование и формальные инспекции примерно одинаковы по эффективности.

Цитата:
> Парное программирование и инспекции примерно эквивалентны по показателям расходов и качества итогового кода. Парное программирование может
оказаться особенно полезным, если вы хотите сократить срок разработки системы. Некоторые разработчики предпочитают работать в паре, а не самостоятельно.

А кто-то не читатель, кто-то писатель.