![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Анализ зависимостей
Есть небольшая опердень, в которой несколько сотен различных объектов - таблицы, вьюшки, хранимые процедуры, запросы, гуишные окна, справочники и прочая дб-центрик хрень. Часть из этих вещей по историческим причинам устарела.
Я вот думаю, сделать автоматический анализатор графа зависимостей между между всем этим, чтобы создать список, "чего нахрен удалить" или по старинке, руками и только то, что нужно на текущий момент.
А то очень уж близко к зоопарку с яками изготовление анализатора зависимостей, хоть он и займет день-два в разработке.
Я вот думаю, сделать автоматический анализатор графа зависимостей между между всем этим, чтобы создать список, "чего нахрен удалить" или по старинке, руками и только то, что нужно на текущий момент.
А то очень уж близко к зоопарку с яками изготовление анализатора зависимостей, хоть он и займет день-два в разработке.
no subject
no subject
no subject
no subject
no subject
no subject
Поэтому проект чуть более чем наполовину (!!!!) состоял из кода, который не используется. Но в силу специфики проекта и корцедусов, код который не используется, все еще остается вызываемым. Например в ветках if'ов, которые никогда не выполнятся и т.п.
Таким образом полностью автоматическая система должна как минимум обладать интеллектом среднего разработчика для того, чтобы выяснить, что же из этого надо удалять.
В общем я это все к тому, что полная автоматика, как показывает практика, не слишком применима в данных условиях. И вместо того, чтобы потратить Н времени на разработку автоматики, лучше потратить Н/4 времени на разработку простых инструментов для того, чтобы разгребать зоопарк в полуавтоматическом режиме или для того, чтобы облегчить ручной разбор.
Ей богу, руками, grep'ом и крепким словом я разгреб это барахло куда раньше чем сваял бы внятную систему анализа зависимостей. (:
Конечно я разгреб еще не все, потому что там остались еще более запутанные куски, которые требуют глубокого анализа, но с такими кусками, очевидно, автоматика не справится еще больше.
no subject
Посчитайте внимательно.
Должно быть 83%.
no subject
Плюс он не сколько код, сколько базу анализировать собирается.
no subject
no subject
Я скорее рассматриваю эти проблемы как впринципе свойственные ситуации "куча устаревшего и неиспользуемого кода".
no subject
В случае если код используется только в ветке if которая никогда не отработает и это можно легко доказать простым анализом кода, то такая чистка достаточно безопасна. Но бесспорно, если есть юнит-тесты оно то завсегда лучше.
Впрочем, это никак не относится к вопросу "руками или автоматикой". Автоматика тоже может иметь ошибки и тоже может удалить что то лишнее. Или не удалить чего то что стоило бы.
no subject
В целом с вашим исходным посылом согласен - зачастую полуавтоматически будет проще, корректней и быстрее.
no subject
Абсолютно согласен. Я всего лишь поделился своим опытом сражения с аналогичной проблемой. В конце концов, чем больше точек зрения можно обдумать, тем более взвешенное решение можно принять. (:
no subject
no subject
no subject
Там могут быть внутренние ошибки типа "неправильно посчиталось", но они ищутся другими методами, тут главное, чтобы не удалить что-нибудь из используемых запросов.
no subject
no subject
no subject
no subject
no subject
no subject