Code Review¶
Автор раздела: Ivan Zakrevsky
Является ли Code Review эффективной практикой?
Возможные результаты Code Review¶
Давайте посмотрим, какие исходы обычно возникают в результате Code Review:
Когда новый инкремент знаний получен, тогда возникает:
Конесенсус (обоюдное согласие на едином решении), который формируется, как правило, новым инкрементом знаний, полученным в процессе обсуждения Pull Request.
Психологическая защита. Чувство ущербности на фоне грамотного спикера вынуждает специалиста защищать свою зону комфорта и социальное положение путем агрессивных попыток дискредитации носителя неудобных компетенций. Увы, подобные случаи происходили даже в практике достаточно известных авторов по архитектуре. Иными словами, мало знать, нужно уметь еще донести.
Если знание по своему определению непротиворечиво и способно привести к обоюдному согласию (пусть и не всегда), то недостаток знаний (для качественной аргументации позиции) приводит к соперничеству мнений за лидерство.
📝 "Там, где заканчивается знание, начинается мнение".
—"Философия: Энциклопедический словарь." — М.: Гардарики. Под редакцией А.А. Ивина. 2004.
Тогда возникает:
Внешний конформизм, когда одному из участников Code Review не удалось аргументированно пояснить свою позицию другому, и тот решил прекратить прения, оставшись внутри себя несогласным.
Эффект иррационального усиления - когда психологически сложно расстаться с проделанным трудом.
Во всех перечисленных случаях, кроме первого, это приводит к демотивации и усиливает текучку кадров. Что, в свою очередь вызывает ущерб упущенной выгоды из-за сдвига графика выхода на рынок новых бизнес-фич в результате простаивания незаполненных вакансий, проблемы Брукса (отвлекания опытных специалистов на обучение новых, низкая эффективность новых специалистов из-за недостатка знаний и трат времени на освоение новых знаний), прямые потери (обучение, поиск соискателей) и т.п.
Поскольку ключевым условием достижения консенсуса ревьюера и автора Pull Request является новый инкремент знаний, резонно возникает вопрос: а нужно ли получение этого инкремента привязывать во времени к инспекции уже воплощенной реализации?
Apaptation vs Prediction¶
Можно еще провести такую аналогию: Code Review - это форма инспекции и адаптации, т.е. эмпирический (опытный) способ обработки неопределенности. Это сродни хождению на ощуп. Куда-то добраться таким образом можно, но происпектировать таким образом можно только то, что можно потрогать, т.е. когда "уже пришли".
Процесс можно сделать эффективней, если расширить горизонт "видения", т.е. внести определенную долю Prediction-активности, и получение основного инкремента знаний перенести с Code Review на Design Review. Как говорится, когда ты за рулем, то уже поздно читать инструкцию по вождению. Очень хорошо эту мысль раскрывает "Эксперимент с красными бусинками - Dr. Deming's Red Bead Experiment".
Тут возникает вопрос о том, как достигнуть Design наименьшими трудозатратами, и именно эту проблему хорошо решает Event Storming, т.к. его можно осуществлять прямо в процессе обсуждения.
Continuous Review¶
Можно еще обратиться к народной пословице о том, что лучше один раз увидеть, чем сто раз услышать. Т.е. использовать Continuous Review (Pair Programming, Mobbing Programming).
Вопрос не в том, чтобы исключить Code Review, а в том, чтобы уменьшить его негативные последствия путем добавления других форм передачи инкремента знаний.
Когда-то делал на скорую руку диаграмму причин и форм проведения Code Review. Жалко выбрасывать, решил поделиться. Исходная модель.¶
