5. Вы запускаете сценарии проверки и осуществляете выборочную проверку данных.

6. Вы проводите регрессионное тестирование приложения и смотрите, что перестало работать.

7. Вы пишете сценарии для вставки отсутствующих данных и исправления ошибок.

8. Вы повторяете шаги с 1 по 7.

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

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

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

Биография автора приведена ранее.

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

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

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

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

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

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

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

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

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

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

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

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