Главная » Архитектура ПО » Когда видите единственное решение, спросите других

0

Тимоти Хай

Вероятно, вам уже доводилось слышать это высказывание. Каждый опытный архитектор знает: если он видит только одно решение задачи, это плохой признак.

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

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

Такая ситуация крайне редко возникает из-за реального отсутствия альтернатив. Гораздо более вероятное объяснение – неопытность архитектора в предметной области конкретной задачи. Если вы знаете, что это относится к вам, не постесняйтесь обратиться за советом к кому-нибудь из более опытных в этом вопросе коллег.

Другое, более коварное проявление этой проблемы встречается при проектировании архитектуры «по привычке». Архитектор может иметь богатый опыт применения одного архитектурного стиля (например, трехуровневая система типа клиент-сервер), но ему не хватает знаний, чтобы определить, когда этот стиль неуместен. Если вы оказались в ситуации, когда решение

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

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

Начальник спросил его:

-   Что мы можем сделать для улучшения производительности?

У моего друга уже был готов ответ:

-   Купить более мощную машину!

-   А что еще?

-   М-м-м… Насколько я знаю, ничего.

Моего друга немедленно уволили. Разумеется, начальник был прав. Биография автора приведена на стр. 117.

Источник: Форд Н., Найгард М., де Ора Б., 97 этюдов для архитекторов программных систем. – Пер. с англ. – СПб.: Сим- вол-Плюс, 2010. – 224 с., ил.

По теме:

  • Комментарии