Я правильно понял что рамочным предположением является то, что 100% кода должно быть проведено через рецензирование?

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

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

Само собой. Чем больше компнент зависит от кода (читай чем больше проект или популярнее библиотека) и чем больше ущерб от ошибок (финансы, 24×7 системы) – тем тщательнее приходится проверять код.

В каких случаях, по вашему, оправданее применять процесс рецензирования основанный на патчах, примерно так как это делается в Open Source проектах?

Я использую примерно такую градацию (от наименее строгого варианта к наиболее строгому):

1. Код не рецензируются вообще;
2. Код рецензируется после того, как попадает в production ветку;
3. Код рецензируется до того, как попадает в production ветку. Автор кода имеет право проигнорировать мнение рецензента, если считает нужным;
4. Рецензент должен дать свое разрешение на чекин.

1 & 2 имеет смысл только для совсем маленьких и незначительных проектов. Выбор между 3 & 4 зависит от мобильности команды и от “проверенности” уровня разрабочиков.

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

С другой стороны в Open Source поекте патч может прислать кто угодно и качество присланого кода заранее не известно. Основное средство коммуникаций – e-mail тоже не обеспечивает нужной мобильности. Соотвественно используется 4-ый вариант. Хотя основные разработчики (как правило авторы проекта и наиболее активные и проверенные участноки) пользуются 2 или 3-им вариантом.

В общем всё зависит от:

1. Размера проекта;
2. Его популярности;
3. Мобильности и уровня разработчиков.

зы. тоже самое и для программистов на Java в среде Idea тоже от jetbrains.

В каких случаях, по вашему, оправданее применять процесс рецензирования основанный на патчах, примерно так как это делается в Open Source проектах?

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