Думаю, многие разработки знакомы с понятием code review или обзор кода по-русски (также данный термин переводят как просмотр кода, инспектирование кода или рецензирование кода – далее, для единообразия, будет использоваться вариант «обзор кода»). Недавно я столкнулся с необходимостью «разложить по полочкам» и классифицировать знания по этой теме. Результат – данная статья. Надеюсь, она окажется полезной, а также поможет внедрить обзоры кода в свой производственный процесс тем, кто только об этом задумывается.
Обзор кода является одним из наиболее эффективных методов поиска и устранения дефектов программы. Обзоры проводятся человеком, что позволяет находить широкий класс ошибок, в том числе с трудом детектируемых или вообще не детектируемых автоматическими средствами. Безусловно, обзор кода, не отменяет использование анализаторов кода или других методик обнаружения ошибок, например, unit-тестирования. К сожалению, не существует метода, который один обеспечил бы обнаружение всех дефектов программы (в исследованиях эффективность обзора кода обычно оценивается как 30-50% обнаруженных ошибок в приложении).
Поиск ошибок не единственная задача обзора кода. Помимо этого, обзор кода имеет еще несколько положительных свойств:
За все это приходится платить временем, которое могло быть потрачено на кодирование. Тем не менее, на проектах, рассчитанных хоть на какую-либо перспективу, затраченное время в будущем вернется сторицей за счет создания изначально качественного продукта, вместо судорожной «допилки» позже.
Можно выделить следующие виды обзоров кода:
Рассмотрим каждый вариант по-отдельности.
Формальная инспекция кода представляет собой как следует из названия ��ормализированную процедуру просмотра кода. По МакКоннеллу она выглядит примерно так.
Координатор инспекции назначает дату инспекционного собрания и инспекторов, которые должны до собрания самостоятельно изучить инспектируемый фрагмент кода. В назначенное время собираются координатор инспекции, секретарь, автор кода и инспекторы. Кто-то из инспекторов или руководитель начинают читать код строчку за строчкой (для удобства желательно его заранее распечатать вместе с номерами строк). Инспектора указывают на найденные ими проблемы, автор кода отвечает на вопросы инспекторов – если все соглашаются, что ошибка действительно имеется, то секретарь ее записывает. Координатор инспекции следит за процессом в целом, например, за тем, чтобы обсуждения одной ошибки не затягивались. По окончании инспекции составляется отчет с ее результатами.
Более подробный пример формальной инспекции можно найти здесь.
Неформальная инспекция в отличие от формальной не имеет четких пр��вил. Например, это может происходить так: автор кода, перед его публикацией, подзывает первого попавшегося разработчика за свой компьютер, где показывает и рассказывает то, что написал. Проверяющий пытается вникнуть в написанное, задает вопросы и высказывает свои соображения. Безусловно, при таком способе эффективность будет не сильно высокая, зато такая инспекция отнимает мало времени.
Чтение кода – это самостоятельное изучение разработчиком чужого кода без присутствия автора. Данная практика является самой простой и распространенной из описанных здесь – думаю, любому разработчику так или иначе приходило читать чужой код. Не говоря уж про мир Open Source, где это зачастую единственный доступный метод обзора кода.
Парное программирование является экстремальным методом обзора кода – обзор, осуществляемый постоянно: два разработчика за одним компьютером, за одним комплектом мыши и клавиатуры, вместе решают одну задачу. Широкое распространение парное программирование получило после появления методологии экстремального программирования, хотя активно использовалось и до этого. Часто парное программирование используется спонтанно: думаю, многим приходилось подходить к другому разработчику за компьютер, чтобы помочь решить сложную задачу.
Хочется добавить несколько слов к вышенаписанному. Как можно заметить некоторые недостатки вытекают из достоинств. В этом нет ничего удивительного – парное программирование методика достаточно не простая, как может показаться с первого взгляда, и не все ее свойства очевидны. Поэтому, начав работать в парах, не стоит ожидать моментальных результатов. Только после получения некоторого опыта парное программирование начнет приносить плоды, и более того – можно будет добиться минимизации некоторых негативных эффектов.
Теперь можно попробовать определиться какой метод и в каком случае стоит использовать.
Как видите, вариантов достаточно – можно выбрать наиболее подходящий для себя способ. Кроме того, никто не запрещает комбинировать методики (например, одна часть команды работает в парах, другая часть – в одиночку, но код, написанный ими, обязательно инспектируется). Можно начинать с более простых методик и постепенно переходить к сложным – главное начать, а положительные эффекты, думаю, не заставят себя ждать.
Обзор кода является одним из наиболее эффективных методов поиска и устранения дефектов программы. Обзоры проводятся человеком, что позволяет находить широкий класс ошибок, в том числе с трудом детектируемых или вообще не детектируемых автоматическими средствами. Безусловно, обзор кода, не отменяет использование анализаторов кода или других методик обнаружения ошибок, например, unit-тестирования. К сожалению, не существует метода, который один обеспечил бы обнаружение всех дефектов программы (в исследованиях эффективность обзора кода обычно оценивается как 30-50% обнаруженных ошибок в приложении).
Поиск ошибок не единственная задача обзора кода. Помимо этого, обзор кода имеет еще несколько положительных свойств:
- Улучшается архитектура приложения за счет того, что каждую часть системы продумали как минимум 2 человека.
- Программист изначально мотивируется писать более качественный код, зная, что его будут просматривать.
- Распространяются знания о проекте среди команды.
- Происходит обмен программистским опытом.
- Вырабатывается единый стиль кодирования в команде.
За все это приходится платить временем, которое могло быть потрачено на кодирование. Тем не менее, на проектах, рассчитанных хоть на какую-либо перспективу, затраченное время в будущем вернется сторицей за счет создания изначально качественного продукта, вместо судорожной «допилки» позже.
Можно выделить следующие виды обзоров кода:
- Формальная инспекция кода.
- Неформальная инспекция кода (другое название – анализ кода).
- Чтение кода.
- Парное программирование.
Рассмотрим каждый вариант по-отдельности.
Формальная инспекция кода
Формальная инспекция кода представляет собой как следует из названия ��ормализированную процедуру просмотра кода. По МакКоннеллу она выглядит примерно так.
Координатор инспекции назначает дату инспекционного собрания и инспекторов, которые должны до собрания самостоятельно изучить инспектируемый фрагмент кода. В назначенное время собираются координатор инспекции, секретарь, автор кода и инспекторы. Кто-то из инспекторов или руководитель начинают читать код строчку за строчкой (для удобства желательно его заранее распечатать вместе с номерами строк). Инспектора указывают на найденные ими проблемы, автор кода отвечает на вопросы инспекторов – если все соглашаются, что ошибка действительно имеется, то секретарь ее записывает. Координатор инспекции следит за процессом в целом, например, за тем, чтобы обсуждения одной ошибки не затягивались. По окончании инспекции составляется отчет с ее результатами.
Более подробный пример формальной инспекции можно найти здесь.
Достоинства:
- Очень высокая эффективность.
- Благодаря составляемому списку ошибок легко проверить их устранение.
- Инспекционные отчеты можно использовать в дальнейшем, например, для анализа характерных проблем.
Недостатки:
- Сложная формальная процедура, требующая времени.
- Отвлечение как минимум 3-х человек (координатор, автор кода и инспектор) от их основной работы.
- Большое психологическое давление на автора кода.
Неформальная инспекция кода
Неформальная инспекция в отличие от формальной не имеет четких пр��вил. Например, это может происходить так: автор кода, перед его публикацией, подзывает первого попавшегося разработчика за свой компьютер, где показывает и рассказывает то, что написал. Проверяющий пытается вникнуть в написанное, задает вопросы и высказывает свои соображения. Безусловно, при таком способе эффективность будет не сильно высокая, зато такая инспекция отнимает мало времени.
Достоинства:
- Малые затраты времени.
- Простой процесс не требующий формальных процедур.
Недостатки:
- Невысокая эффективность за счет поверхностного знакомства проверяющего с кодом.
- Для проверки приходится отвлекать кого-нибудь от основной работы, что может сильно раздражать.
- Критика кода может плохо восприниматься автором, причем как обоснованно (например, из-за незначащих придирок проверяющего), так и необоснованно (например, автору трудно признавать свои ошибки).
Чтение кода
Чтение кода – это самостоятельное изучение разработчиком чужого кода без присутствия автора. Данная практика является самой простой и распространенной из описанных здесь – думаю, любому разработчику так или иначе приходило читать чужой код. Не говоря уж про мир Open Source, где это зачастую единственный доступный метод обзора кода.
Достоинства:
- Простота.
- Высокая доступность – не требуется синхронизация во времени и пространстве.
Недостатки:
- Медленная обратная связь – могут потребоваться дополнительные комментарии к коду, которые нельзя быстро получить, а иногда даже быстрее самому исправить дефект, чем сообщить об этом автору.
Парное программирование
Парное программирование является экстремальным методом обзора кода – обзор, осуществляемый постоянно: два разработчика за одним компьютером, за одним комплектом мыши и клавиатуры, вместе решают одну задачу. Широкое распространение парное программирование получило после появления методологии экстремального программирования, хотя активно использовалось и до этого. Часто парное программирование используется спонтанно: думаю, многим приходилось подходить к другому разработчику за компьютер, чтобы помочь решить сложную задачу.
Достоинства:
- Высокая эффективность, особенно в плане обмена опыта и распространения знан��я о проекте.
- Высокая концентрация на работе – работая в паре, разработчики гораздо меньше отвлекаются на посторонние вещи.
- Естественное ограничение количества одновременно разрабатываемых командой задач – сконцентрированность на меньшем количестве задаче обеспечивает более качественную и быструю их реализацию, что позволяет непрерывно поставлять новые версии продукта.
- Нет психологических вопросов присущих инспекциям – оба авторы кода, и оба одновременно его же инспекторы, предложения по улучшению воспринимаются именно как предложения, а не критика.
- Повышение командного духа – успехи, достигнутые в паре, больше объединяют людей, чем индивидуальные достижения.
- Отлично подходит для обучения новичков.
Недостатки:
- Падение общей производительности, два программиста заняты одной задачей, вместо разработки двух задач – данное утверждение достаточно спорное, согласно ряду исследований, программисты, работающие в паре, имеют всего на 15% процентов меньшую производительность, чем два программиста работающих по отдельности.
- Требуется синхронизация рабочего графика – трудно работать в паре, когда партнеры в разное время ходят на обед или приходят на работу.
- Повешенная утомляемость за счет постоянной высокой концентрации на работе – для программистов, работающих в паре, даже может иметь смысл делать рабочий день меньше стандартных 8-ми часов.
- Не все люди совместимы, а некоторые даже вообще не способны работать с кем-то вместе. На самом деле, таких людей достаточно немного и большую часть проблем взаимодействия в паре можно преодолеть, выполняя ряд правил (например), а также с накоплением опыта работы в паре.
- Неэффективно для выполнения рутинных задач – в этом случае разработчик, не владеющий клавиатурой, будет просто скучать.
- Трудно синхронизировать темп разработчиков уровень опыта и знаний которых сильно различается – для эффективной работы от более опытного разработчика требуются терпение и некоторые наставнические навыки.
Хочется добавить несколько слов к вышенаписанному. Как можно заметить некоторые недостатки вытекают из достоинств. В этом нет ничего удивительного – парное программирование методика достаточно не простая, как может показаться с первого взгляда, и не все ее свойства очевидны. Поэтому, начав работать в парах, не стоит ожидать моментальных результатов. Только после получения некоторого опыта парное программирование начнет приносить плоды, и более того – можно будет добиться минимизации некоторых негативных эффектов.
Что выбрать?
Теперь можно попробовать определиться какой метод и в каком случае стоит использовать.
- Если вы решили делать обзоры кода, но не хотите сильно на этом заморачиваться, то для команды расположенной в одном месте неформальные инспекции будут лучшим выбором.
- Для распределенной команды практически единственный доступный метод обзора это чтение кода. Несмотря на то, что существуют системы для удаленного парного программирования, чисто по психологическим причинам, они не так комф��ртны как программирование за одним компьютером. Кроме того, чтение кода можно практиковать и в нераспределенных командах, но когда стоит выбор гадать над назначением какого-то куска кода или поинтересоваться об этом у автора, я бы выбрал последнее.
- Формальные инспекции отлично подходят для обзора сложных или критичных участков кода – в этом случае временные затраты с лихвой окупятся результатом. Некоторые практикуют постоянное использование формальных инспекций, но мне трудно представить, как можно формальными инспекциями провести обзор всего имеющегося кода.
- Парное программирование не зря является одним из принципов экстремального программирования. Его высокая эффективность и дополнительные бонусы, присущие только этому виду обзора кода, действительно позволяют его рекомендовать как основной способ разработки в команде (за исключением простейших или рутинных задач). Оптимизма добавляет и то, что с большей частью недостатков можно успешно бороться. Самой большой проблемой может стать попытка уговорить менеджмент использовать такой расточительный, по их мнению, метод – тут вам в помощь книги и статьи практиков экстремального программирования.
Как видите, вариантов достаточно – можно выбрать наиболее подходящий для себя способ. Кроме того, никто не запрещает комбинировать методики (например, одна часть команды работает в парах, другая часть – в одиночку, но код, написанный ими, обязательно инспектируется). Можно начинать с более простых методик и постепенно переходить к сложным – главное начать, а положительные эффекты, думаю, не заставят себя ждать.
Литература
- Совершенный код (Code complete). Стив МакКоннелл (Steve McConnell). Глава 21. Совместное конструирование.
- Экстремальное программирование: постановка процесса. С первых шагов и до победного конца (Extreme Programming Applied: playing to win). Кен Ауэр, Рой Миллер (Ken Auer, Roy Miller). Глава 14. Прекращаем работать в одиночку.
