hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Главаm		22. Рецепт программы
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
681Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

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

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

1.Какая доля проектов, в которых вы участвовали, была выполнена в срок?

a.Для удачных проектов: чем был обусловлен успех планирования?

b.Для неудачных: в чем заключались главные проблемы?

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

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

2.Насколько точными бывают ваши оценки? Насколько далекими от ва ших оценок оказываются результаты?

Это такой вид мастерства, который можно совершенствовать вечно. Опыт – большой учитель. Надеюсь, ваши последние оценки точнее, чем прежние. Разве не так?

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

Глава 22. Рецепт программы

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

1.Какое влияние оказывают друг на друга стиль программирования и процесс разработки?

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

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								682m
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

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

Наибольшее влияние на выбор оказывают прежний опыт разработчи% ка и его личные предпочтения в отношении стиля программирования.

2. Какой стиль программирования лучше?

Хитрый вопрос! Если вы решили на него ответить, то положите книж% ку и отшлепайте себя 30 раз мокрой тряпкой.

3. Какой процесс разработки лучше?

И на этот вопрос вы клюнули? Вам поможет только электрошоковая терапия от 9%вольтового аккумулятора.

4.Укажите для каждого из перечисленных в этой главе процессов разра ботки его место на осях классификации процессов (см. стр. 536).

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

Ad hoc (специальный процесс)

Кто сумеет навести в этом порядок? Специальный процесс может оказаться в любом месте любой оси и даже постоянно перемещать% ся. Разработчики в процессе Ad hoc обычно не склонны к бюрокра% тизму, но дисциплина у них отсутствует – одни вещи выпадают из их внимания, другие повторяются снова и снова. Никакой последо% вательности нет вообще, поэтому данный антипроцесс вообще вы% ходит за рамки всех оценок, и если у него и есть какой%то проект, то он, возможно, не имеет ничего общего с тем, что будет создано!

Каскадная модель

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

SSADM

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

V модель

Еще один толстый линейный процесс (хотя некоторые его части в целях эффективности явно распараллелены). Как и другие вари%

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Главаm		22. Рецепт программы
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
683Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

анты каскадной модели, имеет склонность к нисходящему проек% тированию.

Создание прототипов

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

Итеративный и инкрементный процесс

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

Спиральная модель

Толстая версия итеративного и инкрементного процесса.

Методологии ускоренного проектирования

Ускоренные процессы – тонкие и нелинейные. Они не фиксируют направление проектирования; вы его непрерывно меняете. Сравни% те проектирование с поездкой в Париж на машине: в обычном слу% чае вы поворачиваете машину в сторону Парижа и едете; в ускорен% ном процессе вы начинаете езду, а потом непрерывно крутите руль. Возможно, вы даже составите план средней части своего движения, прежде чем найдете лучший маршрут для выезда из своего города.

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

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

Наверное, она была бы слишком похожа на учебник по программиро% ванию. Картинок, от которых текут слюнки, там нашлось бы немного! Можно предположить, что как различаются рецепты «голого повара»1

1Если вам показалось это грубым, загляните на www.jamieoliver.com.

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								684m
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

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

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

6.Можно ли, правильно выбрав процесс, сделать разработку программ ного обеспечения более предсказуемой и повторяемой задачей?

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

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

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

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

1.Каким процессом разработки и языком программирования пользуе тесь вы в данное время?

a.Было ли по этому вопросу достигнуто формальное соглашение меж ду участниками разработки или действуют традиции?

b.Как происходил выбор? Это выбор для данного проекта или рецепт, которым вы пользуетесь всегда?

c.Существует ли какая то документация по данному вопросу?

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

Это вопрос для определения того, насколько организована ваша ко% манда разработчиков и каким способом ведется разработка – целена%