2. Предложите количественные метрики. Польза от предлагаемых вами решений должна быть измеримой (до разумной степени). Чем больше количественных показателей вы предъявите, тем убедительнее сможете обосновать свое утверждение о том, что предлагаемая архитектура обеспечит существенную отдачу. Чем раньше будут заданы метрики, тем проще вам будет управлять восприятием заинтересованных сторон — а это поможет вам убедить их в преимуществах своей архитектуры.

3. Увяжите свои данные с традиционными бизнес-метриками. Будет превосходно, если вы сумеете напрямую представить результаты технического анализа в денежном выражении. В конце концов, единственным неизменным параметром в традиционных бизнес-метриках являются деньги. Если вы недостаточно хорошо разбираетесь в финансовых тонкостях, возьмите себе в помощники бизнес-аналитика.

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

5. Выберите подходящий момент. Даже если вы выполните четыре предыдущих рекомендации и подготовите хорошее экономическое обоснование, ваша идея может провалиться из-за неудачного выбора момента ее подачи. Помню, одно из моих предложений долгое время не получало поддержки — до тех пор, пока другой проект не завершился полным крахом из-за плохой архитектуры. Разумно подходите к выбору момента.

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

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

1. Вы создаете список сценариев, которые необходимо выполнить в заданном порядке.

2. Вы отправляете сценарии конкретному администратору базы данных по электронной почте.

3. Администратор копирует сценарии в каталог, из которого они должны запускаться заданием cron.

4. Вы проверяете журнал выполнения сценариев и молитесь, чтобы все сценарии выполнились успешно, потому что не знаете точно, что произойдет при их повторном выполнении.

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

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

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

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

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

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

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

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

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