Унаследовал кошмар PHP, с чего начать?

Первое, что я бы сделал, - это настроил тестовую среду, используя какую-то виртуальную машину. VirtualBox или Virtual PC были бы хорошим выбором. Таким образом, вы можете начать что-то менять, не опасаясь нарушить производственную среду. Независимо от того, сколько работы это будет казаться (с базой данных, веб-сервером и всем остальным), в конце концов оно того стоит. Одно из больших преимуществ - вы можете скопировать виртуальную машину и передать ее кому-то другому, если вам потребуется помощь.

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

1. Настроить сервер разработки (как Грег Хьюгилл упомянул, VirtualBox и Виртуальный ПК - хороший выбор для это).

2. Поместите текущие файлы сайта (включая соответствующий веб-сервер и конфигурации PHP!) в управление версиями.

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

4. Молитесь ... много (хорошо, это не требуется, но похоже, что вы нужно это).

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

1. Прежде всего, загрузите файлы в контроль версий как есть. Не переходите к пункту 1, пока это не будет сделано.
2. Создайте среду тестирования.
3. Очистите файлы

Первым шагом, конечно же, было бы поставить его под контроль версий. Таким образом, по крайней мере, вы сможете вернуться к исходной рабочей версии. Во-вторых, было бы неплохо перезаписать функции include, require и т. д., Чтобы, например, записать имя файла, который включается в какой-либо файл журнала, таким образом вы можете узнать, какие файлы фактически включаются (таким образом, мы надеемся исключение большого количества index2.php, index3.php и т. д.

Чтобы при необходимости узнать, используются ли некоторые классы, а некоторые нет, вы можете использовать get_declared_classes в сочетании с get_defined_vars и gettype, чтобы увидеть, какие типы создаются.

Что касается проблем 4 и 5, их, вероятно, немного сложнее решить, но, надеюсь, вы должны начать с этого.

Я буду:

1. Сядьте и сделайте глубокий вдох;
2. Решите, действительно ли вы там хотите работать;
3. Предполагая, что да, тогда я бы закатал свои рукава, выбрал бы один беспорядок, над которым работал, и приступил бы к работе.

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

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

Среда разработки

Это будет включать в себя стек веб-сервера / скриптов / СУБД и, скорее всего, IDE.

Для Установщик стека ЛАМПА я рекомендую использовать один из них:

• http://www.apachefriends.org/en/xampp-windows.html
• http://www.easyphp.org/
• http://www.nucleex.com/nucserv/

Дальнейшее чтение по стеку LAMP:

Сайт O'Reilly's OnLamp

Для хорошего PHP IDE я рекомендую использовать один из них:

• Zend Studio
• ActiveState Komodo
• Jetbrains PhpStorm

Статья на сайте разработчиков IBM сравнение нескольких IDE

Для Управления источником вы можете использовать Team Foundation Server, SVN или Git - просто используйте то, что вы знаете. Я бы порекомендовал сначала получить все в системе контроля версий (для любого аварийного обслуживания, которое может у вас возникнуть), но затем планирую провести довольно большой капитальный ремонт.

Капитальный ремонт

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

• Клиенты / пользователи вашего приложения
• Тщательное и организованное ведение заметок
• Хорошая структура ведения журнала

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

Тщательное ведение заметок важно, потому что вы собираетесь переписывать все требования / дизайн / документацию для конечного пользователя с нуля. Вам нужно понимать внутреннее устройство, если вы собираетесь это делать. И если вы собираетесь что-то понимать в этой системе, вам нужно будет записать это самостоятельно (или вы бы сейчас просматривали готовую документацию, а не читали Stack Overflow) ;-)

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

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

Предотвратить это в будущем

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

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

Наладить процесс развертывания, если вы выращиваете более одного разработчика. Управление изменениями в производственной среде должно быть вашим первым приоритетом. (Последнее, что вам нужно сделать, это пройти через это снова, верно?) У вас должен быть ясный и простой процесс перехода между границами среды (например, Dev -> Test, затем Test -> Production).

Я думаю, что все 5 ваших пунктов касаются некоторых классических проектов ASP, которые я унаследовал, и PHP тоже ...

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

