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

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

Майк Браун (Mike Brown) — ведущий разработчик в компании Software Engineering Professionals, Inc. (http://www.sep.com). Обладает 13-летним опытом работы в сфере информационных технологий, включая 8 лет разработки корпоративных решений для разнообразных вертикальных рынков. Является учредителем группы пользователей Indianapolis Alt.NET, соучредителем WPF Disciples, а также организатором группы профессиональных пользователей Indy Arc.

Окупаемость как фактор проектирования

Джордж Маламидис

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

Одним из показателей успешности инвестиций является окупаемость (ROI, Return on Investment). Например: мы предполагаем, что дополнительные затраты времени на создание тестов уменьшат количество ошибок в следующем выпуске приложения. Размер инвестиций в этом случае определяется временем, потраченным на написание тестов, а прибыль — это время, сэкономленное на исправлении ошибок в будущем, плюс удовлетворение клиентов, работающих с более качественной программой. Допустим, в настоящее время 10 из 40 рабочих часов в неделю тратятся на исправление ошибок. По нашим оценкам, выделив 4 часа в неделю на тестирование, мы сократим затраты времени на исправление ошибок до 2 часов в неделю, фактически получив 8 свободных часов, которые можно вложить во что-то другое. Прогнозируемая окупаемость составляет 200 %[35] (8 часов, сэкономленных на исправлении ошибок, делим на 4 часа, потраченных на тестирование).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тимоти Хай

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

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

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

Такая ситуация крайне