Унаследованный PHP-кошмар, с чего начать?
Я унаследовал проект PHP, который оказался кошмаром. Вот основные моменты:
- Все оригинальные разработчики оставили
- Код не имеет контроля версий
- Вся разработка и тестирование проводились на живом сервере путем переименования и редактирования файлов PHP. Существует несколько копий каждого файла index.php, index2.php, index3.php и т. Д., И неясно, какие файлы действительно используются
- В каждом файле есть несколько включений в файлы, которые включают другие файлы, которые включают другие файлы и т. Д.
- В проекте было несколько разработчиков, у каждого из которых был свой способ работы. Например, существует сборка JavaScript-фреймворков, некоторые запросы к базе данных используют SQL, другие - интерфейс XML, а другие вызывают процедурные функции в базе данных.
Из-за всех этих проблем развитие удручающе медленно. Кроме того, чтобы выразить свое разочарование по поводу переполнения стека, есть какие-либо рекомендации о том, как начать этот беспорядок? Я сам довольно новичок в разработке PHP, но похоже, что настройка какой-то среды разработки так, чтобы изменения могли быть протестированы без нарушения работоспособности сервера, является первым шагом. Любые советы о том, как начать здесь? Какой типичный способ сделать тестирование? Настройка локальной версии сайта на моем рабочем столе кажется большой работой (сервер - Linux, но рабочие столы здесь - Windows). Могу ли я создать подкаталог на живом сервере для тестирования или...? Как насчет базы данных?
Во-вторых, есть ли какое-либо профилирование, которое я могу включить, чтобы отслеживать, какие файлы на сервере фактически используются? Я хотел бы удалить переименованные копии вещей, которые на самом деле не включены. Более того, есть ли способ определить, какие части файла не выполняются? Есть много скопированных функций и мусора, которые, как я подозреваю, тоже не используются. Точно так же, для включений, какие-нибудь советы по исправлению беспорядка?
Ну, я перестану здесь извергаться и отдаться на милость всех присутствующих здесь.:)
27 ответов
- Прежде всего, получите файлы в системе управления версиями как есть. Не проходите мимо #1, пока это не будет сделано.
- Создать среду тестирования.
- Очистить файлы
Я сделал это Вы имеете мое сочувствие. Если ваш паспорт не действителен или по какой-то другой причине вы не можете избежать этого, вот как я могу подойти к нему:
Шаг ноль, чтобы получить его в управление версиями, независимо от того, насколько это дерьмо. Если это даже работает, и вы что-то ломаете, вам нужно вернуться в рабочее состояние или хотя бы сравнить свои изменения с ним, чтобы выяснить, что пошло не так. Делайте частые небольшие проверки во время рефакторинга, и у вас будет меньше кода для отката, когда что-то пойдет не так. (Все будет таинственно не так.)
После этого я бы начал с базы данных. Убедитесь, что все относительно хорошо нормализовано, столбцы имеют четкие имена и т. Д.
Сделайте следующий код PHP. Если код на самом деле такой же лоскутный, я бы пошел дальше и приспособил его к фреймворку. Посмотрите на CakePHP или Symfony - их Rails-ишский способ разделения проблем ставит вопрос "куда должен идти этот кусок кода?" легко ответить. Это не маленькая задача, но как только вы это сделаете, вы, вероятно, лучше, чем на полпути к разумно сконструированному приложению. Кроме того, встроенные средства тестирования хорошего веб-фреймворка упрощают рефакторинг FAR - напишите тест, чтобы охватить существующий фрагмент функциональности, прежде чем изменять его, и вы узнаете, сломали ли вы что-нибудь после изменения.
После того как ваша база данных отсортирована и код модели находится в моделях, а код контроллера - в контроллерах, вы можете беспокоиться о вещах уровня представления, таких как стандартизация в одной библиотеке JS/AJAX, очистка CSS и т. Д.
Что касается среды разработки: вы должны абсолютно настроить локальную среду разработки. Существуют готовые пакеты WAMP или вы можете установить их на Linux / box/VM (я рекомендую VirtualBox для виртуализации). У вас также должна быть отдельная среда тестирования интеграции, которая имитирует работающий сервер. Ничего, кроме живого кода, не должно выполняться на работающем сервере.
Что касается инструментов отладки / профилирования, я знаю, что Symfony поставляется с довольно гладким набором инструментов, включая небольшую панель инструментов JS, которая появляется на ваших страницах (только в режиме отладки) с информацией о регистрации и профилировании.
Удачи.
Ну обо всем по порядку. Я был в ситуации, в которой вы находитесь, и это отстой. Я думаю, что вы на правильном пути, желая получить среду разработки и запустить ее.
Среда разработки
Это будет включать в себя стек Webserver / механизма сценариев / ядра базы данных и, скорее всего, IDE.
Для установщика стека LAMP я рекомендую использовать один из них:
- http://www.apachefriends.org/en/xampp-windows.html
- http://www.easyphp.org/
- http://www.nucleex.com/nucserv/
Дальнейшее чтение стека LAMP:
Для хорошей PHP IDE я рекомендую использовать один из них:
Статья на сайте разработчика IBM, сравнивающая несколько IDE
Для управления исходным кодом вы можете использовать Team Foundation Server, SVN или Git - просто используйте то, что вам известно. Я бы порекомендовал сначала получить все в системе контроля версий (для любого аварийного технического обслуживания, которое у вас может быть), но затем планирую сделать довольно большой капитальный ремонт.
Капитальный ремонт
Вы упомянули, что даже не знали, какие файлы используются, и что они использовали соглашение об именах файлов в качестве псевдо-контроля версий. Возможно, вы захотите начать там капитальный ремонт, когда у вас будет запущена среда разработки. Есть несколько вещей, которые могут вам помочь:
- Клиенты / пользователи вашего приложения
- Тщательное и организованное ведение заметок
- Хороший каркас регистрации
Ваши клиенты / пользователи важны, потому что, похоже, вы новичок в проекте, и они узнают, как приложение должно вести себя лучше, чем вы (скорее всего).
Тщательное ведение заметок важно, потому что вы собираетесь переписывать любые требования / дизайн / документацию для конечного пользователя с нуля. Вы должны понимать внутренности, если вы собираетесь это сделать. И если вы хотите что-то понять об этой системе, вам нужно будет записать ее самостоятельно (или вы сейчас будете просматривать предварительно подготовленную документацию вместо чтения переполнения стека);-)
И, наконец, структура ведения журналов важна, потому что вам нужно что-то исправить, и вы не можете исправить вещи, которые вы не знаете, сломаны. Инфраструктура ведения журналов дает вам представление о тех частях приложения, которые не имеют очевидного пользовательского интерфейса. Вставив его в различные части приложения, а затем просматривая журналы, вы получите представление о том, когда выполняется код и в каком порядке.
Вы должны сосредоточиться на том, чтобы запечатлеть (на бумаге), как должно работать приложение, а затем медленно удалять ненужные файлы, стараясь ничего не сломать. Следите за журналами, чтобы помочь с отладкой. Убедитесь, что ваши клиенты не кричат, что что-то сломано. Убедитесь, что ваши заметки согласуются с тем, что регистрируется и что говорят ваши клиенты.
Предотвращение этого в будущем
Перепроверьте все обратно в систему контроля версий. Надеюсь, к этому моменту вы получите более новую, разумную, лучшую структуру каталогов.
Получите тестовую структуру на месте. Даже если это просто означает, что нужно создать базовую платформу для модульных тестов и выполнять некоторые базовые тесты дыма после каждого развертывания, это лучше, чем ничего. В идеале у вас должен быть инженер по тестированию или знающий и заслуживающий доверия клиент, который может проводить тестирование времени после каждого развертывания.
Внедрите процесс развертывания, если у вас больше одного разработчика. Контроль изменений в вашей производственной среде должен быть вашим первым приоритетом. (Последнее, что вы хотели бы сделать, это повторить это, верно?) У вас должен быть четкий и простой процесс перемещения между границами среды (например, Dev -> Test, затем Test -> Production).
Большую часть времени вы можете определить, используется ли файл с помощью grep.
grep -r "index2.php" *
Вы также можете использовать анализатор PHP, чтобы помочь вам очистить. Вот пример сценария, который распечатывает объявленные функции и вызовы функций:
#!/usr/bin/php
<?php
class Token {
public $type;
public $contents;
public function __construct($rawToken) {
if (is_array($rawToken)) {
$this->type = $rawToken[0];
$this->contents = $rawToken[1];
} else {
$this->type = -1;
$this->contents = $rawToken;
}
}
}
$file = $argv[1];
$code = file_get_contents($file);
$rawTokens = token_get_all($code);
$tokens = array();
foreach ($rawTokens as $rawToken) {
$tokens[] = new Token($rawToken);
}
function skipWhitespace(&$tokens, &$i) {
global $lineNo;
$i++;
$token = $tokens[$i];
while ($token->type == T_WHITESPACE) {
$lineNo += substr($token->contents, "\n");
$i++;
$token = $tokens[$i];
}
}
function nextToken(&$j) {
global $tokens, $i;
$j = $i;
do {
$j++;
$token = $tokens[$j];
} while ($token->type == T_WHITESPACE);
return $token;
}
for ($i = 0, $n = count($tokens); $i < $n; $i++) {
$token = $tokens[$i];
if ($token->type == T_FUNCTION) {
skipWhitespace($tokens, $i);
$functionName = $tokens[$i]->contents;
echo 'Function: ' . $functionName . "\n";
} elseif ($token->type == T_STRING) {
skipWhitespace($tokens, $i);
$nextToken = $tokens[$i];
if ($nextToken->contents == '(') {
echo 'Call: ' . $token->contents . "\n";
}
}
}
Настройте сервер разработки (как упомянул Грег Хьюгилл, VirtualBox и Virtual PC - хороший выбор для этого).
Поместите текущие файлы сайта (включая соответствующие веб-сервер и конфигурации PHP!) В систему контроля версий.
Выясните, какие файлы используются - используйте настройку сервера разработки для тестирования, удалив все файлы fooN.php и посмотрите, работает ли он по-прежнему.
Молитесь... много (хорошо, это не обязательно, но, похоже, вам это понадобится).
Если это наихудший случай, весь код сбит, а все отображение смешано с логикой и вызовами базы данных, вы можете сделать то, что я должен был сделать с одним проектом PHP.
Я дал ему три старта, попробовав подход рефакторинга. Это было похоже на восхождение на мотоцикле и прохождение 10% пути каждый раз. Поэтому я выбрал другой подход, который в итоге оказался намного лучше.
- Я вошел как пользователь,
- и работал через каждый экран и каждый вариант использования, который я мог найти.
- Я сохранил HTML в статические файлы,
- и принял к сведению процессуальные действия и очевидные деловые правила.
Я делал это в течение 3 дней, а затем сделал свои записи и долго беседовал с заинтересованными сторонами.
Получив согласие на некоторые первые шаги, я правильно реализовал весь HTML-интерфейс, используя хороший согласованный дизайн и абстракцию. После катания я мог делать пару экранов в день.
Затем я вернул результат заинтересованным сторонам и просмотрел множество вариантов использования. (Заинтересованные стороны были очень довольны шагами 1 и 2, потому что им все равно не понравилась первая реализация (удивление), и теперь похоже, что есть надежда на улучшение, а не просто восстановление sane-old-app.
Это оказалось концом тяжелой работы (а также концом предполагаемого риска проекта для заинтересованных сторон).
Оказалось, что первая команда настолько увязла в своих непосвященных спагетти, что в работе было сравнительно мало контента, поэтому дублирование имело меньше возможностей, чем все подозревали.
Но ключевое решение заключалось в том, что исходный код, как контент, так и структура, были нерефрактерны, и мне нужно было работать с полностью внешним видом с новой структурой, которая была должным образом разработана.
Одна вещь, которую вы могли бы рассмотреть, - это установить расширение PHP "xdebug" в среде разработки, настроить его на отслеживание всех вызовов функций, а затем максимально полно (возможно, посредством автоматического тестирования пользовательского интерфейса) выполнить все приложение. После этого вы сможете анализировать / анализировать файлы трассировки xdebug, чтобы найти все файлы / функции, используемые приложением.
У других людей в этой теме есть отличный совет. Я тоже был в этой ситуации. Вероятно, все когда-то в своей карьере участвовали в проекте, который, похоже, был поражен торнадо.
Одно из предложений, которое я хотел бы добавить, заключается в том, что перед тем, как выполнять какие-либо действия по очистке, описанные другими людьми, вам необходимо получить бай-ин от руководства.
- Составьте план на основе предложений по этой теме.
- Опишите любое новое аппаратное или программное обеспечение, необходимое для создания среды разработки и тестирования, и оцените его.
- Выясните, какие новые навыки вы должны пройти, чтобы настроить и использовать среду разработки и тестирования. Оцените время и затраты, необходимые для получения этих навыков. Например, книги или платное обучение.
- Оцените график работы для вас, чтобы сделать уборку. Как долго, чтобы получить код под контролем исходного кода? Как долго понимать базу данных? Как долго понимать код PHP и JavaScript?
- Представьте это своему менеджеру и сформулируйте цель с точки зрения выгоды для его практического результата. Например, после того, как все будет очищено, внесение изменений или развертывание новой функциональности будет происходить быстрее, ошибки отладки будут более предсказуемыми, а увеличение числа новых сотрудников будет проще.
Естественно, вам нужно продолжать работать с текущим беспорядком, потому что это живой сайт. Управление живым сайтом имеет приоритетное значение, поэтому работа по очистке должна быть фоновой задачей. Это означает, что это займет еще больше времени. Мой опыт очистки проекта среднего размера в качестве фоновой задачи обычно занимал от шести до двенадцати месяцев. Поскольку сайт будет продолжать развиваться в течение этого периода, некоторые из ваших завершенных задач по очистке могут потребовать пересмотра или повторного выполнения. Убедитесь, что ваш менеджер тоже все это понимает.
Если менеджер откажется от вашего плана по устранению этого беспорядка, или не ценит его, по крайней мере, тогда вы поймете, почему все другие разработчики покинули эту компанию!
У меня есть несколько конкретных предложений о том, как поступить:
- В дополнение ко всем другим замечательным советам, я бы предложил использовать тест Джоэля в качестве эталона. Ваш план по очистке должен привести к созданию рабочей среды, которая получила бы хорошие результаты в тесте Джоэла.
- Прочитайте мой ответ на " Как лучше всего понять незнакомую базу данных? "
- Включите ведение журнала на веб-сайте, чтобы вы могли проанализировать, какие страницы PHP фактически вызываются. По крайней мере, это говорит о том, какие из index2.php, index3.php, index4.php и т. Д. Действительно устарели.
- PHP имеет функцию
get_included_files()который возвращает массив всех файлов, включенных во время текущего запроса. Записав эту информацию, вы можете узнать, какие файлы PHP используются, даже если они не отображаются в журнале веб-сервера. - Вам действительно нужно иметь среду тестирования и разработки, соответствующую вашему производственному серверу. Нет смысла тестировать в Windows и развертывать в Linux. Нехорошо использовать MySQL 5.0 во время разработки и MySQL 4.0 в производстве. Вы, вероятно, можете избежать неприятностей с аппаратной платформой, которая более скромна (хотя и совместима).
Вы можете увидеть список всех включенных / обязательных файлов, поместив это в нижней части страницы:
<?php var_dump(get_included_files()); ?>
Я мог бы:
- Сядь и сделай глубокий вдох;
- Решите, действительно ли это то, где вы хотите работать;
- Если предположить, что да, тогда я сверну свои рукава, выберу один беспорядок за один раз и приступлю к работе.
Я знаю, что мы не можем ограничивать себя только одной задачей за раз; однако вы можете ограничить свою работу решением одного беспорядка за раз, работая над ежедневными задачами.
Рассмотрим переписать и использовать старый сайт в качестве спецификации функции
Удивительно, но никто даже не упомянул об этом, насколько я вижу, но есть другая альтернатива: отказаться от кода и просто использовать функциональность самого сайта в качестве новой спецификации набора функций (т. Е. Первой в истории для этого проекта), а затем пересоберите сайт, основываясь на этих функциях, с установленной структурой (такой как Symfony, Laravel или Drupal).
Да, есть те, кто съежился бы от злого переписывания слова... но бывают случаи, когда это действительно лучший путь, и вы намекаете на некоторые причины:
- вы довольно новичок в разработке PHP, сами
- вам, вероятно, будет лучше начать с чего-то чистого, а не с чистого кода, который вы унаследовали
- В конечном счете, большинство пользователей не обращают внимания на исходный код, и если он выглядит так, как будто он "работает", они могут смотреть на вас, как на сумасшедшего, если вы попытаетесь сказать им, что что-то ужасно неправильно
- вам будет веселее и вы дольше будете жить, если будете использовать методы контроля версий и проектирования баз данных в единой среде, которая выглядит так, как будто кто-то действительно заботился о том, чтобы его имя было прикреплено к нему.
Конечно, всем, кто занимал эту должность, раньше приходилось работать с таким кодом, но иногда этого достаточно, и лучше отказаться от спагетти и начать с новой тарелки.
Если вы прочитаете статью Джоэла о том, почему делать переписывание плохо, вы заметите, что почти ни одно из приведенных им обстоятельств не применимо к вам здесь.
Сделайте резервную копию кода сейчас.
Контроль версий.
Создать тестовый сайт. Работает ли сайт под Apache? Вы даже можете установить Apache+ PHP + MySQL на свой компьютер и использовать его для тестирования.
Разобраться с проблемами безопасности. Убедитесь, что сайт защищен от SQL-инъекций и электронной почты. По крайней мере, вы можете выполнить поиск в базе данных вызовов и добавить вызовы в
mysql_real_escape_string()(хорошо, если он использует базу данных MySQL)... вы можете сделать реальное исправление позже, когда вы лучше поймете код. Для внедрения электронной почты... напишите функцию фильтра, которая отфильтровывает спамерский код, и убедитесь, что все поля формы, используемые в электронной почте, отфильтрованы. (Да, он добавляет больше кода spagetti, но потребуется некоторое время, прежде чем вы будете готовы значительно реорганизовать код.)После этого я предлагаю дополнительные обновления. Вы новичок, а код - беспорядочный код, поэтому потребуется некоторое время, чтобы понять все это... и полностью понять предметную область. Так что просто займитесь своей работой немного, исправляя то, что нужно исправить, добавляя то, что нужно добавить. Делая это, вы изучаете, как система собрана. Как только вы узнаете, как код организован (или не организован) немного лучше, вы можете приступить к планированию масштабного рефакторинга / переписывания системы. Надеемся, что вы можете сделать это компонент за компонентом, так что у вас всегда будет новый рубеж в будущем.
Я знаю, что ты чувствуешь. Я унаследовал разработку такого проекта. Это оставалось со мной в течение года, и, честно говоря, это сделало меня разработчиком, которым я являюсь сегодня. Нет лучшей возможности для личного продвижения, чем работа по колено в дерьме.
Вот вещи, которые помогли мне больше всего:
- определить, какие ключевые файлы системы. Вы найдете их, потому что большая часть вашей работы будет выполнена в них
- создать локальную версию проекта (включая базу данных) и поставить ее под контроль версий
- работать только с небольшим количеством файлов с небольшими изменениями
- не помещайте ничего в рабочую версию, пока она не будет тщательно протестирована, а затем будьте готовы вернуть старую версию обратно
узнать, как обрабатываются пользователи системы (сеансы, куки). Создайте суперпользователя, а затем, когда вам нужно протестировать свой код в реальном времени в системе, поместите его в блок, подобный следующему:
if($_POST['your_registered_user_name']{ //Your live code being tested, which will be visible only to you when you are logged in }другие пользователи не смогут почувствовать изменения. Этот метод мне очень помог, когда я не смог заменить состояние системы на моей локальной машине
написать тест и следовать строгим техническим правилам для всего кода, который вы пишете
Вот несколько идей:
- PHP и Apache прекрасно работают и на Windows. Возможно, вы все-таки сможете выполнить установку полностью под Windows?
- Пытаться
grep'(или некоторые альтернативы Windows) для "включить" и "требовать" во всех файлах PHP. Затем составьте список всех найденных включенных файлов. Сравните список с файлами в папке. Вы должны быть в состоянии избавиться хотя бы от НЕКОТОРЫХ файлов, на которые нет ссылок. - Или составьте список всех имен файлов и найдите их во всех файлах. Вы можете сделать что-то вроде графика зависимости, как этот.
Много полезных постов о том, как с этим бороться.
Не пытаясь повторить то, что все остальные сказали:
- Получите копию запущенной среды prod. Это может быть виртуальная машина или другая реальная машина. Но ты должен быть Богом в этом. Если база данных prod находится в другом окне, вам также потребуется версия dev.
- Добавьте все это в контроль версий. На другой коробке. Тот, который поддерживается по крайней мере еженедельно.
- Убедитесь, что вы знаете, как работает ветвление в вашем приложении для контроля версий. Возможно, вам это понадобится.
- Получить Prod сервер заблокирован. Вам не нужны какие-либо дальнейшие изменения, которые не выходят из-под контроля версий.
- Создайте инструкции для освобождения кода от контроля версий на сервер prod. Наименьшей единицей высвобождаемого изменения должна быть вся база кода.
Следующие шаги зависят от того, насколько привязаны к нему пользователи. Если это не может быть изменено по многим причинам, вам понадобится прогрессивный подход. Если разработка и сопровождение все еще необходимы, то это, вероятно, ваш единственный вариант. Не забудьте использовать эту функцию ветвления, чтобы отделить такие моды от ваших усилий по переписыванию.
Чтобы внести смысл в структуру, вы должны в основном создать новую структуру наряду с тем, что там есть. Новый обработчик БД, как правило, является хорошим местом для запуска, включенным из универсального включаемого файла, который должна загружать каждая страница. Цель здесь состоит в том, чтобы создать минимальную структуру включения, которая может быть расширена позже без указания каждой страницы загружать дополнительные файлы.
Теперь вам нужно перейти к новым функциональным файлам. Вам понадобится способ открыть несколько файлов одновременно, например, многофайловый редактор или screen + vi (или emacs). Начните с полезных функций и кодовых блоков, которые повторяются в разных местах. Старайтесь не отвлекаться на исправление сразу. Некоторым типам проблем придется просто перемещать места, так как другие проблемы решаются. Вы вернетесь к ним позже.
Не думайте, что вам нужно добавлять сторонние фреймворки. Добавление такой вещи быстро приводит к полной перезаписи. На этом этапе это будет намного больше работы, чем просто укрощение его структуры включения. Так что разберитесь сначала.
По мере перемещения функциональности вам понадобится, чтобы файлы использовали новый включаемый файл. Первые несколько файлов, которые вы сделаете для вас, будут некоторое время преследовать конфликты. Это будет чувствовать разочарование и бессмысленность, но это, вероятно, самая сложная часть. После нескольких файлов это станет легче. Будут времена, когда вы сможете перенести полдюжины страниц в новые файлы включений, заменив дюжину включений одним. Обратная сторона этого действия - наличие файлов, которые вы можете просто удалить.
Если вы будете придерживаться этого, вы в конечном итоге дойдете до того момента, когда все включаемые файлы будут теми, что вы написали, и вы увидите весь макет включения. К этому моменту будет значительно проще делать гораздо более инвазивные изменения, например, вставлять сторонние фреймворки.
Вам определенно нужна среда разработки. Если вы не хотите возиться с запуском сайта на вашем компьютере с Windows, вы можете получить образ VMWare какого-то дистрибутива Linux.
Первое, что я хотел бы сделать, это настроить среду тестирования, используя какую-нибудь виртуальную машину. VirtualBox или Virtual PC будет хорошим выбором. Таким образом, вы можете начать менять вещи, не боясь нарушить производственную среду. Неважно, сколько работы это будет выглядеть (с базой данных, веб-сервером и всем остальным), в конце концов, оно того стоит. Одним из больших преимуществ является то, что вы можете скопировать виртуальную машину и передать ее кому-то другому, если вам понадобится помощь.
Это действительно беспорядок. Но начните изобретать, где отрезать некоторые щупальца на этой вещи:
- Получить контроль версий. Я рекомендую Git.
- Настройте локальный сервер разработки. Найдите пакет WAMP, LAMP или MAMP, чтобы начать работу, поскольку вы новичок в этом.
- Найдите точки входа (index.php и т. Д.). Проверьте журналы доступа к вашему серверу, чтобы увидеть, что это такое.
- Закатайте рукава на чёрной магии регулярного выражения и выкиньте дерево включений / запросов на все файлы. Но будьте осторожны с любым динамическим включением ( $filename). Если у вас есть что-то из этого, вам нужно будет зарегистрироваться в $ filename, чтобы выяснить, что может быть включено, хотя код вокруг должен дать вам подсказки. Если вам повезет, вы можете удалить все неиспользуемые файлы таким образом.
- Используйте больше регулярных выражений черной магии, чтобы проверить функции и методы, на которые ссылаются в других местах кодовой базы. Там может быть IDE, которая может помочь вам в этом. Попробуйте NetBeans (я использовал его, чтобы помочь мне реорганизовать проект C++ один раз, поэтому он может помочь здесь.)
- Как сказал кто-то другой: "узнайте, если необходимо, если некоторые классы используются, а некоторые нет, вы можете использовать get_declared_classes вместе с get_defined_vars и gettype, чтобы увидеть, какие типы создаются." Вы также можете просто написать код, чтобы найти все новые операторы в базе кода.
- И так далее... просто подумайте о том, как вы можете уничтожить этого монстра. И попробуйте реорганизовать код, где вы можете.
Первым шагом, конечно, было бы поставить его под контроль версий. Таким образом, по крайней мере, вы можете вернуться к исходной рабочей версии. Во-вторых, было бы неплохо переписать функции include, require и т.д., например, для записи имени файла файла, который включается в какой-либо файл журнала, таким образом, вы можете узнать, какие файлы фактически включены (таким образом, мы надеемся, исключение большого количества index2.php, index3.php и т. д.
Чтобы выяснить, если необходимо, если некоторые классы используются, а некоторые нет, вы можете использовать get_declared_classes вместе с get_defined_vars и gettype, чтобы увидеть, какие типы создаются.
Что касается вопросов 4 и 5, их, вероятно, решить немного сложнее, но, надеюсь, это поможет вам начать работу.
Получить его под контролем ревизии.
Определите соглашения об именах и структуру файлов / каталогов.
Убедитесь, что у вас есть достойные инструменты /IDE.
Настройте отдельную среду разработки / тестирования, если вы еще этого не сделали
ЗАТЕМ...
К сожалению, вам нужно просмотреть все эти 1, 2, 3 файла и определить, какие из них используются, а какие можно утилизировать. Нет другого способа, кроме грубого перемалывания, файл за файлом.
Несмотря на то, что у меня есть RCS, я все еще часто перемещаю то, что я считаю неиспользуемыми сценариями, в скрытое местоположение, например.mausoleum, и затем RCS игнорирует это местоположение. Приятно иметь возможность взглянуть локально, не возвращаясь к репо.
Разделите HTML и PHP в максимально возможной степени. Я не могу подчеркнуть это достаточно! Если это делается в каждом файле, хорошо. Пока у вас есть отдельные куски PHP и HTML. Конечно, HTML будет усеян эхом тут и там, но постарайтесь, чтобы все тесты, переключатели, все остальное было перенесено из блока HTML в блок PHP. Это само по себе может быть ОГРОМНЫ, когда дело доходит до выяснения вещей.
Если код в основном процедурный - я предполагаю, что в вашем случае это так - вероятно, лучше сначала выполнить некоторую очистку, прежде чем проводить какой-либо серьезный рефакторинг или рефакторинг в классы.
Когда вы найдете файлы / сценарии, которые могут быть логически объединены, сделайте это. (Я видел проекты - вероятно, не такие, как у вас - где общее количество выживших файлов составляет около 1/4 от того, с чего мы начали).
Как только вы зашли так далеко, вы можете начать правильный рефакторинг или рефакторинг в классы.
Боннский шанс!
Я думаю, что все 5 ваших очков затронули некоторые классические проекты ASP, которые я унаследовал, и PHP тоже...
Я полностью согласен с другими в том, чтобы получить его в системе контроля версий как можно скорее и использовать VMWare, VirtualBox и т. Д. Для тестовой среды.
Убедитесь, что ваша база данных тоже версионирована, особенно если в процедурах есть дополнительная логика (не просто прямая вставка, обновление, удаление). Управление версиями БД требует большего внимания, чем страницы php. Вам необходимо сгенерировать все объекты для сценариев sql и поместить эти сценарии в систему управления версиями. Затем, когда вы изменяете структуру, процедуры и т. Д., Вам необходимо обновить сценарии, чтобы у вас также была история этих изменений.
Что касается выяснения того, что использует то, что на стороне базы данных, я бы посоветовал взглянуть на ApexSQL Clean. Я использовал это в проекте с несколькими сотнями ASP-файлов, 200+ таблиц и около 400 хранимых процедур. Мне удалось идентифицировать около 20 таблиц, которые не использовались, и около 25% хранимых процедур. С ApexSQL Clean вы можете добавить все ваши php файлы в проверку зависимостей вместе с таблицами, представлениями и сохраненными процессами. Возьмите 30-дневную пробную версию и проверьте ее, она сэкономит вам много времени.
Для того, какие файлы использовались для веб-сайта, у меня были журналы веб-сервера за предыдущий месяц, и я провел поиск по ним всего, в чем я не был уверен. Мне также нравится вариант того, что Айстина предложила изменить файлы, чтобы они регистрировались при обращении к ним. Может быть, он перейдет к таблице в установленной вами базе данных, которая содержит имя файла и счетчик доступа, и при каждой загрузке файла увеличивает счетчик. Затем через некоторое время вы можете просмотреть счет и определить, что может пойти.
Я только что прошел через это сам.
Мой совет номер один - не пытаться изменить все в первый день. Тебе нужны друзья, если ты действительно хочешь исправить это. Вы должны уважать своих коллег, прежде чем предлагать, как изменить все, над чем они работали месяцами (годами?).
Во-первых, получите код под управлением версиями как можно скорее. Если это будет нелегко для вас, по крайней мере, начните делать ежедневные резервные копии, даже если это означает просто заархивировать файлы и назвать zip-файл с датой. Если никто не знает о контроле версий, купите книгу Pragmatic Programmer для CVS или SVN и настройте ее самостоятельно. Книги могут быть прочитаны за один день, и вы можете быстро приступить к работе. Если никто не хочет использовать контроль версий, вы можете использовать его самостоятельно... тогда, когда кто-то теряет файл, вы можете сохранить день с копией из вашего репо. Рано или поздно другие увидят мудрость контроля версий.
Во-вторых, погрузитесь в код так сильно, как только можете. Живи и вдыхай месяц. Покажите людям, которые там, что вы собираетесь изучать их код.
В-третьих, проходя код, делайте обильные заметки. Запишите все, что беспокоит вас о коде. Просто поделись своими мыслями на бумаге. Вы можете организовать это позже, после первого месяца.
В-четвертых, установите профилировщик кода (например, xdebug). Это скажет вам, какие файлы и функции вызываются на каждой странице, и сколько времени занимает выполнение каждого фрагмента кода. Вы можете использовать это, чтобы выяснить ваши проблемы с включением и найти медленные фрагменты кода. Оптимизируйте те сначала.
После месяца напряженной работы, разбирая код и делая заметки, превратите свои заметки в нужный документ. Различные разделы могут варьироваться от безопасности, кеширования, архитектуры, до всего, что вас беспокоит. Для каждой вашей критики предложите лучшее решение и подсчитайте, сколько времени потребуется, чтобы это исправить. Здесь вы избавляетесь от всех конкурирующих структур JavaScript и т. Д.
Пересмотрите этот документ в максимально возможной степени. Я не могу подчеркнуть это достаточно.
Убедитесь, что ваша аудитория может сказать, что вы делаете это для блага компании, а не только для своих личных предпочтений.
Подарите это своему боссу лично. Установите время, чтобы обсудить это.
Они могут уволить вас за то, что написали это. Если они это сделают, вам лучше без них, потому что они не хотят улучшаться, и ваша карьера будет стагнировать.
Возможно, они захотят выполнить все ваши рекомендации. Это маловероятно, но возможно. Тогда вы будете счастливы (если ваши рекомендации не будут выполнены).
Скорее всего, они захотят выполнить несколько ваших рекомендаций, и это лучше, чем ничего. По крайней мере, это поможет облегчить ваши проблемы.
Что касается тестирования, настройте другой "виртуальный хост" в Apache (поддерживается как в Windows, так и в Linux). Виртуальные хосты позволяют запускать несколько сайтов на одном сервере. Большинство крупных сайтов имеют по крайней мере 3 виртуальных хоста (или реальных сервера): dev.domain.com (для ежедневной разработки), staging.domain.com (для людей, которые проводят тестирование непосредственно перед выпуском), и www.domain.com (ваш производственный сервер). Вам также следует настроить dev, промежуточную и рабочую версии базы данных с разными логинами и паролями, чтобы случайно не перепутать их.
Альтернативным решением было бы предоставить каждому разработчику свой собственный виртуальный хост на сервере Linux, и они могли бы работать через FTP/SCP или через сетевой ресурс, используя samba.
Удачи!
Да, контроль версий определенно является шагом № 0.
Я также рекомендую хороший инструмент для поиска кода.
Агент Рэнсак довольно хорош (при условии, что вы в Windows) http://www.mythicsoft.com/agentransack/Page.aspx?page=download
Я бы летал вслепую без поиска кода.
- начать использовать контроль версий в проекте (я рекомендую git)
- написать модульные тесты для всего кода
- начать использовать ORM (я настоятельно рекомендую доктрину)
- начать использовать некоторые рамки (я рекомендую Symfony/ Nette)
- начать рефакторинг PHP-кода
В дополнение к замечательным вещам, о которых говорили другие люди, чтобы в первый раз узнать, какие файлы активно используются, вы можете установить кэш кода операции, такой как APC или eaccelerator, на свой сервер разработки (или даже на производственный сервер, это не сломается). что-нибудь). Затем щелкните по веб-приложению на своем сервере разработки (или разрешите пользователям делать это на вашем производственном сервере).
Теперь посмотрите на список кэшированных файлов на странице администратора вашего кэша. Если файл не указан как кэшируемый вашим кэшом кода операции, есть большая вероятность, что он ничего не загружает.
Это не полное решение, но если в каждом каталоге есть 10 файлов index.php (например, index.php, index2.php и т. Д.), По крайней мере, вы будете знать, какой из них используется вашим приложением.
Делай то, что сказал Харпер Шелби...
Но я также добавил бы, что если вы не получите поддержку со стороны руководства, чтобы очистить это, вы можете принять тот факт, что это может быть так по какой-то причине. ... просто говорю.;-)
Попробуйте получить подробную статистику на сайте и узнать, где находятся точки входа и выхода. Достойный способ узнать, какие файлы ударили сверху (а затем заглянуть в эти файлы, чтобы увидеть, какие из них удаляются).