Эффективное удаление больших кусков PHP - PullRequest
Новая
       12

Эффективное удаление больших кусков PHP

3 голосов
/ 02 марта 2010

Я только что унаследовал проект, и мне сказали, что из-за проблем с лицензированием необходимо удалить всю папку «include /». Мы не имеем права распространять файлы в этой папке, поэтому мы нужно сократить наши зависимости от них, и исправить все разрывы. Мне сказали: «Менее 5% строк в этой папке когда-либо даже вызывается нашей программой», но у меня нет возможности проверить это.

В папке около 50 файлов, каждый из которых содержит пару сотен строк кода. В настоящее время нет модульного тестирования. Есть один мастер-файл, include.php, который require()s всех 49 других файлов, поэтому я не могу просто выполнить grep для любого файла, выполняющего import() на includes/.*.

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

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

Ответы [ 5 ]

2 голосов
/ 02 марта 2010

Возможно, вы захотите найти «покрытие кода php». Это должно помочь вам понять, какой код используется. Например, похоже, что это может помочь:

http://www.xdebug.org/docs/code_coverage

0 голосов
/ 02 марта 2010

Чтобы ответить на мой собственный вопрос, я использовал профилировщик xdebug, чтобы выполнить эту работу, поскольку я сначала занимался расследованием (после того, как предложение друга подтолкнуло меня взглянуть еще раз).

В моем /etc/php5/apache2/conf.d/xdebug.ini (в Ubuntu 9.10) я установил xdebug.profiler_enable=1 и xdebug.profiler_output_dir=/var/log/xdebug/, затем загрузил получившиеся файлы cachegrind с помощью KCacheGrind и просто запустил поиск по именам файлов для "includes /".

Теперь у меня впереди куча работы по удалению всего этого, но по крайней мере у меня есть хороший обзор того, что я буду модифицировать!

0 голосов
/ 02 марта 2010

См. SD PHP Test Coverage Tool . Он предоставит визуальное представление о том, какой код на самом деле выполняется, а также отчет о том, какие части файлов используются (включая «без частей», что является вашей подсказкой, что код является вероятным кандидатом на удаление).

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

0 голосов
/ 02 марта 2010

Я бы начал с поиска файлов, ссылающихся на include.php. Проверьте через них, если они управляемы, один за другим. Затем я бы использовал grep для каждой функции в файлах / include / * php. Посмотри, где их называют, найди их, замени их.

Поскольку PHP динамически типизирован, я не думаю, что для этого найдется инструмент.

(С нетерпением жду, пока кто-нибудь докажет, что я неправ, потому что у меня все время одни и те же задачи ...)

0 голосов
/ 02 марта 2010

Ваш первоначальный подход совсем не плох. Это, конечно, разумное место для начала:

  1. удалить тот код, который не разрешен.
  2. попробуй запустить то, что осталось.
  3. если что-то сломается: создайте заглушку для метода, который сейчас отсутствует, и установите для него возврат некоторого разумного значения по умолчанию.
  4. Перейти к 2.

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

...