Дополнение:
8) Есть ли код, отвечающий за мониторинг релиза. Есть ли эмитинг метрик, логов, алармы и т.д. Какие образом ваш релиз будет сапортится уже в продакшене.
9) Аффектит ли это изменение другие компоненты и команды. Иногда ваше изменение может заафектить другие компоненты или команды. В таком случае нужно добавлять людей из этих команд, в качестве reviewer. Или кто-то из вашей команды может на это указать.
10) Правильность подхода. Иногда reviewer может предложить альтернативный подход или вообще поставить под вопрос необходимость этих изменений или задачи в целом. Особенно это актуально, если у вас не было Design Review на эту задачу.

В Facebook, культура разработки другая. Тут основная заточенность на скорость разработки и impact, а не на культуру разработки. Поэтому пункты 2,3,4 не так важны. Очень часто код деплоится с минимальным числом тестов или вообще без них. Но тут скажем есть очень крутые авто-форматерры кода, универсальные для всей компании. Поэтому парится по поводу форматирование кода не надо вообще. Несмотря на меньшее покрытие тестами, число багов я бы сказал минимальное. За мой 17 летний опыт работы я понял, что качество кода и число багов больше зависит от качества разработчика, чем от культуры разработки. Если у вас в компании будут топ 0.1% разработчиков планеты, то они будут сразу писать правильный код, даже с минимальным числом тестов. Чем ниже уровень разработчиков, тем важнее культура разработки, чтобы предотвратить кучу багов.

Смотрите также: Design Review в Amazon, Version Control в FAANG

Пишите в комментария, как Code Review проходит у вас.