Убедитесь, что ваша база данных тоже версирована, особенно если в процедурах есть дополнительная логика (а не просто прямая вставка, обновление, удаление). Управление версиями БД требует большего внимания, чем страницы php. Вам необходимо сгенерировать все объекты для сценариев sql и поместить эти сценарии в систему управления версиями. Затем, когда вы меняете структуру базы данных, процедуры и т. д., Вам необходимо обновить скрипты, чтобы у вас также была история этих изменений.

Что касается определения того, что использует что на стороне базы данных, я бы посоветовал взглянуть на ApexSQL Clean. Я использовал это в проекте с несколькими сотнями файлов ASP, 200+ таблицами и около 400 хранимыми процедурами. Мне удалось идентифицировать около 20 неиспользуемых таблиц и около 25% хранимых процедур. С помощью ApexSQL Clean вы можете добавить все свои php-файлы в проверку зависимостей вместе с таблицами, представлениями и сохраненными процедурами. Возьмите 30-дневную пробную версию и проверьте ее, это сэкономит вам много времени.

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

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

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

После этого я бы начал с базы данных. Убедитесь, что все относительно хорошо нормализовано, столбцы четко названы и т. д.

Затем выполните код PHP. Если код действительно представляет собой лоскутное одеяло, я бы пошел дальше и приспособил его к фреймворку. Взгляните на CakePHP или Symfony - их Rails-подобный способ разделения проблем вызывает вопрос: «Куда должен идти этот фрагмент кода?» легко ответить. Это нелегкая задача, но как только вы ее сделаете, вы, вероятно, будете лучше, чем на полпути к созданию разумно сконструированного приложения. Кроме того, встроенные средства тестирования хорошего веб-фреймворка упрощают рефакторинг FAR - напишите тест, чтобы охватить существующую часть функциональности, прежде чем изменять ее, и вы узнаете, сломали ли вы что-нибудь после изменения.

После того, как вы отсортировали свою базу данных и получили код модели в моделях и код контроллера в контроллерах, вы можете беспокоиться о таких вещах уровня презентации, как стандартизация в одной библиотеке JS / AJAX, очистка CSS и т. д.

Что касается среды разработки: вы должны обязательно настроить локальную среду разработки. Существуют готовые пакеты WAMP, или вы можете установить их на Linux / виртуальную машину (я рекомендую VirtualBox для виртуализации). У вас также должна быть отдельная среда тестирования интеграции, которая имитирует работающий сервер. На реальном сервере не должно выполняться ничего, кроме живого кода.

Что касается инструментов отладки / профилирования, я знаю, что Symfony поставляется с довольно приятным набором инструментов, включая небольшую панель инструментов JS, которая появляется на ваших страницах (только в режиме отладки) с информацией для ведения журнала и профилирования.

Удачи.

Делай то, что сказал Харпер Шелби ...

Но я бы также добавил, что если у вас нет поддержки со стороны руководства, чтобы это исправить, вы можете принять тот факт, что это может быть так по какой-то причине. ... просто говорю. ;-)

Вот несколько идей:

• PHP и Apache отлично работают и в Windows. Может быть, вы все-таки сможете выполнить установку для всей Windows?
• Попробуйте использовать grep (или какую-нибудь альтернативу для Windows) для "include" и "require" во всех файлах PHP. Затем составьте список всех найденных включенных файлов. Сравните список с файлами в папке. Вы сможете избавиться как минимум от НЕКОТОРЫХ файлов, на которые нет ссылок.
• Или же составьте список всех имен файлов и найдите их во всех файлах. Вы можете сделать что-то вроде этого графа зависимости.

Это действительно беспорядок. Но начните изобретать, где отрезать несколько щупалец на этой штуке:

