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

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

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

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

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

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

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

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

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

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