ДОКУМЕНТАЦИЯ КАК ВВЕДЕНИЕ В ПРОГРАММНУЮ АРХИТЕКТУРУ
Однажды мне довелось делать презентацию атрибутного метода проектирования (Attribute Driven Design, ADD; см. главу 7). Заказчики — представители одного из подразделений крупной производственной компании — видели в действии большинство наших разработок: метод анализа компромиссных архитектурных решений (АТАМ, см. главу 11), реконструкцию (глава 10), а также наши предложения по линейкам продуктов (глава 14). Закончив вещать, я, весьма довольный собой, ждал реакции. Оказалось, что не все так гладко. Представители заказчика, подтвердив свое намерение проводить разработку на основе архитектуры, признались, что численность группы разработчиков в их компании не позволяет применить на практике все, о чем мы им говорили, — на это уйдет несколько лет. А у них производственные планы и контракты, которые нужно выполнять. На то, чтобы воплотить в жизнь все наши рекомендации, у них просто не хватит ресурсов. Итак, наша задача состояла в том, чтобы грамотно направить их на путь архитектурной разработки, опустив все ненужные для начала подробности. Дискуссия плавно перетекла в плоскость документации программной архитектуры и книги на эту тему, написанием которой мы в то время занимались. Заказчику хотелось узнать, каким образом документация помогает распространять среди персонала компании знания о принадлежащих ей программных продуктах. В конце концов мы договорились провести практикум по архитектурной реконструкции и документировать ее результаты согласно тем принципам, которые рассматриваются далее в этой главе. Я всегда считал, что документацию следует создавать по окончании процессов проектирования и разработки. Необходимость создания архитектуры и документации обусловливается одними и теми же соображениями (коммуникативный, аналитический и образовательный факторы); разница лишь в ролях: архитектура — это побудительный мотив, а документация — производное. Представители заказчика высказали иную точку зрения. Документирование программной архитектуры они рассматривали как идеальное упражнение для разработчиков. По их мысли, если уж разработчикам все равно приходится заниматься документацией, то почему бы не составить для нее шаблон? В процессе заполнения им бы пришлось документировать разные представления (кстати, одной из наших задач было выбрать наиболее полезные для заказчика представления) и обсуждать пути удовлетворения проектируемым артефактом тех или иных задач по качеству. Таким образом, по мере составления документации они смогли бы углублять свои знания в области архитектуры. Идея о применении документации в качестве средства обучения, честно говоря, раньше не приходила мне в голову. А ведь мысль-то сильная! Для тех, кому по роду деятельности приходится рыться в битах, представление об архитектуре и связанных с ней понятиях — большой прогресс. Изучение принципов программной архитектуры путем составления документации представляется мне весьма эффективным педагогическим приемом, который к тому же не требует от практикующей его компании серьезных расходов. -LJB Даже если архитектором остается тот же человек, документация прошлых архитектур служит для него репозитарием знаний, кладезем детальных проектных решений, помнить которые в силу их крайней многочисленности весьма проблематично. Таблица 9.1. Заинтересованные лица и их коммуникативные потребности, удовлетворяемые архитектурой1
|