1. Получите контроль версий. Я рекомендую Git.
2. Настройте локальный сервер разработки. Найдите пакет WAMP, LAMP или MAMP, чтобы начать работу, так как вы новичок в этом.
3. Найдите точки входа (index.php и т. д.). Проверьте журналы доступа к серверу, чтобы узнать, что это такое.
4. Засучите рукава черной магии регулярных выражений и создайте дерево включения / требования для всех файлов. Но остерегайтесь любых динамических включений include ($ filename). Если у вас есть какой-либо из них, вам нужно будет выполнить регистрацию в $ filename, чтобы узнать, что, возможно, будет включено, хотя код вокруг него должен дать вам подсказки. Если повезет, вы сможете таким образом удалить все неиспользуемые файлы.
5. Используйте больше черной магии регулярных выражений, чтобы проверить, есть ли ссылки на функции и методы в другом месте базы кода. Может быть IDE, которая может вам в этом помочь. Попробуйте NetBeans (я однажды использовал его для рефакторинга проекта C++, так что здесь он может помочь).
6. Как ответил кто-то другой, «при необходимости узнайте, используются ли некоторые классы, а некоторые нет, вы можете использовать get_declared_classes вместе с get_defined_vars и gettype, чтобы увидеть, какие типы создаются». Вы также можете просто написать код, чтобы найти все новые операторы в базе кода.
7. И так далее ... только подумайте, как вы можете вырезать этого монстра. И попробуйте реорганизовать код там, где это возможно.

Вы можете подумать об установке расширения 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 в производстве. Вероятно, вам удастся обойтись более скромной (хотя и совместимой) аппаратной платформой.

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

Вот что мне больше всего помогло:

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

• узнать, как обрабатываются пользователи системы (сеансы, файлы cookie). Создайте суперпользователя, а затем, когда вам нужно протестировать свой код в реальном времени в системе, поместите его в такой блок:

  if ($_POST['your_registered_user_name']{
     //Your live code being tested, which will be visible only to you when you are logged in
  }
  

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

• напишите тест и следуйте строгим инженерным рекомендациям для всего кода, который вы пишете

В большинстве случаев вы можете определить, используется ли файл, с помощью 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";
        }
    }
}

1. Сделайте резервную копию кода сейчас.

2. Управление версиями.

3. Создайте тестовый сайт. Сайт работает под Apache? Вы даже можете установить Apache + PHP + MySQL на свой компьютер и использовать его для тестирования.

4. Решайте вопросы безопасности. Убедитесь, что сайт защищен от SQL-инъекций и электронной почты. По крайней мере, вы можете выполнить поиск вызовов базы данных и добавить вызовы к mysql_real_escape_string() (ну, если он использует базу данных MySQL) ... вы можете сделать реальное исправление позже, когда лучше поймете код. Для внедрения электронной почты ... напишите функцию фильтра, которая отфильтровывает код спамера, и убедитесь, что все поля формы, которые используются в электронном письме, отфильтрованы. (Да, он добавляет больше кода спагетти, но это займет некоторое время, прежде чем вы будете готовы к значительному рефакторингу кода.)

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

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

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

1. Я вошел в систему как пользователь,
2. и проработал каждый экран и все варианты использования, которые смог найти.
3. Я сохранил HTML в статических файлах,
4. и сделал заметки о процедурных операциях и очевидных бизнес-правилах.

Я делал это в течение 3 дней, а затем сделал заметки и долго беседовал с заинтересованными сторонами.

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

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

Это оказалось концом тяжелой работы (а также концом предполагаемого риска проекта для заинтересованных сторон).

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

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

Подумайте о том, чтобы переписать и использовать старый сайт в качестве спецификации функции.

Удивительно, но, насколько я понимаю, никто даже не упомянул это сделал, но есть другая альтернатива: откажитесь от кода и просто используйте функциональность самого сайта как новую спецификацию набора функций (то есть первая в этом проекте), а затем перестроить сайт, основываясь на этих функциях, с установленной структурой. (например, Symfony, Laravel или Drupal).

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

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

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

Если вы прочитаете Статья Джоэла о том, почему делать переписывание - это плохо, вы не заметите, что почти ни одно из обстоятельств, которые он цитирует, не применимы к вам здесь.

Множество полезных сообщений о том, как с этим бороться.

Не пытаясь повторить то, что сказали все:

1. Получите копию работающей среды prod. Это может быть виртуальная машина или другая реальная машина. Но для этого нужно быть Богом. Если база данных prod находится в другом ящике, вам также понадобится версия для разработчиков.
2. Бросьте все это в систему контроля версий. На другой коробке. Тот, который создается как минимум еженедельно.
3. Убедитесь, что вы знаете, как работает ветвление в вашем приложении для управления версиями. Вероятно, вам это понадобится.
4. Заблокируйте прод-сервер. Вы не хотите, чтобы в него вносились дальнейшие изменения, которые не выходят из-под контроля версий.
5. Создайте инструкции по передаче кода из системы контроля версий на прод-сервер. Наименьшей единицей допустимых изменений должна быть вся кодовая база.

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

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

