Говорят, скульптор думает о своей законченной работе, как о заключенной внутри глыбы камня или куска дерева, и которую нужно оттуда извлечь, отсекая лишнее. Это помогает. Точно так же, мы можем представить себя глядящими глазами пользователя на наше творение в один из дней в будущем. Если мы смотрим на него используя свойства (черты) системы, мы можем спросить себя: «Как это должно быть реализовано?» Тогда очень легко получить описание потребностей пользователя на языке инженера-программиста.
Архитектурный проект
Если уже приходится делать работу, заключенную в АП, то может показаться, что самая тяжелая работа по проектированию к этому моменту завершена. Есть также большой соблазн вообще уклониться от написания Архитектурного Проекта. В то время как мы умышленно опускаем детали проекта в АП, иногда чтобы удовлетворить требованиям независимости от платформы (portability), иногда просто чтобы развеять туман вокруг большой картины, мы по-прежнему должны быть уверены в том, что наш проект действительно реализуем. Инженер должен знать по крайней мере один приемлемый способ реализации каждого свойства до того, как искать его, и должен подумать о концептуальной целостности кода, требуемого для реализации этих свойств.
Утверждение, что архитектурный проект не должен касаться детального проекта, мы считаем ошибочным. Если мы не можем рассматривать реализацию, мы не можем быть хорошими инженерами, поскольку любой идиот может спроектировать нереализуемое. Только учитывая реализацию мы обнаруживаем ограничения наших проектов и находим разницу между хорошим и плохим. Мы способны увидеть альтернативы, сравнивать их и выбирать лучшее. Если мы не можем учитывать реалии реализации, то один дизайн так же хорош, как и другой, и эта критическая стадия познания становится упражнением в письме, кто быстрее может «написать документ», нимало не задумываясь над написанным!
АП — это дидактический документ. Он учит читателя тому, как посмотреть на проблему и решение так же, как смотрел автор.
Детальный проект
ДП — это записка в бутылке. Он говорит читателю о том, как автор планировал реализацию, поэтому код можно понять. Детальность изложения должна прояснить те места, которые остались за кадром в АП, и привести читателя в точку, где уже должен быть сам код. Иногда, это объяснение может быть выражено псевдокодом, но не обязательно. Следует допускать возможность исправления ДП. Во время реализации будут возникать такие детали проекта, как организация кода в модули. Если такие детали не передать с помощью ДП нашим коллегам, то как еще это сделать? Это простое упущение вызывает в дальнейшем слишком много ненужных проблем, поскольку инженеры посчитают составляющие системы хорошо документированными, только в случае, если они знали, с чего начать! Окончательный вариант ДП должен говорить последователям, что они должны знать, чтобы понять систему и изменить ее.
План тестирования
План Тестирования — наиболее чувствительный к контексту тип документа, но очень полезно руководствоваться следующими наблюдениями в рамках требований ситуации. Стратегическая цель тестирования — напрячь систему. Не будет никакой пользы, если делать тестирование хаотично, поэтому необходимо найти одну или несколько моделей системы, которые могут дать нам индикатор для типичных и стрессовых ситуаций. Таким образом, полезная структура — описать модель, выяснить стрессовые условия и затем перечислить их.
Снова и снова в этой работе мы видим эхо глубокой структуры, которую мы выявили, написав простейшую программу. У нас есть проблемная область, семантика системы и карта взаимосвязей между ними, созданная программистом при рассмотрении желания. Этот паттерн — центральное действие программирования компьютеров. В нем самом может и не содержаться понимания, но способность это делать — единственное доказательство, что проблема на самом деле понята в терминах заданной семантики. Если семантика строгая и проверяемая, как семантика цифрового компьютера, можно заявить о «глубоком» или «истинном» понимании, но это только предположение, поскольку кто-нибудь всегда может заглянуть за горизонт и сказать: «Посмотри на это так!»
Этот паттерн настолько важен, что мы хотим сфокусировать на нем внимание. Хотя мы стараемся избегать замысловатого жаргона без стоящего за ним реального смысла, мы хотим ввести термин, «Ход конем» («Вилка»), чтобы обозначить этот паттерн. Мы позаимствовали этот термин из шахмат. Там конь стоит на доске и может совершать последовательность L-образных перемещений. Другие фигуры могут перемещаться только по горизонтали, вертикали или диагонали, а L-образные ходы коня позволяют напасть сразу на две фигуры, каждая из которых ограничена своим собственным миром, и таким образом добиться чего-нибудь полезного в любом случае.
Такого вида паттерн появляется снова и снова, но мы всегда можем свести его к написанию простейшей программы. Компьютерная система может находиться во многих состояниях и развиваться в соответствии со своей собственной внутренней логикой. Окружающий мир, за которым следит компьютер, также может находиться во многих состояниях и изменяться (эволюционировать). Используя интуицию, дизайнер может абстрагировать и внести в компьютер критические аспекты проблемы, применяя одну и ту же структуру в обоих случаях, поэтому компьютер и реальность будут согласованы. Тестовые ситуации, формируемые моделью проблемы и системы, будут охватывать допустимые (и, вероятно, недопустимые) состояния пространства входных воздействий, в соответствии с интуицией автора, таким образом, что в любом случае можно будет проверить изменение состояния системы. Проектировщик, при необходимости выполнения манипуляций с данными, будет использовать свойства самих данных, определяемые структурой данных, и отражать эти свойства на свойства языка, как в каноническом:
while((c = getchar())!= EOF) putchar(f(c));
Все проектирование архитектуры заключается в прощупывании проблемы, рассматривая требования с максимально возможного числа направлений, до тех пор, пока в ней не обнаружится структура, которую архитектор системы сможет использовать для решения проблемы.
«Ход конем» всегда использует внутреннюю (присущую ей) глубокую структуру проблемной области. Проверка того, что эта глубокая структура реальна, а не плод воображения и случайных совпадений, очень важна. Если дизайнер использует случайные совпадения, результат будет скорее «заумным», чем «элегантным», и все будет хрупким, полагающимся на специальные меры предосторожности по всему результирующему коду системы, с потерей целостности проекта. Вайнберг (Weinberg) приводит пример программиста, пишущего на ассемблере. Тот обнаружил, что мог бы делать поиск по таблице [12] основываясь на номере кода операции и спроектировал свою программу исходя из этого. Но разработчики аппаратуры («железа») не считали схему нумерации кодов операций священной, и когда они произвели допустимые изменения, весь дизайн программы развалился.
Персональный послойный процесс
Дзенская притча говорит о мудром монахе, пришедшем к старому учителю. Он вошел в комнату учителя и сел перед ним. «Когда ты входил, с какой стороны двери ты оставил свой посох?» — спросил учитель. Монах не знал. «В таком случае, ты потерял свой Дзен».
После того, как вы рассмотрели структуру своей программы и готовы реализовать ее, все еще остается важная задача сохранить над ней контроль. Даже если вы уже написали критические строки кода, еще нужно написать много других. Требующаяся для этого дисциплина гораздо важнее, чем любой формальный процесс, и в каждой новой ситуации его нужно применять разумно.
Ваш процесс будет разбивать задачу на подзадачи, а затем вы должны собрать все вместе. Как машина-укладчик железнодорожного полотна, вы должны должны выстраивать структуру своей работы по мере ее развития. По прошествии времени вы достигнете способности делать это в своей голове, и на самом деле очень быстро, поскольку задачу можно упростить двумя способами.
Вы можете разворачивать только часть вашего плана, над которым вы работаете. Вот как можно спланировать изменения некоторой программы в своей голове:
1. Идентифицировать все файлы, которые включают функции:
ModelOpen(),
ModelRead(),
ModelWrite(),
ModelClose().
2. Отключить контроль версий этих файлов.
3. Внести изменения.
3.1. Изменить modread.c
3.1.1. Исправить ModelOpen()
3.1.2 Исправить ModelRead()
3.1.3. Исправить ModelWrite()
3.1.4. Исправить ModelClose()
3.2. Изменить appfile1.c
3.3. Изменить appfile2.c
4. Обратно включить контроль версий
5. Перекомпилировать
Тот факт, что это описание процесса может не описывать каждый маленький шажок и поэтому не перегружает ваш интеллект бесполезными попытками это делать, не освобождает вас от обязанности делать эту работу самому. И это позволяет устанавливать необходимый порядок в собственной голове по своему усмотрению — так, как вам удобнее. Некоторым людям нравится записывать небольшие списки файлов, которые нужно модифицировать, на клочках бумаги и рвать их, когда дело сделано, оставляя остальной процесс в своих головах. Они могут помнить, где они находятся на большой картине, но если их прервать посредине большого списка, они могут растеряться.
