ВВЕДЕНИЕ

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

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

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

Важной частью этого подхода является неоднократное количество итераций, когда необходимо запускать весь жизненный цикл программного обеспечения много раз в течение жизни проекта. Гибкие процессы выполняют полные жизненные циклы в каждой итерации, завершая итерацию рабочим, протестированным, интегрированным кодом для небольшого подмножества требований конечного продукта. Эти итерации короткие, обычно выполняются от недели до нескольких месяцев, хотя основное предпочтение отдается более коротким итерациям. Считалось, что такое итерационное проектирование не может применяться для БД, так как изменение схемы БД на поздних этапах разработки приводит к повсеместным сбоям в прикладном программном обеспечении. Кроме того, изменение схемы данных после развертывания приводит к обширным проблемам транзакции данных.

Корпорация «СотВоркс» в 2014 году приступила к большому проекту «Атлас» разработки БД большого объема, используя множество гибких методов и технологий экстремального программирования. В проекте приняли участие почти 100 человек на нескольких сайтах по всему миру (США, Австралия и Индия). Этот проект содержит около полумиллиона строк кода и более 200 таблиц. БД развивается в течение полутора лет и не останавливает эволюцию, несмотря на то, что она находится в производстве для нескольких клиентов. Сначала в проекте использовали итерации, которые длились месяц, затем перешли на двухнедельные итерации, так как они лучше работали. В результате были получены ряд принципов, которые можно объединить и проанализировать для дальнейшего использования.

1. ПРИНЦИПЫ ИТЕРАЦИОННЫХ МЕТОДОВ РАЗРАБОТКИ БД БОЛЬШОГО ОБЪЕМА

Одним из принципов гибких методов является то, что люди с разными навыками и опытом должны очень тесно сотрудничать друг с другом. Они не могут общаться только через официальные встречи и документы. Они должны постоянно иметь возможность разговаривать и работать друг с другом. Это затрагивает всех: аналитиков, менеджеров по проектам, экспертов по доменам, разработчиков и администраторов БД.

Разработчик, решая каждую задачу, потенциально нуждается в помощи администратора БД. Как разработчики, так и администратор БД должны учитывать, собираются ли в задание на разработку вносить существенные изменения в схему БД. Если это так, разработчик должен проконсультироваться с администратором БД, чтобы решить, как внести изменения. Разработчик знает, какие новые функциональные возможности необходимы, и администратор БД имеет единое представление о данных в приложении.

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

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

Хотя разработчики могут часто экспериментировать в своей области, важно снова и снова возвращать разные версии и объединять их. Требуется иметь в каждый момент времени общую основную БД, из которой выполняется вся работа. Когда разработчик начинает решать задачу, он копирует основную версию проекта в собственное рабочее пространство, манипулирует им и затем присоединяет свои изменения обратно в основную версию проекта. Делает это администратор, который вносит изменения (применяя один или несколько рефакторингов БД, о которых будет ниже). Администратор БД анализирует все предложения разработчиков и сразу же вносит изменения (если они не являются деструктивными изменениями — об этом ниже).

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

С исходным кодом большая часть трудностей интеграции решается системами контроля исходного кода. Для БД требуется немного больше усилий. Любые изменения в базах данных должны выполняться правильно, как автоматические рефакторинги баз данных. Кроме того, администратор БД должен анализировать любые изменения БД и гарантировать, что они вписываются в общий план схемы БД. Чтобы это работало гладко, большие изменения не должны преподносить сюрпризы во время интеграции — отсюда необходимость тесного сотрудничества администратора БД с разработчиками.

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

2. ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ БД БОЛЬШОГО ОБЪЕМА

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

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

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

Любые изменения – это рефакторинг БД. Техника рефакторинга заключается в применении контролируемых и четко задокументированных техник для изменения существующей кодовой базы. Сложность состоит в том, что необходимо выполнить вместе три различных изменения:

• Изменение схемы БД;
• Перенос данных в БД;
• Изменение кода доступа к БД.

Процесс рефакторинга требует большего исследования, но часть результатов уже получено. Рефакторинг кода и рефакторинг БД очень мал. Концепция объединения последовательности очень маленьких изменений для БД почти такая же, как и для кода. Именно тройной характер изменения делает его более важным за счёт внесения небольших изменений.

Многие рефакторинги БД, такие как добавление столбца, могут быть выполнены без обновления всего кода, который обращается к системе. Если код использует новую схему, не зная об этом, столбец просто не будет использоваться.

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

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

Процесс рефакторинга требует автоматизации, по крайней мере, в области изменения схемы и миграции данных. Рефакторинг БД автоматизируется путем записи его в виде SQL DDL (для изменения схемы) и DML (для переноса данных). Эти изменения никогда не применяются вручную, вместо этого они применяются к основной версии проекта, запустив небольшой сценарий SQL для выполнения изменений.

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

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

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

Тот же сценарий рефакторинга, который обновляет основную версию проекта, автоматически обновляет все БД разработчиков, чтобы не возникало проблем с версиями обновлений.

Чтобы понять последствия рефакторинга БД, важно уметь видеть, как БД используется приложением. Если SQL разбросан вокруг базы кода, это очень сложно сделать. В результате важно иметь четкий уровень доступа к БД, чтобы показать, где и как используется БД. Наличие четкой архитектуры БД имеет ряд ценных побочных преимуществ. Это минимизирует области системы, в которых разработчикам требуются знания SQL для управления БД, что облегчает жизнь разработчикам, которые зачастую не особенно разбираются в SQL. Для администратора БД предоставляется четкий раздел кода, на который он может посмотреть, чтобы увидеть, как используется БД. Это помогает подготовить индексы, оптимизировать БД, а также посмотреть в SQL, чтобы увидеть, как его можно модифицировать для повышения производительности.

Это позволяет администратору БД лучше понять, как используется БД.

ЗАКЛЮЧЕНИЕ

Использование гибких итерационных методов требует выполнение большого количества повторяющихся задач, что приводит к необходимости автоматизации процесса. Рассмотренные особенности использования итерационных методов для разработки БД на примере проекта «Атлас» позволяют построить следующий сценарий:

• Знакомство пользователя с текущей версией проекта;
• Создание нового пользователя;
• Копирование схемы БД. Например, Сью находит ошибку в своей БД, теперь Майк может скопировать БД Сью и попытаться отладить приложение;
• Перемещение БД. Например, с одного рабочего места на другое, это, по сути, копирование БД и удаление БД, объединенные в одну;
• Удаление пользователя;
• Экспорт пользователя. Для создания членами команды автономных резервных копий БД, с которой они работают;
• Импорт пользователя. Если у членов группы есть резервная копия БД, они могут импортировать резервную копию и создать новую схему;
• Экспорт базовой версии — сделать резервную копию основной версии проекта БД. Это специализированный случай экспорта пользователя;
• Создание отчета о различиях любого числа схем, чтобы Майк мог выяснить, что структурно отличается между его БД и Сью;
• Сравнение схемы с основной версией проекта, чтобы разработчики могли сравнить свою локальную копию с основной версией проекта;
• Составление списка всех пользователей.