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 часа, потраченных на тестирование).
35
В действительности эффект будет не настолько сильным: переключение между задачами само по себе отнимает у разработчика существенное время, тем самым снижая его продуктивность. — Примеч. науч. ред.
Не все следует сводить к выгоде в денежном эквиваленте, однако наши инвестиции должны обеспечивать добавленную стоимость. Если в текущем проекте срок выпуска на рынок критичен для заинтересованных сторон, возможно, «пуленепробиваемая» архитектура, требующая долгого предварительного проектирования, не обеспечит такой привлекательной окупаемости, как быстрый выпуск альфа-версии. Быстрый выпуск позволит изучить реакцию аудитории, что может стать определяющим фактором выбора будущего направления и успеха проекта; в то же время планирование на скорую руку может обернуться лишними затратами из-за трудностей с масштабированием приложения, если такая необходимость возникнет. Окупаемость каждого варианта можно определить путем анализа затрат и предполагаемых прибылей, а затем использовать ее как критерий выбора при наличии нескольких альтернатив.
Рассматривайте архитектурные решения как инвестиции и анализируйте связанную с ними окупаемость; это полезный метод оценки реалистичности и практичности имеющихся вариантов.
Джордж
Ваша система станет унаследованной — учитывайте это при проектировании
Дейв Андерсон
Даже если вы создаете сверхсовременную систему на базе новейших технологий, для вашего преемника она станет унаследованной (legacy). С этим ничего не поделаешь! Современному программному обеспечению свойственно быстро устаревать. Если вы ожидаете, что ваша система будет запущена в реальную эксплуатацию и просуществует хотя бы несколько месяцев, смиритесь с тем, что сопровождающим ее разработчикам придется вносить в нее исправления. Отсюда вытекает ряд требований к системе:
• Ясность: должно быть сразу понятно, какую роль играет тот или иной компонент или класс.
• Удобство тестирования: насколько легко проверить вашу систему?
• Корректность: работает ли система так, как было задумано? Исключите исправления, вносимые на скорую руку.
• Трассируемость: сможет ли специалист-«пожарник», никогда прежде не видевший ваш код, диагностировать ошибку в работающей системе и исправить ее? Или же на то, чтобы войти в суть дела, ему потребуются два месяца?
Попробуйте представить себе, что будет, если какая-то другая команда откроет вашу базу кода и попытается в нем разобраться. Это наиважнейший аспект хорошей архитектуры. Систему необязательно чрезмерно упрощать или документировать до мельчайших подробностей; хороший дизайн во многих отношениях документирует сам себя. Кроме того, дизайн может проявлять себя в поведении системы во время эксплуатации. Например, система с «разросшейся» архитектурой, опутанной уродливыми зависимостями, в эксплуатации часто ведет себя, как зверь в клетке. Подумайте о других (обычно менее опытных) разработчиках, которым придется исправлять ошибки в вашей программе и отлаживать код.
В кругах разработчиков не любят термин «унаследованный», но на самом деле этот ярлык несет на себе любая программная система. И в этом нет ничего плохого, потому что такое определение может означать лишь то, что ваша система долговечна, соответствует ожиданиям пользователей и обладает коммерческой ценностью. Если программную систему никогда не называли унаследованной, ее, скорее всего, отправили пылиться на полке, так и не запустив, а это вряд ли можно считать свидетельством удачной архитектуры.
Дейв Андерсон (Dave Anderson) — главный специалист по разработке ПО в компании Liberty IT (Белфаст), которая поставляет IT-решения для компании Liberty Mutual, входящей в список Fortune 100. Дейв обладает более чем 10-летним опытом разработки ПО для многих ведущих IT-компаний в разных отраслях и странах.
Когда видите единственное решение, спросите других
Тимоти Хай
Вероятно, вам уже доводилось слышать это высказывание. Каждый опытный архитектор знает: если он видит только одно решение задачи, это плохой признак.