Инструменты для уборки мусора PHP - PullRequest
0 голосов
/ 10 марта 2009

Я только что унаследовал кодовую базу PHP длиной 70 тысяч строк, к которой теперь нужно добавить улучшения. Я видел хуже, по крайней мере, эта кодовая база использует архитектуру MVC и является объектно-ориентированной. Тем не менее, нет системы шаблонов, и многие классы устарели - вызывается только один раз. Я думаю, что мой метод может быть следующим:

  1. Найдите все файлы на работающем сервере, которые не были затронуты в течение 48 часов, и назначьте их кандидатами на удаление (к счастью, существует работающий сервер).
  2. Реализация системы шаблонов (Smarty) и попытка найти дубликат кода в шаблонах.
  3. Многие методы скопировали и вставили код ... Я не знаю, насколько сильно я хочу с ним связываться.

Мои вопросы: есть ли шаги, которые я должен предпринять, или вы бы предприняли? Какой у вас метод борьбы с этим? Существуют ли инструменты, помогающие найти повторяющийся код PHP?

Ответы [ 3 ]

5 голосов
/ 10 марта 2009

Найдите все файлы на живом сервере, которые не были затронуты в течение 48 часов, и назначьте их кандидатами на удаление (к счастью, есть живой сервер)

Под "прикосновением" я предполагаю, что вы проверите файл, чтобы увидеть, был ли он доступен какой-либо части системы. Я бы потратил на это полтора месяца, а не 48 часов. В старых базах PHP-кода вы часто обнаруживаете кучу кода, который вызывается через локальное задание cron раз в неделю или раз в месяц, или третье лицо регулярно вызывает его удаленно как псевдо-сервис. , Ожидая 6 недель, вы с большей вероятностью поймаете все вызываемые файлы.

Реализация системы шаблонов (Smarty) и попытка найти дубликат кода в шаблонах.

Почему? Серьезный вопрос, есть ли причина для внедрения системы шаблонов? (не разбирающиеся в PHP дизайнеры, разработчики, которые доставляют вам неприятности, добавляя слишком много логики в представления, или вы создаете шаблоны, и вы знаете, что в smarty вы работаете намного быстрее, чем в PHP). Если нет, то избегайте этого и просто используйте PHP.

Кроме того, насколько реально реализовать чистую систему шаблонов? Я бы дал благоприятные шансы, что в старых PHP-системах, подобных этой, будет масса «бизнес-логики», смешанной с их представлениями, которые не могут быть реализованы в чистом виде, и если вы разрешите смешанный PHP / Smarty, ваши разработчики будут использовать PHP каждый раз.

Многие методы скопировали и вставили код ... Я не знаю, насколько сильно я хочу с ним связываться.

Я не знаю ни одного инструмента для анализа кода, который бы делал это «из коробки», но можно было бы что-то сделать с помощью функций tokenizer .

Что вы должны действительно сделать

Я не хочу вас отговаривать или деморализовать, но почему вы хотите очистить этот код? Прямо сейчас он делает то, что должен делать. Тупо, но он делает это. Каждый ре-факторинговый проект подвергает риску текущие, недокументированные, возможно, критически важные для бизнеса функции, и в конце этой работы у вас появляется приложение, которое делает то же самое. Это 70 тысяч строк того, что звучит как дрянной код, который только вы заботитесь о том, чтобы исправить, не важно, что другие люди говорят вам о своих приоритетах. Если бы их приоритетом был чистый код, их код уже был бы чистым. Один человек не может изменить культуру. Если нет прямого бизнес-обоснования для очистки этого кода (открыть проект как бизнес-стратегию?), Этот устаревший код никуда не денется.

Вот другой набор приоритетов, которые следует учитывать в устаревших приложениях PHP

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

  2. Есть ли прямой способ для разработчиков избежать внедрения SQL-кода? Дайте им это для нового кода (параметризованный SQL) и рассмотрите возможность исправления устаревшего SQL для использования этого нового метода, а также рассмотрите меры безопасности, которые можно предпринять на уровне сети.

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

  4. Разработайте централизованную систему для значений конфигурации, большинство устаревшего кода PHP представляет собой ужасную комбинацию определений и констант классов, что означает, что любые изменения конфигурации означают толчок кода, что означает потенциальную DOOM.

  5. Разработать пух, который подключен к системе управления исходным кодом, чтобы обеспечить разумность кода для всего нового кода, а не только для стиля , но чтобы убедиться, что бизнес-логика остается вне поля зрения SQL создается безопасным способом, эти старые библиотеки копирования / вставки не используются и т. д.

  6. Разработайте разумную, отслеживаемую систему сборки и / или push и не позволяйте людям взломать код, работающий на производстве

3 голосов
/ 10 марта 2009

Я не знаю каких-либо конкретных инструментов, но я работал над рефакторингом некоторых довольно крупных проектов PHP.

Я бы порекомендовал систему шаблонов, либо Smarty, либо строгую систему PHP, которая четко объясняется всем, кто работает над проектом.

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

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

1 голос
/ 11 марта 2009

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

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

Не спешите с одноразовыми классами. Так работает множество небольших PHP-фреймворков. Часто они могут быть абстрагированы лучше, хотя. Кроме того, большая часть кода PHP также не понимает абстракцию уровня данных, в результате чего код SQL засоряется через бизнес-логику или даже код отображения. Эта проблема часто связана с отсутствием специального обработчика базы данных, что является проблемой, если вам вдруг придется учить его репликации или кэшированию. Это та же проблема абстракции с другого направления.

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

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