Как пасти котов

Держу пари, что вы сомневаетесь: нужно ли вам все это знать? Полагаю, что если вы действительно хотите стать эффективным техническим лидером, это знание необходимо. Если вы пользуетесь языком программирования четвертого поколения (4GL, например, Visual Basic), а не, скажем, С++, то больше внимания следует уделять разработке архитектуры системы. Даже при условии применения С++ создать плохую архитектуру не представляет труда – что уж говорить о языках четвертого поколения! Да, действительно, они позволяют оперативно выстроить механизм взаимодействия пользователя с системой, но это, как вы понимаете, лишь ее оболочка. Термин быстрая разработка приложений (Rapid Application Development, RAD), возникнув на заре создания программных продуктов под Windows, первоначально отражал высокие темпы выхода продуктов на рынок, достигавшиеся средствами языков четвертого поколения. В сегодняшних условиях «быстрая» разработка в большинстве случаев приводит к появлению некачественных программных продуктов. Мне даже кажется, что аббревиатуру RAD сегодня более уместно расшифровывать как «разработка мерзких приложений» (Rotten Application Development). Первоочередное внимание следует уделять, говоря анатомическим языком, скелету, нервной системе и внутренним органам. В противном случае вы рискуете извергнуть очередную халтуру.

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

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

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

Свежий взгляд на проектирование

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

О чем вы говорите? Я предпочитаю VB и собираюсь писать на нем все программы[65]. Вы так считаете? Подумайте еще раз. Задачи, которые вам предстоит решать, – не гвозди; их нельзя вбивать одним молотком. Да, я опять обращаюсь к метафоре строительства, но, по-моему, в этом контексте она как нельзя более кстати. Не забывайте, впрочем, что метафоры и аналогии выполняют исключительно иллюстративную функцию – они как луч света в темной комнате, освещающий очертания меблировки. Иначе говоря, иллюстрация и реальный объект не идентичны; между иллюстрацией и проблемной областью нет точного соответствия. Аналогичным образом проектные решения можно принимать только при наличии утвержденной архитектуры.