Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
А почему вы никак, вообще ни словом не упоминаете об актуализации и тестировании всех систем, взаимодействующих с вашей БД?
Спасибо! Действительно упустил. Добавил небольшой пункт в советы.
«Небольшой пункт», серьезно? Половина Database Refactoring посвящена тому, как решать эту проблему, а вы обошлись «небольшим пунктом»?
На основании чего?
А если это не «коллеги», а другая компания, давно ушедшая с контракта? А если такого списка нет?
Угу, вам будет легче проводить рефакторинг (на самом деле, нет), зато их жизнь существенно усложнится, потому что теперь они не могут использовать стандартные инструменты, которые работали с таблицами (например, ORM), и вынуждены использовать те или иные костыли, которые работают с процедурами и функциями.
Ну и да, добротный гвоздь в крышку: а если код приложения недоступен (как следствие, его нельзя ни модифицировать, ни проанализировать)?
Составьте список приложений, использующих Вашу базу.
На основании чего?
Попросите, по возможности, коллег разрабатывающих эти приложения выдать Вам список объектов, которые они используют.
А если это не «коллеги», а другая компания, давно ушедшая с контракта? А если такого списка нет?
Обсудите с коллегами чтобы они вместо таблиц перешли на использование представлений (процедур).
Когда все обращения к базе будут реализованы посредством процедур/представлений/функций, Вам будет намного легче проводить рефакторинг.
Угу, вам будет легче проводить рефакторинг (на самом деле, нет), зато их жизнь существенно усложнится, потому что теперь они не могут использовать стандартные инструменты, которые работали с таблицами (например, ORM), и вынуждены использовать те или иные костыли, которые работают с процедурами и функциями.
Ну и да, добротный гвоздь в крышку: а если код приложения недоступен (как следствие, его нельзя ни модифицировать, ни проанализировать)?
Проблем действительно много. И не всем уделено внимание в книге Database Refactoring. У каждого встречаются свои тараканы.
В статье я лишь показал использование базовых методов рефакторинга.
Давайте соберемся и напишем отдельную статью на эту тему?
В статье я лишь показал использование базовых методов рефакторинга.
Давайте соберемся и напишем отдельную статью на эту тему?
В статье я лишь показал использование базовых методов рефакторинга.
Будем честными, для меня ваша статья выглядит как «методы рефакторинга, доступные в SQL Refactor Studio». Например, добавление исторических таблиц/триггеров — это вообще не рефакторинг.
Но самое важное то, что для рефакторинга критична проверка сохранения работоспособности, а вы эту тему, как уже сказано, не затронули практически.
На основании чего?
Посвятите, пожалуйста, в ужасающий пример невозможности определения приложений, использующих базу.
Почему же сразу «невозможности»?
Вот вы пришли на проект, он пять лет развернут в продуктиве в достаточно крупной (и весьма безалаберной) организации. Как вы узнаете, какие приложения используют его БД?
Вот вы пришли на проект, он пять лет развернут в продуктиве в достаточно крупной (и весьма безалаберной) организации. Как вы узнаете, какие приложения используют его БД?
Отключу БД.
В продуктиве? Очень мило. На сколько?
Как правило нескольких минут достаточно, чтоб начались агрессивные звонки в тех.отдел с просьбой вернуть все как было. Далее можно начинать рефакторить, а «забытые приложения» уже сами всплывут. Поверьте, этот подход куда действенее, чем попытка отыскать пользователей по «горячим следам».
За несколько минут по звонкам вы определите основные line-of-business (которые и так известны, чего уж), и менеджмент которых придет к вам со строгим наказом никогда так больше не делать.
А что делать со всеми остальными малозаметными интеграциями, которые упадут через два месяца после выкатки вашего рефакторинга в продуктив?
А что делать со всеми остальными малозаметными интеграциями, которые упадут через два месяца после выкатки вашего рефакторинга в продуктив?
А что делать со всеми остальными малозаметными интеграциями, которые упадут через два месяца после выкатки вашего рефакторинга в продуктив?
А что тут сделать. Варианта два:
1. Пытаться определить их «по хорошему», что приведет к трате большого количества времени и вопросом начальства вида — чем это ты столько времени занимаешься?
2. Починить проблемы по мере поступления.
Я двумя руками за первый вариант, но чаще всего он ни к чему не приведет, тем более потребность в рефакторинге начальство никогда не испытывает, а если что то начинает ломаться, всегда дадут время это исправить ;)
если что то начинает ломаться, всегда дадут время это исправить
Правда? Если у вас упадет отчет в контролирующее ведомство в день подачи, то чинить его придется в тот же день любой ценой. Вы правда этого хотите?
Потому так редко делается рефакторинг в информационных системах, связанных с гос. структурами. Хотеть я этого не хочу, но рефакторинг делал (когда работал с гос. структурами), ибо 1 ночь понервничать лучше, чем год копаться в говнокоде.
А вы думаете, контролирующие ведомства бывают только в госухе? Отчет для заседания правления ровно в той же категории находится, если что.
Ну и да, речь идет не о том, чтобы не делать рефакторинг, а о том, что есть альтернативные, недеструктивные способы рефакторинга, которые позволяют пережить подобные проблемы. Просто это тяжелее и медленнее.
Ну и да, речь идет не о том, чтобы не делать рефакторинг, а о том, что есть альтернативные, недеструктивные способы рефакторинга, которые позволяют пережить подобные проблемы. Просто это тяжелее и медленнее.
А вы думаете, контролирующие ведомства бывают только в госухе?
А не думаю, я уверен что в госухе нет контролирующих ведомств. Но сейчас не об этом.
Просто это тяжелее и медленнее.
Как я уже говорил ранее, начальству этот тяжелый, медленный, да и вообще любой рефакторинг не нужен (как правило), потому либо вы будете действовать себе на благо, либо копаться в говнокоде.
Не могу уловить вашу позицию. Вы с моими словами не согласны?
не думаю, я уверен что в госухе нет контролирующих ведомств.
Зря. Но речь правда не об этом.
Как я уже говорил ранее, начальству этот тяжелый, медленный, да и вообще любой рефакторинг не нужен (как правило), потому либо вы будете действовать себе на благо, либо копаться в говнокоде.
Понимаете ли в чем дело, если начальству рефакторинг не нужен, то единственное обоснование, которое вы сможете выдать для остановки системы в продуктиве — ваша же ошибка. За которую вам же и влетит. И последующие остановки сопряженных систем — тоже ваши ошибки, которые вы будете исправлять за счет своего времени.
Не могу уловить вашу позицию. Вы с моими словами не согласны?
Конечно, не согласен. Нельзя делать опасные для работоспособности продуктивной системы действия без согласия заказчика.
Понимаете ли в чем дело, если начальству рефакторинг не нужен, то единственное обоснование, которое вы сможете выдать для остановки системы в продуктиве — ваша же ошибка. За которую вам же и влетит.
Таки вы хотите и на пеньке посидеть, и ватрушку вкусить. Мой опыт подсказывает, что не получится.
без согласия заказчика
Еще раз повторю, заказчику все равно на этот ваш рефакторинг. Делаете его вы сугубо для того, чтобы вам не копаться в говнокоде.
Таки вы хотите и на пеньке посидеть, и ватрушку вкусить. Мой опыт подсказывает, что не получится.
А мой опыт показывает, что если рефакторинг заказчику выгоден, то заказчик на него можно уговорить. А если невыгоден, то зачем его проводить?
Делаете его вы сугубо для того, чтобы вам не копаться в говнокоде.
Вот именно поэтому вы не можете взять и остановить ради своего рефакторинга продуктивную систему.
Точнее, конечно, не заказчику (выгоден рефакторинг), а вашему начальству. А уже ваше начальство договаривается с заказчиком, используя соответствующие формулировки.
А мой опыт показывает, что если рефакторинг заказчику выгоден, то заказчик на него можно уговорить. А если невыгоден, то зачем его проводить?
Ну если вам удасться убедить заказчика, что он получит некий выигрышь в будущем, но за это ему придется заплатить уже сегодня, при чем система уже работает, то вам нужно не программистом, а продавцом работать )
Вот именно поэтому вы не можете взять и остановить ради своего рефакторинга продуктивную систему
Ну как же не могу, могу, и даже приходилось делать. Чаще, конечно, все решалось более элегантрыми методами.
Ну если вам удасться убедить заказчика, что он получит некий выигрышь в будущем, но за это ему придется заплатить уже сегодня, при чем система уже работает, то вам нужно не программистом, а продавцом работать
А просто не надо делать рефакторинг, когда система «уже работает». Включите его в косты доработки (а лучше — в косты разработки) — и все. И не будет никакого «в будущем».
Ну как же не могу, могу, и даже приходилось делать.
Ну то есть я правильно понял, вы можете, не объясняя причин (и не неся ответственности) остановить продуктивную систему (что обычно влечет за собой те или иные потери заказчика)?
А просто не надо делать рефакторинг, когда система «уже работает». Включите его в косты доработки (а лучше — в косты разработки) — и все. И не будет никакого «в будущем».
Как мне включить его в уже оплаченную, разработанную (не мной) и запущенную систему?
Ну то есть я правильно понял, вы можете, не объясняя причин (и не неся ответственности) остановить продуктивную систему (что обычно влечет за собой те или иные потери заказчика)?
В идеале да.
Как мне включить его в уже оплаченную, разработанную (не мной) и запущенную систему?
Никак. Если она оплачена, разработана и запущена, просто не надо ее трогать.
В идеале да.
И вам не кажется, что это безответственно по отношению к заказчику?
Всех уволить, а на их места хороших набрать?
Да нет, достаточно самому уволиться.
просто не надо ее трогать.
Поддерживать то надо, или говнокод это «не так уж и плохо»?
И вам не кажется, что это безответственно по отношению к заказчику?
Безответственно по отношению к заказчику, бережно собирать и культивировать костыли в их говнокоде. Так как заказчик человек не сведующий, он должен быть мне благодарен за то, что я чищу его систему (обычно бесплатно), ценою десятка минут неработоспособности.
Да нет, достаточно самому уволиться.
Таки уволился, только идеальной организации, разрабатывающей идеальное ПО с идеальными начальниками, которые убеждают заказчика в необходимости рефакторинга, все еще не нашел. Может посоветуете какую?
Поддерживать то надо, или говнокод это «не так уж и плохо»?
Если надо поддерживать — включаете в косты поддержки.
Так как заказчик человек не сведующий, он должен быть мне благодарен за то, что я чищу его систему (обычно бесплатно), ценою десятка минут неработоспособности.
Нет, не должен быть. Вы не думали, что этот десяток минут неработоспособности может выйти ему дороже, чем весь выигрыш от вашей «чистки»?
Таки уволился, только идеальной организации, разрабатывающей идеальное ПО с идеальными начальниками, которые убеждают заказчика в необходимости рефакторинга, все еще не нашел. Может посоветуете какую?
Нет, не посоветую. Они (организации) ничем передо мной не провинились, чтобы советовать их человеку, который считает, что заказчик ему должен быть благодарен за остановку продуктива.
Если надо поддерживать — включаете в косты поддержки.
На что заказчик спросит — а чего так дорого?
Нет, не должен быть. Вы не думали, что этот десяток минут неработоспособности может выйти ему дороже, чем весь выигрыш от вашей «чистки»?
Я не рефакторю системы таким способом, если это может выйти заказчику боком.
Они (организации) ничем передо мной не провинились
На этих словах, думается, можно закончить наш милый диалог )
На что заказчик спросит — а чего так дорого?
Потому что ваша работа столько стоит. Если ваш заказчик не понимает в IT, у вас нет никакого другого способа ему что-то объяснить.
Я не рефакторю системы таким способом, если это может выйти заказчику боком.
А откуда вы знаете, может, или нет?
Потому что ваша работа столько стоит
Вам нужно сказки писать, чесслово ) Не хочу вас обидеть, но мне кажется, что вы немного лукавите. С одной стороны вы боитесь остановить работу ПО заказчика чтобы отчистить его от говнокода, с другой стороны вы предлагаете ставить заказчику условия и продавать ему то, что ему не нужно )
А откуда вы знаете, может, или нет?
Ну я не работаю методом — пришел, сел, заварил чай, начал программировать. Если о системе нет вообще никакой инфы, то вы ее не отрефакторите никакими методами.
На этих словах, думается, можно закончить наш милый диалог )
Может все таки закончим, а? Думается у нас разная позиция и друг друга мы убедить не сможем.
с другой стороны вы предлагаете ставить заказчику условия и продавать ему то, что ему не нужно )
Я не предлагаю продавать то, что не нужно. И да, я предлагаю ставить ему условия, потому что работать без условий — это рабство.
Если о системе нет вообще никакой инфы, то вы ее не отрефакторите никакими методами.
Ну можно же сначала собрать информацию. А если можно ее собрать, то зачем останавливать систему?
Напомню, вы предлагаете остановить БД, чтобы узнать, кто к ней подключен. Если вы не знаете, кто к ней подключен (а иначе зачем ее останавливать) — это означает, что вы не знаете, какие последствия будут у останова.
Я не предлагаю продавать то, что не нужно
Повторюсь, заказчику рефакторинг не нужен.
И да, я предлагаю ставить ему условия, потому что работать без условий — это рабство.
А вы точно с государством работали?
Ну можно же сначала собрать информацию. А если можно ее собрать, то зачем останавливать систему?
Можно и нужно, но бывают случае, когда информацию о рисках собрать получается (что довольно просто), а вот технические подробности, что с чем связано, никак не собрать.
Если вы не знаете, кто к ней подключен (а иначе зачем ее останавливать) — это означает, что вы не знаете, какие последствия будут у останова.
Повторюсь — узнать о рисках проще, чем узнать о технических подробностях и зависимостях. Я не пропагандирую этот метод как единственно-верный, но он не раз пролевал свет на сложные зависимости в БД и ПО.
Повторюсь, заказчику рефакторинг не нужен.
Значит, не надо его делать.
А вы точно с государством работали?
Без малого пять лет.
Можно и нужно, но бывают случае, когда информацию о рисках собрать получается (что довольно просто), а вот технические подробности, что с чем связано, никак не собрать.
И как же вы, зная, что отключение БД влечет за собой риск срыва критического отчета, все-таки отключите ее, чтобы узнать, какие системы с БД связаны?
Без малого пять лет.
И вы ставили условия государству?
И как же вы, зная, что отключение БД влечет за собой риск срыва критического отчета, все-таки отключите ее, чтобы узнать, какие системы с БД связаны?
Почему вы считаете, что я отключал БД под риском срыва критического отчета?
И вы ставили условия государству?
Я озвучивал условия выполнения задачи начальству, а те — заказчику. Не вижу в этом ничего странного.
Почему вы считаете, что я отключал БД под риском срыва критического отчета?
Я не считаю, я спрашиваю. Если не отключали — то как же вы выясните, какие системы с ней связаны?
Я озвучивал условия выполнения задачи начальству, а те — заказчику. Не вижу в этом ничего странного.
Мой опыт обычно сводился к следующему: есть бюджет, который пилится на 2 части, одна из которых идет в фирму, после чего еще немного пилится (ибо на фирме не только программисты живут), а остаток получает отдел. Озвучивать условия выполнения начальству конечно можно, но эти условия должны либо согласоваться с бюджетом, выделенным на проект (да, он выделяется заранее, а не на основании ваших условий), либо компания с этим заказчиком не работает.
Если не отключали — то как же вы выясните, какие системы с ней связаны?
Как уже говорил ранее, сначала оцениваются риски, затем принимается решение о способе анализа зависимостей. Как уже говорил ранее, узнать о рисках намного проще, чем о технических подробностях.
Озвучивать условия выполнения начальству конечно можно, но эти условия должны либо согласоваться с бюджетом, выделенным на проект (да, он выделяется заранее, а не на основании ваших условий), либо компания с этим заказчиком не работает.
Ну вот и прекрасный второй вариант.
Как уже говорил ранее, сначала оцениваются риски, затем принимается решение о способе анализа зависимостей. Как уже говорил ранее, узнать о рисках намного проще, чем о технических подробностях.
Прекрасно, мы выяснили, что риск высокий. Дальше что делать?
Ну вот и прекрасный второй вариант.
Вам нельзя в продавцы )))
Прекрасно, мы выяснили, что риск высокий. Дальше что делать?
Однозначно не отключать БД. Использовать другие методы нахождения зависимостей.
Использовать другие методы нахождения зависимостей.
Какие?
(собственно, с этого и надо было начинать)
(собственно, с этого и надо было начинать)
Я понимаю что вам очень интересны другие методы анализа зависимостей (либо вы хотите, чтоб о них упомянули), но я начал с одного из методов (при чем самого действенного) и считаю, что его не следует списывать со счетов.
Какие?
Опрос, тестирование, анализ структуры, анализ логов и т.д.
Гораздо лучше эти несколько минут мониторить подключения к базе. А лучше подольше, хотя бы месяц — некоторые клиенты запускаются только раз в месяц максимум.
Хотелось бы побольше узнать про миграции данных. Допустим у вас есть несколько клиентов на версиях 1.0 2.0 3.0
1) Есть ли какой-нибудь способ миграции данных клиента 1.0 на 4.0 кроме последовательных миграций на промежуточные версии
2) Если между соседними релизами было несколько последовательных зависимых друг от друга миграций, есть ли способ миграции клиента напрямую на релиз без прогона всего промежуточного. Есть ли инструменты, которые это облегчают?
1) Есть ли какой-нибудь способ миграции данных клиента 1.0 на 4.0 кроме последовательных миграций на промежуточные версии
2) Если между соседними релизами было несколько последовательных зависимых друг от друга миграций, есть ли способ миграции клиента напрямую на релиз без прогона всего промежуточного. Есть ли инструменты, которые это облегчают?
А что будет с городом который имеет одинаковое название но находится в разных странах?
liquibase имеет обширный инструмент рефакторинга БД
Перед тем, как что-либо трогать, полезно проверить programmability в БД на отсутствие ссылок на это что-то в тексте сторед-процедур (там может быть и динамика!), функций и триггеров — например, испустив следующее:
Ну и вообще, полезно знать, где и зачем используется динамика — для этого можно найти все EXEC и sp_execute_sql в текстах всех процедур и посмотреть, насколько хитро там формируются стейтменты — иногда может оказаться, что строки на исполнение берутся из полей таблиц ;)
select * from syscomments where text like '%<object_to_change>%'
Ну и вообще, полезно знать, где и зачем используется динамика — для этого можно найти все EXEC и sp_execute_sql в текстах всех процедур и посмотреть, насколько хитро там формируются стейтменты — иногда может оказаться, что строки на исполнение берутся из полей таблиц ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рефакторинг схем баз данных