Поиск неиспользуемого кода в приложении Rails

Ответ 1

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

Просто для ясности сначала: Не доверяйте автоматическим инструментам. Они будут показывать только результаты для вещей, которые вы активно тестируете, не более того.

С выражением об отказе от ответственности я предлагаю использовать инструмент покрытия кода (например rcov или simplecov для Ruby 1.9) в вашем производственном приложении и измерьте пути кода, которые фактически используются вашими пользователями. Хотя эти инструменты были первоначально разработаны для измерения охвата тестирования, вы также можете использовать их для покрытия продукции

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

Другим подходом, который можно было бы объединить с вышеизложенным, является попытка реорганизовать ваше приложение на отличительные функции, которые вы можете включить и выключить. Затем вы можете отключить функции, которые, как предполагается, не используются, и проверить, не жалуются ли никто:)

И как последнее замечание: вы не найдете волшебный инструмент для полного анализа. Это потому, что ни один инструмент не может узнать, используется ли определенный кусок кода фактическими пользователями или нет. Единственное, что могут сделать инструменты, это создать (более или менее) статические диаграммы достижимости, сообщая вам, как ваш код каким-то образом вызывается из определенной точки. С динамическим языком, таким как Ruby, даже этого довольно сложно достичь, поскольку статический анализ не дает большого понимания перед метапрограммами или динамическими вызовами, которые широко используются в контексте рельсов. Поэтому некоторые инструменты фактически запускают ваш код или пытаются получить представление о тестировании. Но нет волшебного заклинания.

Таким образом, учитывая высокую внутреннюю (в основном скрытую) сложность приложения rails, вы не сможете выполнить большую часть анализа вручную. Лучшим советом, вероятно, было бы попытаться модулизировать ваше приложение и отключить некоторые модули, чтобы проверить, что они не используются. Это может быть подтверждено надлежащими интеграционными тестами.

Ответ 2

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

Здесь он находится в github: https://github.com/railsbp/rails_best_practices.

Поместите 'gem "rails_best_practices" ' в свой Gemfile, а затем запустите rails_best_practices . для создания файла конфигурации

Ответ 3

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

Dec 18 03:10:41 ip-xx-xx-xx-xx appname-p[7776]:   Processing by MyController#show as HTML

Итак, я создал простой script для анализа этой информации

zfgrep Processing production.log*.gz |awk '{print $8}' > ~/tmp/action

sort  ~/tmp/action | uniq -c |sort -g -r > ~/tmp/histogram

Что вызвало результаты того, как часто выполнялось задание контроллера #.

4394886 MyController#index
3237203 MyController#show
1644765 MyController#edit

Следующий шаг - сравнить его со списком всей пары действий контроллера # в приложении (используя выходные маршруты рейка или сделать тот же самый script для тестового набора)

Ответ 4

Оформить заказ coverband, он делает то, что вы точно ищете.

Ответ 5

Я не очень хорошо знаком с Ruby и RoR, но я бы предложил некоторые сумасшедшие предположения:

• добавить :after_filter метод, который записывает имя предыдущего вызываемого метода (возьмите его из стека вызовов) в файл
• Разверните это для производства
• Подождите некоторое время
• удалить все методы, которые не входят в журнал.

p.s. вероятно, решение с Alt + F7 в NetBeans или RubyMine намного лучше:)

Ответ 6

У вас уже есть идея отметить подозрительные методы как частные (что может сломать ваше приложение).

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

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

Ответ 7

Метапрограммирование

Объект # method_missing

переопределить Object#method_missing. Внутри запишите вызывающий класс и метод асинхронно в хранилище данных. Затем вручную вызовите исходный метод с соответствующими аргументами на основе аргументов, переданных в method_missing.

Дерево объектов

Затем сравните данные в хранилище данных с содержимым дерева объектов приложения.

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

Ответ 8

Попробовали ли вы создать тестовый набор, используя что-то вроде sahi, вы могли бы записать все ваши журналы пользователей, используя это, и связать эти тесты с rcov или что-то подобное.

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

Ответ 9

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

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

Ответ 10

Это не идеальное решение, но, например, в NetBeans вы можете найти способы использования этих методов, щелкнув их правой кнопкой мыши (или нажмите Alt + F7).
Поэтому, если метод не используется, вы увидите его.

Ответ 11

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