«Растения в саду высаживаются, с одной стороны, в соответствии с исходным замыслом, а с другой – согласно текущим обстоятельствам. Некоторые из них выживают, другим же суждено превратиться в компост. Растения можно пересаживать, менять их расположение, играя, таким образом, со светом и тенью, ветром и дождем. Переросшие растения подрезают или срезают, а если, к примеру, какой-нибудь цветок по своему цвету не соответствует окружению, его пересаживают в более подходящее (с эстетической точки зрения) место. Занимаясь садоводством, мы выдираем сорняки и удобряем растения, которым нужна дополнительная поддержка. Хороший садовод постоянно наблюдает за здоровьем растений на своем участке и при необходимости вносит разного рода коррективы (удобряет почву, пересаживает растения, придумывает новый вариант разбивки)» [59] Andrew Hunt and David Thomas, The Pragmatic Programmer (New York: Addison-Wesley, 2000), p. 184. Перевод на русский язык: http://www.ozon.ru/context/detail/id/1657382/ (прим. сост. FB2)
.
Надо сказать, что метафора садоводства значительно лучше соответствует разработке программных средств. Она делает очевидным преходящий характер программных продуктов и акцентирует внимание на архитектуре, гибкость которой подразумевает возможность реализации новых структур. В контексте архитектуры системы конструируются, а непосредственно программные продукты выращиваются. Чтобы соответствовать потребностям бизнеса XXI века, мы должны построить органичную методику разработки программных продуктов.
Чтобы соответствовать потребностям бизнеса XXI века, мы должны построить органичную методику разработки программных продуктов.
Метафора садоводства, к тому же, выражает различие между органическим и синтетическим. Все органическое выращивается; синтетические же объекты собираются из конструируемых компонентов. Действительно, конструируя компоненты, мы делаем их синтетическими по самой природе. Однако та среда, в которой их предполагается выращивать, должна выводить целое за рамки суммы компонентов. Кроме того, она должна предусматривать возможность адаптации к изменяющимся коммерческим требованиям и к технологической эволюции.
Итак, пытаясь усвоить материал, который я излагаю в дальнейшем, не забывайте о биологии и старайтесь не зацикливаться на аналогиях со строительной индустрией. Функции метафор ограничены – они просто-напросто помогают применить абстрактные понятия в условиях рутинной технической деятельности. Нельзя писать код, исходя из метафоры. В этом процессе без деталей проектного решения не обойтись. С другой стороны, все эти детали в совокупности формируют образец. А вот образец уже можно рассматривать метафорически, анализируя степень его применимости к решению бизнес-задач. Вы ведь еще не забыли, как важно для нас думать? Штудируя мою книгу, вы должны были уже уяснить, что главное в нашей работе – мыслить. Мыслить широко и ни в коем случае не поверхностно. Никогда не забывайте этот принцип – он вам пригодится.
За последнее десятилетие появилось множество работ – как фундаментальных, так и прикладных, – доказывающих необходимость применения в процессе разработки программных средств качественной архитектуры. Исследователи, специализирующиеся в этой области, указывают на то, что огромное количество проектов приложений заканчиваются неудачей именно из-за пренебрежения архитектурными вопросами [60] Рекомендую в этом контексте ознакомиться с работами апологетов позитивных и негативных эталонов, например с трудами Брауна (Вroun) и других исследователей, чьи публикации перечислены в библиографии.
. В результате выполнения таких проектов, как правило, получаются «прямолинейные» системы. Их последующая адаптация к изменяющимся коммерческим требованиям осуществляется с большими трудностями, поскольку предполагает выделение значительных временных, трудовых и интеллектуальных ресурсов.
Занимаясь проектированием той или иной системы, вы должны уделять первоочередное внимание рискам. Каким видам рисков? Во-первых, риску ухудшения позиций компании на рынке, возникающему, когда в существующий продукт вследствие конкуренции приходится вносить новые непредусмотренные изначально черты; риску неумеренного усложнения процесса сопровождения продуктов, возникающему вследствие жесткой взаимозависимости компонентов-подсистем или негибкости их конфигурации. Еще один вид рисков заключается в неоправданной сложности продукта на верхних уровнях архитектуры. Это обстоятельство чрезвычайно усложняет задачу кодировщиков, не принимавших участия в процессе создания системы, но вынужденных выискивать способы исправления базовых компонентов. Все перечисленные проблемы имеют непосредственное отношение к временным и финансовым затратам, которые ваш начальник, естественно, желает сократить.
Читать дальше
Конец ознакомительного отрывка
Купить книгу