97 этюдов для архитекторов программных систем

Уважайте коллег, работающих над реализацией вашего видения системы. Прислушивайтесь к ним. Если у них возникают проблемы с вашим дизайном, вполне возможно, что они правы, а дизайн ошибочен или, по крайней мере, невнятен. В таких случаях привести дизайн в соответствие практическим требованиям — ваша непосредственная задача, и решить ее вы можете, общаясь с членами вашей команды, которые помогут вам определить, что работает, а что нет. Ни один дизайн не бывает идеальным с самого начала; любой дизайн подвержен изменениям по мере реализации.

Если вы участвуете в проекте и в качестве разработчика, научитесь ценить время, потраченное на написание кода, и не верьте тем, кто говорит, что это лишь отнимает время от работы по созданию архитектуры. Вы обретете гораздо более точное видение проекта на макро- и микроуровнях, после того как сами попробуете вдохнуть жизнь в свое творение.

Эллисон Рэндал (Allison Randal) — главный архитектор и ведущий разработчик проекта с открытым исходным кодом Parrot. За свою 25-летнюю карьеру она разрабатывала буквально все — от игр до средств лингвистического анализа, сайтов электронной коммерции, систем контроля доставки, компиляторов и систем репликации баз данных. Ей довелось побывать проектировщиком языков программирования, руководителем проектов, организатором конференций, редактором и консультантом. Эллисон была президентом фонда ПО с открытым кодом, написала две книги и основала, издательство технической литературы.

Решений на все случаи жизни не существует Рэнди Стаффорд

Архитектор должен непрерывно развивать и совершенствовать свое «контекстное чутье», поскольку единственного универсального решения для широкого круга разнородных проблем не существует.

Броское выражение «контекстное чутье» впервые использовал (с содержательным описанием его смысла) Эберхардт Рехтин (Eberhardt Rechtin) в своей книге «Systems Architecting: Creating & Building Complex Systems» (Системная архитектура: создание и построение сложных систем) (Prentice Hall, 1991):

«Чтобы узнать основные принципы „эвристического подхода“ к проектированию сложных систем, спросите опытного архитектора, что он делает, когда сталкивается с особенно сложной задачей. Его ответ, скорее всего, будет таким: „Просто использую здравый смысл“. <…> Вместо термина „здравый смысл“ лучше было бы использовать выражение „контекстное чутье“ [7] — знание о том, что является разумным в данном контексте. Образование, полученный опыт и изучение примеров позволяют архитектору-практику набрать значительную мощь контекстного чутья к тому моменту, когда ему доверяется решение проблемы системного уровня, — обычно на это уходит лет десять.»

7

Английское слово sense в зависимости от ситуации может переводиться и как «смысл», и как «чувство, чутье», поэтому в английском тексте перекличка терминов (common sense — «здравый смысл» и contextual sense — «контекстное чутье») выглядит более явной. — Примеч. ред.

Одна из серьезных проблем в индустрии разработки ПО, как мне кажется, состоит в том, что решение задач часто поручается людям, не успевшим развить достаточное контекстное чутье. Возможно, это связано с тем, что отрасль насчитывает всего два поколения и сейчас переживает стадию взрывного роста; не исключено, что исчезновение этой проблемы можно будет считать признаком зрелости отрасли.

Я часто сталкиваюсь с проявлениями этой проблемы в своей работе консультанта. Вот характерные примеры: отказ от проектирования на основе предметной области (domain-driven design) [8] там, где оно было бы уместным; утрата прагматического взгляда на вещи и чрезмерное увлечение проектированием программного решения, когда речь идет о задаче, не терпящей отлагательств; необоснованные или не имеющие отношения к делу предложения в тот момент, когда работы по оптимизации быстродействия системы заходят в тупик.

8

См. Эрик Эванс (Eric Evans) «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Проектирование на основе предметной области: как совладать с присущей программам сложностью) (Addison-Wesley Professional).

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

Биография автора приведена ранее.

Думать о производительности никогда не рано Ребекка Парсонс

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

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

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

Почему это так важно? Прежде всего, вы как минимум будете знать о том, какие именно изменения привели к резкому падению производительности. Если в системе возникнут проблемы с производительностью, вам не придется анализировать всю архитектуру целиком — достаточно будет сосредоточиться на тех моментах, которые менялись недавно. Рано приступив к тестированию производительности и часто его выполняя, вы сузите круг изменений, которые следует подвергать анализу.

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

Этот подход позволяет также проверять решения, принятые в ходе проектирования и работы над архитектурой системы, в контексте реальных требований к производительности. Если к системе предъявляются жесткие требования, такая ранняя проверка особенно важна для своевременной поставки готовой системы.

Хорошо известно, что организовать техническое тестирование — непростая задача. Настройка окружения, генерация наборов данных, определение необходимых тестовых сценариев (test case) — все это занимает много времени. Раннее тестирование производительности способствует поэтапному формированию тестовой среды, избавляя вас от существенно больших затрат времени и усилий при обнаружении проблем с производительностью на более поздней стадии.

Доктор Ребекка Парсонс (Rebecca Parsons) — технический директор ThoughtWorks. Она обладает более чем 20-летним опытом разработки приложений в различных отраслях, от телекоммуникаций до новых интернет-сервисов. Ребекка имеет печатные публикации по языкам программирования и искусственному интеллекту, работала в ряде комитетов в области программирования и написала множество журнальных статей. У нее есть обширный опыт в области создания, крупномасштабных распределенных объектных приложений и интеграции разнородных систем.