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

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

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

Тогда почему мы беспокоимся о том, когда следует внести добросовестные изменения — сейчас или потом? Потому что изменения «на скорую руку» сопряжены со скрытыми расходами. В финансовой сфере такие скрытые расходы на кредит называются процентами; любой владелец кредитной карты знает, как дорого может обходиться простая выплата процентов по кредиту.

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

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

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

Берк Хафнагель (Burk Hufnagel) создает пользовательские приложения с 1978 года. В настоящее время работает ведущим архитектором ПО в LexisNexis.

Не спешите решать задачи

Збен Хьюит

Практически все архитекторы когда-то были разработчиками. Разработчикам платят за решение задач из области программирования, менее масштабных по сравнению с архитектурными задачами. Как правило, это мелкие каверзные алгоритмические задачи. Они часто представлены в книгах и учебных курсах так, словно существуют в отрыве от реальности, а их каверзность выглядит весьма вызывающе и соблазнительно. Со временем мы начинаем воспринимать такие задачи как данность — мы не спрашиваем, насколько осмысленна задача, интересна ли она, полезна, этична и так далее. Нам не платят за анализ роли задачи в более широком контексте. Мы приучены концентрироваться исключительно на самом решении; дело усугубляется тем, что решать сложные задачи действительно трудно. Мы привыкли брать быка за рога на собеседованиях, где перед нами по сути вываливают груду цветных леденцов, требуя рассортировать их в соответствии с некоторым набором ограничений. Нас приучают не сомневаться в этих ограничениях: они — учебный инструмент, при помощи которого мы должны самостоятельно открыть то, что уже известно учителю или экзаменатору.

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

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