hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								484m
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
Глава 19. СпецификацииClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Should not (Не следует)

Пользуйтесь should not (или not recommended, не рекоменду% ется) для описания определенного поведения, которого следу% ет избегать, если только нет веских причин выбрать именно его – опять%таки взвесив все последствия.

May (Может)

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

Это слово часто следовало бы использовать там, где люди пи% шут can. Can часто ошибочно используют в спецификациях и стандартах; оно двусмысленно и в зависимости от интерпре% тации читателем может означать как должен (must), так и мо# жет (may).

Почему мы не пишем спецификации?

Ибо не понимаю, что делаю. Потому что не то делаю, что хочу, а что ненавижу, то делаю.

К Римлянам 7:15

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

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

•Они не знают, что это необходимо.

•Они забывают.

•У них нет времени.

•Они сознательно решают не писать спецификации, считая, что мо%

гут обойтись без них («Да кто их вообще читает?»).

				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
485Click										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								486m
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
Глава 19. СпецификацииClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

Избегать составления спецификаций опасно и непрофессионально. Если не хватает времени для написания спецификаций, его, скорее всего, недоста& точно и для написания кода.

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

Резюме

Слова – самый сильный наркотик, который использует человечество.

Редьярд Киплинг

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

Хорошие программисты…

•Понимают важность специфи% каций и облегчают с их помо% щью свою жизнь

•Знают, насколько детальной должна быть документация

•Стремятся улучшить свои пи% сательские навыки и ищут воз% можности их потренировать

Плохие программисты…

•Бросаются очертя голову в коди% рование, не задумываясь над про% ектированием, документировани% ем или рецензированием

•Не обдумывают текст, который пишут, и создают бессистемные, малопонятные спецификации

•Не любят писать документы, счи% тая это скучным и бессмыслен% ным занятием

См. также

Глава 4. Литературоведение

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