Теперь вам нужно начать перенос функций в ваши новые включаемые файлы. Вам понадобится способ одновременно открывать несколько файлов, например, многофайловый редактор или screen + vi (или emacs). Начните с служебных функций и блоков кода, которые повторяются в разных местах. Старайтесь не отвлекаться на то, чтобы сразу многое исправить. Некоторые типы проблем нужно будет просто переместить, пока другие проблемы будут исправлены. Вы к ним вернетесь позже.

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

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

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

Я просто сам проходил через это.

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

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

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

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

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

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

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

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

Представьте его своему боссу лично. Назначьте время, чтобы обсудить это.

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

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

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

Что касается тестирования, настройте еще один «виртуальный хост» в Apache (поддерживается как в Windows, так и в Linux). Виртуальные хосты позволяют запускать несколько сайтов на одном сервере. Большинство крупных сайтов имеют как минимум 3 виртуальных хоста (или реальных сервера): dev.domain.com (для ежедневной разработки), staging.domain.com (для QA-специалистов, которые проводят тестирование непосредственно перед выпуском) и www.domain. com (ваш производственный сервер). Вам также следует настроить версию базы данных для разработчиков, промежуточную и производственную версии с разными логинами и паролями, чтобы случайно не перепутать их.

Альтернативным решением было бы предоставить каждому разработчику свой собственный виртуальный хост на сервере Linux, и они могли бы работать через FTP / SCP или общий сетевой ресурс, используя самбу.

Удачи!

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

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

Это не полное решение, но если в каждом каталоге есть 10 файлов index.php (например, index.php, index2.php и т. д.), По крайней мере, вы будете знать, какой из них используется вашим приложением.

Вы можете увидеть список всех включенных / требуемых файлов, поместив его внизу страницы:

<?php var_dump(get_included_files()); ?>

Да, контроль версий - это определенно шаг №0.

Я также рекомендовал бы хороший Инструмент поиска кода.

Агент Рэнсак довольно хорош (при условии, что вы работаете в Windows) http://www.mythicsoft.com/agentransack/Page.aspx?page=download

Я бы летал вслепую без поиска кода.

1. Получите это под контролем версий.

2. Определитесь с соглашениями об именах и структурой файлов / каталогов.

3. Убедитесь, что у вас есть достойные инструменты / IDE.

4. Настройте отдельную среду разработки / тестирования, если вы еще этого не сделали

ТОГДА ...

5. К сожалению, вам придется просмотреть все эти 1, 2, 3 файла и определить, какие из них используются, а от каких можно избавиться. Нет другого пути, кроме грубой силы, файл за файлом.

6. Несмотря на то, что у меня есть RCS, я все равно часто перемещаю то, что я считаю неиспользуемыми скриптами, в скрытое место, например .mausoleum, а затем заставляю RCS игнорировать это место. Приятно иметь возможность взглянуть на место, не возвращаясь к репо.

7. Максимально разделяйте HTML и PHP. Я не могу подчеркнуть это достаточно! Если это сделано в каждом файле, хорошо. Просто до тех пор, пока у вас есть отдельные фрагменты PHP и HTML. Конечно, HTML будет изобиловать эхом здесь и там, но постарайтесь, чтобы все тесты, переключатели и все остальное переместились из блока HTML в блок PHP. Одно только это может быть ОГРОМНЫЙ, когда дело доходит до выяснения отношений.

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

9. Как только вы найдете файлы / сценарии, которые можно логически объединить, сделайте это. (Я видел проекты - вероятно, похожие на ваш - где общее количество сохранившихся файлов составляет примерно 1/4 от того, с чего мы начали).

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

Хороший шанс!

1. начать использовать контроль версий в проекте (рекомендую git)
2. писать модульные тесты для всего кода
3. начать использовать ORM (я настоятельно рекомендую доктрину)
4. начать использовать какой-нибудь фреймворк (я рекомендую symfony / nette)
5. начать рефакторинг php кода