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

Рассматривайте архитектурные решения как инвестиции и анализируйте связанную с ними окупаемость; это полезный метод оценки реалистичности и практичности имеющихся вариантов.

Джордж Маламидис (George Malamidis) — разработчик программного обеспечения в компании TrafftcBroker (Лондон). До этого был ведущим консультантом и ведущим техническим специалистом в ThoughtWorks. Участвовал в разработке и внедрении критических приложений в разных областях, от сетевых и финансовых приложений до Web 2.0.

Ваша система станет унаследованной — учитывайте это при проектировании

Дейв Андерсон

Даже если вы создаете сверхсовременную систему на базе новейших технологий, для вашего преемника она станет унаследованной (legacy). С этим ничего не поделаешь! Современному программному обеспечению свойственно быстро устаревать. Если вы ожидаете, что ваша система будет запущена в реальную эксплуатацию и просуществует хотя бы несколько месяцев, смиритесь с тем, что сопровождающим ее разработчикам придется вносить в нее исправления. Отсюда вытекает ряд требований к системе:

• Ясность: должно быть сразу понятно, какую роль играет тот или иной компонент или класс.

• Удобство тестирования: насколько легко проверить вашу систему?

• Корректность: работает ли система так, как было задумано? Исключите исправления, вносимые на скорую руку.

• Трассируемость: сможет ли специалист-«пожарник», никогда прежде не видевший ваш код, диагностировать ошибку в работающей системе и исправить ее? Или же на то, чтобы войти в суть дела, ему потребуются два месяца?

Попробуйте представить себе, что будет, если какая-то другая команда откроет вашу базу кода и попытается в нем разобраться. Это наиважнейший аспект хорошей архитектуры. Систему необязательно чрезмерно упрощать или документировать до мельчайших подробностей; хороший дизайн во многих отношениях документирует сам себя. Кроме того, дизайн может проявлять себя в поведении системы во время эксплуатации. Например, система с «разросшейся» архитектурой, опутанной уродливыми зависимостями, в эксплуатации часто ведет себя, как зверь в клетке. Подумайте о других (обычно менее опытных) разработчиках, которым придется исправлять ошибки в вашей программе и отлаживать код.

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

Дейв Андерсон (Dave Anderson) — главный специалист по разработке ПО в компании Liberty IT (Белфаст), которая поставляет IT-решения для компании Liberty Mutual, входящей в список Fortune 100. Дейв обладает более чем 10-летним опытом разработки ПО для многих ведущих IT-компаний в разных отраслях и странах.

Когда видите единственное решение, спросите других

Тимоти Хай

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

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

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