97 этюдов для архитекторов программных систем
Шрифт:
Обдумывая архитектуру для своих проектов, вы должны представлять себе объем работы, необходимый для реализации каждого элемента вашего дизайна. Если какой-то элемент вы уже разрабатывали ранее, вам будет намного проще оценить объем работы.
Не применяйте при проектировании шаблоны, которые вы не использовали прежде. Не полагайтесь на инфраструктуры, с помощью которых вы никогда ничего не разрабатывали. Не используйте сервер, который вам не доводилось настраивать. Если архитектура зависит от элементов, с которыми вы никогда не имели дела лично, возникает целый ряд отрицательных побочных эффектов:
• Вы не
• Вы не знаете, какие «ловушки» могут подстерегать вас при использовании этих элементов. На практике все обязательно пойдет не так гладко, как на демонстрации, которую проводил эксперт в этой технологии. Если прежде вы никогда не работали с технологией, вас неизбежно ждут неприятные сюрпризы.
• Вы лишитесь доверия своих разработчиков. Если вы не можете уверенно ответить на вопросы, относящиеся к вашему дизайну, разработчики быстро перестанут доверять вам и вашим творениям.
• Вы подвергаетесь излишнему риску; нехватка знаний ставит жирный вопросительный знак на ключевых элементах решения. Никто не захочет начинать проект, имея в багаже огромный ненужный риск.
Как же архитектор должен подходить к освоению новых инфраструктур, шаблонов и серверных платформ? Об этом вам расскажет этюд «Архитектор — прежде всего разработчик».
Биография автора приведена ранее.
«Что значит имя?», или Как роза превращается в капусту
Сэм Гардинер
Я случайно подслушал разговор архитекторов, которые принимали решение о необходимости дополнительных уровней в их архитектуре. Они были правы, но, как это нередко случается, подошли к делу немного не с той стороны. Они пытались создать инфраструктуру, которая включала бы в себя бизнес-логику. Вместо того чтобы решать конкретную задачу, они задумали создать инфраструктуру, которая инкапсулирует базу данных и создает объекты. И при этом она должна была использовать объектно-реляционные отображения. И сообщения. И веб-службы. И должна была делать массу других Классных Штук.
К сожалению, еще не было точно известно, какие Классные Штуки она должна вытворять, поэтому архитекторы не знали, как ее назвать. Им пришлось затеять небольшой конкурс на лучшее имя. В подобный момент вы должны понять, что столкнулись с проблемой: если вы не знаете, как что-то назвать, то вы не знаете, что это такое. А если вы не знаете, что это такое, то вы не сможете сесть и написать программный код.
В нашем конкретном случае быстрый просмотр истории версий исходного кода выявил всю глубину проблемы. Конечно, в нем оказалось множество пустых «реализаций» интерфейсов! Но самое смешное, что даже без нормального кода имена уже менялись трижды. Сначала было выбрано имя ClientAPI (причем под «клиентом» имелся в виду заказчик, а не клиент в контексте модели «клиент-сервер»), а последняя версия называлась ClientBusinessObjects. Воистину замечательное
Конечно, имя — это всего-навсего указатель. Как только все участники будут знать, что имя — это просто имя, а не архитектурная метафора, вы сможете двигаться дальше. Но если вы не можете договориться о выборе имени, которое было бы достаточно конкретным, чтобы вы сразу могли понять, подходит оно или нет, то вам будет сложно даже приступить к решению задачи. Все проектирование направлено на реализацию намерений (например, быстрота, гибкость, экономичность), а имена отражают эти намерения.
Если вы не в состоянии что-либо назвать, то не сможете это и реализовать. Если вы меняете имя уже в третий раз, приостановите свою деятельность и попытайтесь понять, что же вы собираетесь построить.
После продолжительных развлечений с компьютерами (от написания игр на Basic на компьютере ВВС до применения Pascal, Мathematica и LabVIEW для обработки экспериментальных данных, которые хранились в «базе данных» из скрепленных скотчем папок) Сэм Гардинер (Sam Gardiner) перешел к профессиональной разработке ПО. Он работает в сфере программирования на протяжении шести лет.
Четко определенные задачи решаются качественно
Сэм Гардинер
Реальная практика программирования представляет собой отнюдь не решение задач, которые дал вам кто-то другой. Конечно, в учебном классе вы должны были решать задачу двоичной сортировки, полученную от преподавателя. Но в реальном мире лучшие архитекторы заняты не решением сложных задач, а поиском для них обходных путей. Их искусство проявляется в умении проложить границы между разнотипными и расплывчатыми задачами, чтобы сделать их четко определенными и автономными.
Архитектор вникает в мешанину концепций, данных и процессов и разбивает их на меньшие фрагменты. Важнейшим качеством таких фрагментов является четкая определенность задачи, что позволяет решить их законченными и четко определенными фрагментами системы. Основные свойства фрагментов задачи таковы:
• Внутренняя связность: фрагмент является концептуально цельным, то есть все его задачи, данные и функциональные возможности связаны друг с другом.
• Изолированность: фрагменты концептуально нормализованы, то есть практически не перекрываются друг с другом.
Подобно человеку с хорошей ориентацией на местности, который подсознательно знает, где находится в данный момент, человек, в совершенстве владеющий методом фрагментирования задачи, может даже не осознавать, что использует его, — ему просто кажется разумным разбить задачи, данные и функциональные возможности так, чтобы сформировать удобную логическую границу или интерфейс. (Естественно, речь идет не об интерфейсах из объектно-ориентированных языков, а о границах системы.)
Например, реляционная СУБД имеет очень хорошую границу. Она работает практически с любыми данными, которые могут быть преобразованы в поток байтов, обеспечивая структурирование, поиск и выборку этих данных. Все просто.