Анализ зависимостей
Mar. 15th, 2013 09:36 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Есть небольшая опердень, в которой несколько сотен различных объектов - таблицы, вьюшки, хранимые процедуры, запросы, гуишные окна, справочники и прочая дб-центрик хрень. Часть из этих вещей по историческим причинам устарела.
Я вот думаю, сделать автоматический анализатор графа зависимостей между между всем этим, чтобы создать список, "чего нахрен удалить" или по старинке, руками и только то, что нужно на текущий момент.
А то очень уж близко к зоопарку с яками изготовление анализатора зависимостей, хоть он и займет день-два в разработке.
Я вот думаю, сделать автоматический анализатор графа зависимостей между между всем этим, чтобы создать список, "чего нахрен удалить" или по старинке, руками и только то, что нужно на текущий момент.
А то очень уж близко к зоопарку с яками изготовление анализатора зависимостей, хоть он и займет день-два в разработке.
no subject
Date: 2013-03-15 06:42 am (UTC)no subject
Date: 2013-03-15 06:46 am (UTC)no subject
Date: 2013-03-15 06:55 am (UTC)no subject
Date: 2013-03-15 06:58 am (UTC)no subject
Date: 2013-03-15 07:02 am (UTC)no subject
Date: 2013-03-15 08:44 am (UTC)Посчитайте внимательно.
Должно быть 83%.
no subject
Date: 2013-03-15 12:36 pm (UTC)no subject
Date: 2013-03-15 08:05 am (UTC)Поэтому проект чуть более чем наполовину (!!!!) состоял из кода, который не используется. Но в силу специфики проекта и корцедусов, код который не используется, все еще остается вызываемым. Например в ветках if'ов, которые никогда не выполнятся и т.п.
Таким образом полностью автоматическая система должна как минимум обладать интеллектом среднего разработчика для того, чтобы выяснить, что же из этого надо удалять.
В общем я это все к тому, что полная автоматика, как показывает практика, не слишком применима в данных условиях. И вместо того, чтобы потратить Н времени на разработку автоматики, лучше потратить Н/4 времени на разработку простых инструментов для того, чтобы разгребать зоопарк в полуавтоматическом режиме или для того, чтобы облегчить ручной разбор.
Ей богу, руками, grep'ом и крепким словом я разгреб это барахло куда раньше чем сваял бы внятную систему анализа зависимостей. (:
Конечно я разгреб еще не все, потому что там остались еще более запутанные куски, которые требуют глубокого анализа, но с такими кусками, очевидно, автоматика не справится еще больше.
no subject
Date: 2013-03-15 09:43 am (UTC)Плюс он не сколько код, сколько базу анализировать собирается.
no subject
Date: 2013-03-15 09:46 am (UTC)Я скорее рассматриваю эти проблемы как впринципе свойственные ситуации "куча устаревшего и неиспользуемого кода".
no subject
Date: 2013-03-15 09:57 am (UTC)В целом с вашим исходным посылом согласен - зачастую полуавтоматически будет проще, корректней и быстрее.
no subject
Date: 2013-03-15 09:58 am (UTC)Абсолютно согласен. Я всего лишь поделился своим опытом сражения с аналогичной проблемой. В конце концов, чем больше точек зрения можно обдумать, тем более взвешенное решение можно принять. (:
no subject
Date: 2013-03-15 10:02 am (UTC)no subject
Date: 2013-03-15 12:58 pm (UTC)no subject
Date: 2013-03-15 01:04 pm (UTC)no subject
Date: 2013-03-15 01:09 pm (UTC)no subject
Date: 2013-03-15 01:11 pm (UTC)no subject
Date: 2013-03-15 09:46 am (UTC)no subject
Date: 2013-03-15 09:50 am (UTC)В случае если код используется только в ветке if которая никогда не отработает и это можно легко доказать простым анализом кода, то такая чистка достаточно безопасна. Но бесспорно, если есть юнит-тесты оно то завсегда лучше.
Впрочем, это никак не относится к вопросу "руками или автоматикой". Автоматика тоже может иметь ошибки и тоже может удалить что то лишнее. Или не удалить чего то что стоило бы.
no subject
Date: 2013-03-15 11:26 am (UTC)no subject
Date: 2013-03-15 11:39 am (UTC)Там могут быть внутренние ошибки типа "неправильно посчиталось", но они ищутся другими методами, тут главное, чтобы не удалить что-нибудь из используемых запросов.
no subject
Date: 2013-03-15 12:59 pm (UTC)