Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами

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

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

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

Как отличить проектное решение от архитектуры? Представьте себя божком, собирающимся сотворить живое и разумное существо, обладающее, к тому же, способностью к адаптации. Надеюсь, для вас это не проблема (кстати, если так, придется вам внимательно ознакомиться со следующей главой, посвященной темной стороне лидерства). Как бы там ни было, трудно сотворить часть тела, не понимая, в каком окружении она будет существовать. К примеру, если бы легкие висели на левой руке, вряд ли они смогли бы исполнять свою основную функцию, – значит, лучше разместить их в груди. Полагаю, вы понимаете, к чему я клоню. При создании проектного решения предполагается наличие архитектуры, которая диктует расположение всех реализующих системные функции компонентов. Таким образом, проектное решение становится «плотью» [64] Ах, какой я молодец, что подобрал анатомическую метафору! архитектуры; кроме того, на этом этапе разработки производится выбор технологии реализации.

О чем вы говорите? Я предпочитаю VB и собираюсь писать на нем все программы [65] Лично я пользуюсь VB, начиная с версии 1.0, поэтому никаких предрассудков против этого языка не питаю. Всем интересующимся проблемами создания архитектуры и проектирования средствами VB рекомендую ознакомиться с работой Billy S. Hollis, Visual Basic 6 Design, Specification and Objects (Upper Saddle River, NJ: Prentice Hall, 1999). . Вы так считаете? Подумайте еще раз. Задачи, которые вам предстоит решать, – не гвозди; их нельзя вбивать одним молотком. Да, я опять обращаюсь к метафоре строительства, но, по-моему, в этом контексте она как нельзя более кстати. Не забывайте, впрочем, что метафоры и аналогии выполняют исключительно иллюстративную функцию – они как луч света в темной комнате, освещающий очертания меблировки. Иначе говоря, иллюстрация и реальный объект не идентичны; между иллюстрацией и проблемной областью нет точного соответствия. Аналогичным образом проектные решения можно принимать только при наличии утвержденной архитектуры.

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

Итак, имея на руках грандиозную архитектуру, вы готовы приступить к проектированию компонентов. Прекрасно. Мобилизуйте все свои объектно-ориентированные навыки. В первую очередь вам предстоит проверить архитектуру, имея в виду подчеркнуть приоритет этого этапа (я называю его «нулевым») в контексте процесса проектирования. Другими словами, вы должны провести макетирование архитектуры, но не совсем так, как это делается обычно. Вместо обширного графического пользовательского интерфейса сконструируйте ряд низкоуровневых компонентов, снабдите их интерфейсами-заглушками и возвращаемыми значениями – это позволит убедиться в работоспособности системы в вертикальной проекции. Конструируемые на этом этапе графические пользовательские интерфейсы должны лишь подавать сигналы и запускать те или иные процессы – больше от них ничего не требуется. Ведь ни один человек не выживет, если его мозг не будет взаимодействовать с сердцем, так? Именно поэтому, кстати, косметические операции проводятся исключительно по желанию пациента, а вот при проведении операции на головном мозге его согласия не требуют. Я полностью убежден – проверять архитектуру необходимо. На это, скорее всего, уйдет больше времени, чем можно было бы ожидать, но не сомневайтесь – усилия стоят того. С соблазном сразу перейти к разработке реальных компонентов системы нужно бороться – будет очень неприятно, если, подключив все компоненты, вы обнаружите, что они не стыкуются или не работают.