Обнаружение зависимостей интерфейса - PullRequest
4 голосов
/ 28 января 2009

Я взял на себя обслуживание очень большого (> 2M SLOC) программного проекта, все написанного на C #. Существует очень мало документации. Теперь я хочу внести изменения в модуль с открытыми интерфейсами (около 400), но я не знаю, какие все другие модули (всего их около 50) в решении могут использовать этот открытый интерфейс.

Как бы вы создали дерево использования зависимостей интерфейса для такой ситуации? База кода слишком велика, чтобы просто перемещаться по Project Explorer и читать исходный код. Какие инструменты или методы вы использовали для создания этого типа дерева анализа зависимостей?

Я не хочу покупать какие-либо инструменты. Инструменты Visual Studio, такие как Class View, не очень хорошо справляются с проектом такого размера. Я думал о написании своего собственного сценария sed / awk / perl-ish, который просто просматривает исходный код и использует сопоставление с образцом для создания моей собственной базы данных использования зависимостей / интерфейсов, но я не хочу делать что-то сложное, если легкий путь.

Спасибо!

Ответы [ 6 ]

3 голосов
/ 28 января 2009

Вы, вероятно, должны купить что-то вроде NDepend .

Если бы существовал еще один БЕСПЛАТНЫЙ инструмент, обеспечивающий аналогичную ценность, я бы порекомендовал его. Однако я искренне верю, что NDepend - ваш лучший выбор. Имея кодовую базу такого размера, инструмент за 400 долларов не займет много времени, чтобы окупить себя.

2 голосов
/ 29 января 2009

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

У парня, с которым работал, была эта проблема - его менеджер не платил за профилировщик, и поэтому они потратили 5 дней на разработку для оптимизации не тех частей программы. Используя профилировщик, он нашел и исправил проблему в течение полдня.

1 голос
/ 29 января 2009

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

.NET предлагает вам все необходимое для загрузки сборки и запроса всех интерфейсов, типов, методов и свойств в пространстве имен System.Reflection. Таким образом, вам не нужно беспокоиться о парсинге исходного кода самостоятельно, используя sed / awk / perl (что нетривиально, так как вам нужно разрешить пространства имен и наследование).

(Примечание: то, что вы не получили бы напрямую, используя отражение, это зависимости сборок от динамически загружаемых сборок, загружаемых, например, с помощью Assembly.Load. Вы должны будете реализовать специальную обработку, если это используется в вашем проекте)

1 голос
/ 29 января 2009

Простое решение для прямых зависимостей, щелкните правой кнопкой мыши интерфейс и выберите «Найти все ссылки». Вы также можете сделать это для каждого метода.

Чтобы узнать, сколько кода сломается в результате изменения, вы можете добавить [Устаревший (true, "Проверка изменения")] к методам интерфейса, который вы планируете изменить и вызвать восстановление. Это приведет к тому, что некоторые части не будут строиться. Перейдите к этим частям и пометьте их [Устаревшее (ложное, «Ограниченное изменение»)]], если вы чувствуете, что это небольшое изменение в этом классе и что вы можете исправить это без какого-либо влияния на потребителей этого класса, если вы считаете, что вместо этого будет вызывать серьезные проблемы у потребителей класса, вы можете пометить его как [устаревший (true, "каскад")] и иметь дело с его выпадением.

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

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

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

Сделайте все это в свежем обновлении исходного кода, чтобы вы могли просто откатить детали, если хотите повторить попытку.

1 голос
/ 28 января 2009

Я знаю, что вы сказали, что не хотите покупать инструмент, но CodeRush доступен в полном объеме и бесплатно в течение месяца (и только после 250 долларов, и вы получите рефактор-профессионал!, Что здорово). Он заменяет Shift + F12 на действительно изящное окно поиска всех ссылок.

0 голосов
/ 28 января 2009

Я не знаю, как настроен ваш проект, но здесь у каждого модуля есть номер версии. Когда нам нужно внести изменения в модуль, мы создаем новую версию. Код клиента, который хочет использовать новый интерфейс, ссылается на обновленный модуль и удаляет ссылку на старый проект. В разных версиях нет непреднамеренных побочных эффектов от изменения API; код клиента должен явно что-то делать.

Кроме того, у нас есть утилита, которая (каким-то образом) сканирует все проекты и сообщает, если какой-либо из них использует модуль, который не является последней версией. Довольно легко проверить (даже с Microsoft VSS!), Какие проекты имеют ссылки на устаревшие модули.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...