Рефакторинг баз данных

Существует масса стереотипов типа "Проектирование БД - это сложно и поэтому должно проводиться один раз и на века". А фразу "изменение структуры БД" на работающем проекте стараются вообще не произносить вслух.  Ведь нужно не просто внести изменения, а сделать их так, чтобы после этого приложение работало как раньше... Все эти страхи и мифы и пытается разрушить Антон Кекс в своем докладе "Рефакторинг баз данных" (презентация).

Доклад предназначен не только для разработчиков баз данных (как можно подумать из названия), но и для обычных девелоперов. Так как, во-первых, не знаешь с чем столкнешься в будущем. А во-вторых, большой упор сделан именно на общепрограммерские ценности, и я лично услышал очень много мыслей касательно вообще подхода к программированию, который (с чем я полностью согласен) должен быть "agile" со всеми вытекающими. Я как приверженец рефакторинга  должен был обязательно посмотреть это видео и не прогадал. Антон действительно профессионал. Он прошелся по очень разным темам: некоторые из них лежат на поверхности, а другие наоборот очень глубокие. Если вкратце, то в презентации последовательно освещается 6+ пунктов:

0. Вступление. Рефакторинг БД: обстоятельные ответы на вопросы: "зачем?" и "почему?". 

1. Sandboxes. Использование continiues integration для эволюционного проектирования БД. Интеграция между БД в разных sandboxes при помощи системы контроля версий.

2. Testing. Очевидно, что рефакторинг без тестов - это очень опасный процесс. Поэтому  от тестирования никуда не деться. Но все на самом деле не так сложно как кажется. 

3. Changelog. Антон рассказал про интересные тулы dbdeploy и liqubase. Эти программы ничуть не страшные и бояться ими пользоваться не нужно. Все действия производимые ими достаточно тривиальны и использовать их очень легко. Я сразу же после просмотра попробовал dbdeploy и очень доволен.

4. Proper versioning. Полезный прием: baseline. Это когда несколько скриптов (отвечающих за какие-то атомарные задачи) объединяют в один большой скрипт.

5. Continiues integration наше все. Постоянная сборка проекта, контроль версий и прогон модульных тестов.

6. Teamwork. Мысли о культурных изменениях в команде и Agile DBA.

Стоит упомянуть, что видео получилось довольно долгим (около 100 минут), но в нем есть как теория, так и практика, поэтому заскучать у меня никак не получилось. Также не могу не сказать про книгу  "Рефакторинг баз данных:  эволюционное проектирование"  (Скотт В. Эмблер, Прамодкумар Дж. Садаладж). Честно говоря, я до этого вообще не представлял что за зверь такой "рефакторинг БД" и эту книгу я вряд ли бы прочитал в ближайшем времени. Но вот после просмотра видео задумался. В любом случае теперь мне  ясно где искать расширение границ моего знания в этой области.

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

• Вести сhangelog для БД очень полезно и, что самое главное, легко;
• Deprecated-методы обязательно должны быть удалены в будущем. Для меня лично после долгого использования Java API этот тезис оказался не таким уж очевидным. Дело в том, что подход который практикуется в Java обусловлен прежде всего проблемой поддержки ранее написанного кода. А в собственном же приложении практически всегда имеется возможность отрефакторить код так, чтобы deprecated-методы больше не использовались. То же относится и к БД;
• В очередной раз убедился, что ключевая мысль рефакторинга (не только БД) в том, что изменения - это нормально и от них никуда не денешься; 
• Почти все проблемы в разработке ПО сводятся к коммуникации;
• Teamwork: Культурные изменения должны произойти с каждым человеком в команде;
• Проблемы будут всегда. Но если использовать системный подход в своей работе (писать  тесты, changelog и т.д.), то задача рефакторинга БД никакая не тупиковая и вполне себе решаема.

P.S. И да, рубашка у него реально клевая!)))