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

•Сохранять старые версии в виде почтовых вложений, отправляемых некоторому «условному» пользователю (фантастика, но я столкнул# ся с такой системой в одной компании).

Какую бы систему вы ни выбрали, она должна решать такие проблемы:

•Обеспечивать простоту применения и доступность документов

•Два человека на должны одновременно редактировать один и тот же документ

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

•Не допускать случайного уничтожения документа или переписыва% ния документа не с тем номером версии

•Поддерживать журнал учета внесенных изменений

•Обеспечивать легкость получения документа с заданным номером версии

Глава 20. Рецензия на отстрел

Вопросы для размышления

1. Зависит ли количество рецензентов от объема рецензируемого кода?

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

Впрочем, если код слишком большой, нужно не приглашать дополни% тельных рецензентов, а переписать его заново!

2. Какие инструменты полезны при рецензировании кода?

Здравый смысл, пара глаз и острый ум!

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

3.Когда нужно рецензировать код – до или после обработки утилитами проверки исходного кода?

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								676m
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
Ответы и обсуждениеClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

проверить свой код, прежде чем передавать его на рецензирование. Глупо не сделать этого. Зачем рецензентам тратить время на код, кото% рый и без них можно было легко улучшить? Лучше потратить его на более интересные задачи.

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

4. Какая подготовка нужна перед совещанием по рецензированию?

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

•Прочесть и понять спецификацию.

•Ознакомиться с кодом.

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

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

5.Как отличить замечания рецензентов, которые нужно реализовать сра зу, от тех, которые нужно взять на заметку для следующего проекта?

Решение нужно принять исходя из следующего:

•Насколько важна выявленная проблема?

•Является ли она делом личного вкуса или нарушает принятые дого% воренности?

•Сколько времени понадобится для решения проблемы?

•Какое влияние окажет модификация на прочий код?

•Насколько ошибочен (или обманчив) код в отсутствие исправления?

•Насколько хрупкой или опасной является модификация?

•В какой стадии находится разработка проекта? Если близок срок выпуска, нужно вносить только существенные изменения.

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

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

6. Как провести виртуальное совещание по рецензированию?

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

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

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

7. Насколько полезны неформальные рецензии кода?

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

Хотя следующие термины официально не определены, Макконнелл описывает два типа неформального рецензирования (McConnell 96):

Критический анализ (walkthrough)

Это совершенно неофициальные собрания программистов, которые вместе просматривают код. Можно делать это в редакторе и тут же вносить изменения.

Чтение кода (code reading)

Автор рассылает код рецензентам, которые комментируют его и воз% вращают обратно.

Вопросы личного характера

1.Подвергается ли рецензированию код в вашем проекте? Достаточно ли проводится рецензирований?

Даже если такие совещания проходят более или менее регулярно, вполне вероятно, что рецензирование проводится в недостаточном объ% еме. Эта практика недооценивается; если видно, что код работает, то кажется, что и тратить время на его обсуждение нецелесообразно.