hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								494m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 20. Рецензия на отстрелClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

или который важнее всего для правильного функционирования систе% мы. Можно воспользоваться следующими стратегиями:

•Отобрать главные фрагменты кода основных компонент.

•Запустить профайлер, чтобы выяснить, где тратится больше всего процессорного времени, и подвергнуть рецензированию соответст% вующие участки кода.

•Запустить утилиту, анализирующую сложность, и отправить на ре% цензирование самый подозрительный код.

•Выбрать области, где уже обнаруживалось больше всего ошибок.

•Выбрать код, написанный программистами, которым вы не дове% ряете (месть в виде рецензии!).

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

Тщательно отберите код для рецензирования. Если вы не можете прорецен& зировать весь код, сделайте обоснованный выбор. Не нужно отбирать наугад и терять драгоценное время.

Проведение рецензирования кода

То, что мы делаем постоянно, становится легче не потому, что задачи становятся легче, а потому что растет наше умение решать их.

Ральф Уолдо Эмерсон

Простого проведения рецензирования кода недостаточно. Само по себе это не решает всех проблем. Нужно обеспечить правильное проведение рецензирования. Этому мы и посвятим несколько следующих разделов.

Рецензирование на собраниях

Рецензирование чаще всего проводится в виде официального совеща# ния (по крайней мере, когда процедура разработки предполагает стро% гий церемониал). Предлагаются жесткая повестка дня (чтобы выпол% нить все необходимые действия) и определенные границы (необязатель% но по времени, но указывается, какой код вы рецензируете, а какой нет, поскольку это не всегда очевидно).

Ниже приводится пример организации совещания.

Где?

Лучше всего проводить рецензирование в тихом помещении. Участни% ков не должны беспокоить. Следует организовать кофе (или чай, если кому%то он больше нравится).

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Проведениеm		рецензирования кода
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
495Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

Когда?

Очевидно, в удобное всем время. Здравый смысл подсказывает, что 5 ча% сов вечера в пятницу не лучший выбор. Времени потребуется изрядно, поэтому позаботьтесь, чтобы вас никто не беспокоил и не отвлекал.

Если код очень большой, разбейте рецензирование на несколько встреч. Нельзя держать людей часами в замкнутом пространстве и рас% считывать, что качество их рецензий будет при этом высоким.

Роли и обязанности

Важнейший фактор успеха совещания по рецензированию – выбор участников. Каждому из них должна быть назначена определенная роль; в небольших группах один участник может исполнять несколько ролей. Роли следующие:

Автор

Очевидно, тот, кто написал код, должен участвовать в обсуждении, чтобы рассказать, какую работу он проделал, отвергнуть неспра% ведливую или некорректную критику и выслушать правильные, конструктивные замечания (и принять их к руководству).

Рецензенты

Рецензентов нужно тщательно отобрать среди людей, у которых есть время и способности к рецензированию. Хорошо, если код вхо% дит в их сферу компетентности или каким%то образом их касается. Например, разработчика библиотеки можно пригласить на рецен% зирование программы, которая использует эту библиотеку, чтобы отметить случаи неправильного применения API.

Должно присутствовать достаточное число опытных программистов. Можно пригласить представителя QA или тестирующего подразде% ления (см. врезку «Контроль качества» на стр. 187), чтобы QA убеди% лись в качестве программного продукта и процесса разработки.

Председатель

У каждого совещания должен быть председатель, иначе возникнет хаос (см. врезку «Это судьба» на стр. 435). Это лицо ведет совеща% ние и направляет обсуждение. Он должен следить за тем, чтобы об% суждение было деловым и не уходило в сторону. Мелкие вопросы, не требующие обсуждения на совещании, должны им сниматься. Дай программистам волю, и они станут часами обсуждать мелкие технические детали в ущерб рецензированию остального кода.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								496m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Глава 20. Рецензия на отстрелClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Секретарь

Секретарь ведет протокол, записывает, какие вопросы были подня% ты, чтобы ничего не забыть по окончании рецензирования. Если есть контрольный список для рецензирования (см. пример на стр. 504), секретарь его заполняет. Председатель, ведущий совещание, не должен выполнять роль секретаря.

Предполагается, что до начала совещания все участники ознакомятся с кодом. Все должны прочесть сопутствующую документацию (специ% фикации и пр.)1 и быть в курсе стандартов кодирования, принятых в проекте. Тот, кто организует совещание, должен указать на эти до% кументы в объявлении о предстоящем мероприятии во избежание не% доразумений.

Повестка дня

Чтобы организовать рецензирование кода:

•Автор сообщает, что его код готов к рецензированию.

•Председатель организует совещание (резервирует место, назначает время и подбирает рецензентов).

•Подготавливаются все необходимые ресурсы (компьютеры, проек% тор, распечатки и т. п.).

•О предстоящем совещании нужно объявить заранее, чтобы рецен% зенты могли подготовиться.

•После объявления о рецензировании автор не должен изменять код без крайней необходимости – это было бы нечестно по отношению к рецензентам.

Рецензирование проходит так:

•Председатель организует подготовку помещения, с тем чтобы во% время начать совещание.

•Автор в течение нескольких минут (не более!) рассказывает о назна% чении кода и немного о его структуре. Это должно быть известно за% ранее, но поразительно, сколько недоразумений обнаруживается на этой первой стадии.

•Предлагается высказаться по структуре проекта. Имеется в виду структура реализации, а не уровень операторов кода. Это может ка% саться разделения функциональности на классы, распределения кода по файлам и стиля написания функций. (В достаточной ли ме% ре соблюден защитный стиль и есть ли хорошие тесты?)

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

1Естественно, вся сопровождающая документация должна быть тщательно

прорецензирована заранее.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Проведениеm		рецензирования кода
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
497Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

•Последовательно детально разбирается код, по строке или по бло% кам, и ищутся ошибки. То, на что следует обратить внимание, опи% сывается ниже (раздел «Идеальный код» на стр. 501).

•Рассматривается несколько сценариев применения кода и изучает% ся поток управления. Если есть полный набор для поблочного тес% тирования (а он должен быть), тогда в нем есть все сценарии, кото% рые нужно рассмотреть. Он поможет рецензентам проследить все возможные пути выполнения.

•Секретарь отмечает, какие изменения необходимо произвести (за% писывает имя файла и номер строки).

•Проблемы, которые могут касаться более широкой области кода, регистрируются с целью дальнейшего исследования.

•После рецензирования обсуждается, какими должны быть после% дующие действия.

Возможные сценарии:

Okay

Отличный код, не требует никакой доработки.

Доработать и проверить

Требуется некоторая доработка кода, но созывать новое совещание нет необходимости. Председатель назначает ответственного прове% ряющего. После доработки проверяющий сверяет код с протоколом рецензирования.

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

Переработать и снова рецензировать

Код требует значительной переработки, и сочтено необходимым провести новое рецензирование.

Помните, что цель совещания состоит в выявлении проблем, а не устра% нении их на месте. Некоторые проблемы могут потребовать поиска пу% тей решения, и этой работой автор (или тот, кто модифицирует код) должен заняться после обсуждения кода.

При проведении рецензирования кода вам может оказаться полезен контрольный список, приведенный в конце главы.

Интеграционное рецензирование

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

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