Посмотри что я наделал

Странно, что я до сих пор ничего не писал про ревью кода. Если прикинуть эффективность различных инженерных практик, то она окажется, на мой взгляд, одной из самых выгодных. Смотри сам: при правильно построенном процессе, эта активность занимает 10-15 минут в день. Плюсов же - вагон и тележка.

Быстрое обучение как новичков, так и опытных разработчиков. С одной стороны, более опытные разработчики, знакомые с архитектурой системы, могут подсказать, как сделать проще или эффективней, исправить ошибки. С другой стороны, читая код более опытных коллег, разработчики перенимают хорошие решения и практики.
Код пишется более качественно. Это происходит просто потому, что ты знаешь, что твой код будут читать твои коллеги. Пруф.
Растёт бас-фактор (всегда приятно, когда что-то растёт =) ). Со временем, каждый человек в команде будет знаком с каждым уголком приложения, а значит, пропадут тайные знания и будет проще распределять задачи.

Можно продолжить этот список, но даже его более чем достаточно, чтобы окупить 15 минут в день. А чтобы код-ревью проходил легко и действительно занимал 15 минут в день, достаточно придерживаться простых правил:

Делайте ревью небольшими. Да, придётся декомпозировать большие задачи, но ведь это тоже полезно ;).
Любую задачу можно решить множеством способов, поэтому не критикуйте чужое решение только потому, что вы сделали бы это по-другому.
Критикуя, предлагайте альтернативу.
Предлагая альтернативу, объясните, чем предложенное решение лучше.
Не придирайтесь к стилю, для этого есть другие инструменты (статического анализа).
Не проводите много времени за ревью. После 5-10 минут эффективность начинает серъезно падать. Лучше сделайте несколько подходов в течении дня.
Не затягивайте ревью, люди ждут ваших комментариев.
Делайте не только замечания, но и отмечайте удачные решения. Ласковое слово и кошке приятно =).
Проводите ревью всех изменений. Вне зависимости от того, код это продукта или тестов, писал его новичек или техлид, реализует он новую фичу или фиксит баг.

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