Анализ зависимостей

[metaclass]

Есть небольшая опердень, в которой несколько сотен различных объектов - таблицы, вьюшки, хранимые процедуры, запросы, гуишные окна, справочники и прочая дб-центрик хрень. Часть из этих вещей по историческим причинам устарела.
Я вот думаю, сделать автоматический анализатор графа зависимостей между между всем этим, чтобы создать список, "чего нахрен удалить" или по старинке, руками и только то, что нужно на текущий момент.
А то очень уж близко к зоопарку с яками изготовление анализатора зависимостей, хоть он и займет день-два в разработке.

Comments

[7ocb.livejournal.com]

Я вот тут недавно столкнулся с проектом, на котором я работал пару лет назад, потом его отдали американским корейце-индусам (корцедусами их, что-ли, называть). И через пару лет я снова оказался на этом проекте. Американские товарищи очень любят писать и копипасту. Но удалять код и убирать за собой не любят совершенно.

Поэтому проект чуть более чем наполовину (!!!!) состоял из кода, который не используется. Но в силу специфики проекта и корцедусов, код который не используется, все еще остается вызываемым. Например в ветках if'ов, которые никогда не выполнятся и т.п.

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

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

Ей богу, руками, grep'ом и крепким словом я разгреб это барахло куда раньше чем сваял бы внятную систему анализа зависимостей. (:

Конечно я разгреб еще не все, потому что там остались еще более запутанные куски, которые требуют глубокого анализа, но с такими кусками, очевидно, автоматика не справится еще больше.

[zamotivator.livejournal.com]

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

[7ocb.livejournal.com]

Я ни в коем случае не сомневаюсь в качестве кода автора.

Я скорее рассматриваю эти проблемы как впринципе свойственные ситуации "куча устаревшего и неиспользуемого кода".

[zamotivator.livejournal.com]

Не все кучи устаревшего неиспользуемого кода одинаково проблемны :)
В целом с вашим исходным посылом согласен - зачастую полуавтоматически будет проще, корректней и быстрее.

[7ocb.livejournal.com]

"Не все кучи устаревшего неиспользуемого кода одинаково проблемны :)"

Абсолютно согласен. Я всего лишь поделился своим опытом сражения с аналогичной проблемой. В конце концов, чем больше точек зрения можно обдумать, тем более взвешенное решение можно принять. (:

[zamotivator.livejournal.com]

Консенсус, отлично :)

[jdevelop.livejournal.com]

мы этого кода не видели, впрочем лично я ни одного кода ребе не видел

[zamotivator.livejournal.com]

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

[jdevelop.livejournal.com]

"по идее" может быть все что угодно

[zamotivator.livejournal.com]

/me разводит руками

[http://users.livejournal.com/zubr_/]

Выгребать и удалять можно только при наличии юнит-тестов. Почему-то везунчики, у которых среда разработки умеет юнит тесты, даже не вспоминают про них.

[7ocb.livejournal.com]

Наличию юнит-тестов необходимо в случае если речь идет о том, чтобы вычищать код который очень тесно переплетается с реально работающим.

В случае если код используется только в ветке if которая никогда не отработает и это можно легко доказать простым анализом кода, то такая чистка достаточно безопасна. Но бесспорно, если есть юнит-тесты оно то завсегда лучше.

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

[jakobz.livejournal.com]

Для таких БД оперденей часто неясно как писать тесты и что в них вообще проверять.

[metaclass.livejournal.com]

У меня как раз просто - "выбрать все пункты меню доступные пользователям и проверить что они не валятся с ошибками".
Там могут быть внутренние ошибки типа "неправильно посчиталось", но они ищутся другими методами, тут главное, чтобы не удалить что-нибудь из используемых запросов.

[jdevelop.livejournal.com]

юниттесты писать нельзя, это вам любой айсед расскажет