Подтвердить что ты не робот

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

Я унаследовал проект PHP, который оказался кошмаром. Вот основные моменты:

  • Все оригинальные разработчики оставили
  • Код не имеет контроля версий
  • Все разработки и тестирование выполнялись на реальном сервере путем переименования и редактирования файлов PHP. Существует несколько копий каждого файла index.php, index2.php, index3.php и т.д., И неясно, какие файлы действительно используются
  • В каждый файл входят несколько файлов, в которые входят другие файлы, которые включают другие файлы и т.д.
  • В проекте было несколько разработчиков, каждый из которых имел собственный способ делать что-то. Например, существует мешанина фреймворков JavaScript, некоторые запросы к базе данных используют SQL, другие - интерфейс XML, а другие вызывают процедурные функции в базе данных.

Из-за всех этих проблем развитие расстраивает медленно. Помимо того, что я разочаровываюсь в Stack Overflow, любые рекомендации о том, как начать работу с этим беспорядком? Я довольно недавно занимаюсь разработкой PHP, но похоже, что создание какой-то среды разработки, чтобы изменения можно было протестировать, не нарушая работу сервера, это первый шаг. Любые советы о том, как начать работу здесь? Каков типичный способ проведения тестирования? Настройка локальной версии сайта на моем рабочем столе кажется большой работой (сервер Linux, но настольные компьютеры - это Windows). Могу ли я создать поддиректорию на реальном сервере для тестирования или...? Как насчет базы данных?

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

Хорошо, я перестану дышать здесь и броситься на милость всех здесь.:)

4b9b3361

Ответ 1

  • Прежде всего, получите файлы в версия управление как есть. Не переходите к # 1 до тех пор, пока это не будет выполнено.
  • Установите тестовую среду.
  • Очистка файлов

Ответ 2

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

Шаг Zero - это получить контроль над версиями, как бы он ни был дрянным. Если это даже работает, и вы что-то сломаете, вам нужно вернуться в рабочее состояние - или, по крайней мере, сравнить свои изменения с ним, чтобы выяснить, что пошло не так. Выполняйте частые, мелкие проверки при повторном рефакторинге, и у вас будет меньше кода для отката, когда все таинственно пойдет не так. (Вещи ТАК ТАК ТАК ТАК ТАК ТАКОЕ НЕИСПРАВНОСТИ.)

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

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

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

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

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

Удачи.

Ответ 3

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

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

Это будет включать в себя веб-сервер/ script блок ядра двигателя/базы данных и наиболее вероятно IDE.

Для LAMP установщик стека, я рекомендую использовать один из них:

Дальнейшее чтение в стеке LAMP:

O'Reilly OnLamp сайт

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

Статья на сайте IBM Developer, сравнивающая несколько IDE

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 4

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

grep -r "index2.php" *

Вы также можете использовать парсер PHP, который поможет вам очистить. Вот пример script, который печатает функции, объявленные и вызовы функций:

#!/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";
        }
    }
}

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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

  • Составьте план, основанный на предложениях по этой теме.
  • Опишите любое новое оборудование или программное обеспечение, необходимое для создания среды разработки и тестирования, и оцените их.
  • Выясните, какие новые навыки вам необходимо обучить, чтобы настроить и использовать среду разработки и тестирования. Оцените время и затраты, необходимые для получения этих навыков. Например. книги или оплачиваемое обучение.
  • Оцените рабочий график, чтобы выполнить очистку. Как долго получить код под контролем источника? Как долго понимать базу данных? Как долго понимать код PHP и javascript?
  • Представьте это своему менеджеру и сформулируйте цель с точки зрения выгоды для его нижней линии. Например. когда все будет очищено, внесение изменений или развертывание новых функций будет быстрее, ошибки отладки будут более предсказуемыми, а наращивание новых сотрудников будет проще.

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

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

У меня есть несколько конкретных предложений о том, как действовать:

  • В дополнение ко всем другим замечательным советам я бы предложил использовать Joel Test в качестве эталона. Ваш план по очистке должен привести к созданию рабочей среды, которая хорошо оценила бы тест Joel.
  • Прочтите мой ответ на Каковы наилучшие способы понять незнакомую базу данных?
  • Включить ведение журнала на веб-сайте, чтобы вы могли анализировать, какие страницы PHP на самом деле вызываются. По крайней мере, это говорит вам, какие из индексов index.php, index3.php, index4.php и т.д. Действительно устарели.
  • PHP имеет функцию get_included_files(), которая возвращает массив всех файлов, включенных во время текущего запроса. Регистрируя эту информацию, вы можете узнать, какие файлы PHP используются, даже если они не отображаются в журнале веб-сервера.
  • Вам действительно нужно иметь среду тестирования и разработки, соответствующую вашему производственному серверу. Не стоит тестировать Windows и развертывать в Linux. Не стоит использовать MySQL 5.0 во время разработки и MySQL 4.0 в производстве. Вы, вероятно, можете уйти с аппаратной платформой, которая является более скромной (хотя и совместимой).

Ответ 9

Я бы:

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

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

Ответ 10

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

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

Ответ 11

Рассмотрим переписывание и использование старого сайта в качестве спецификации функции

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

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

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

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

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

Ответ 12

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

Ответ 13

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

Ответ 14

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

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

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

Ответ 15

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

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

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

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

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

Ответ 16

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

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

Ответ 17

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

  • Получить контроль версий. Я рекомендую Git.
  • Настройте локальный сервер разработки. Найдите пакет WAMP, LAMP или MAMP, чтобы начать работу с тех пор, как вы новичок в этом.
  • Найдите точки входа (index.php и т.д.). Проверьте журналы доступа к серверу, чтобы узнать, что это такое.
  • Сверните свои рукава на черном манере обычного выражения и выгрузите дерево include/require на все файлы. Но будьте осторожны с включенными динамиками include ($ filename). Если у вас есть какие-либо из них, вам нужно сделать некоторые записи в $filename, чтобы узнать, что может быть включено, хотя код вокруг него должен дать вам подсказки. С небольшой удачей вы можете отбросить все неиспользуемые файлы таким образом.
  • Используйте больше черной магии regex для проверки функций и методов, на которые ссылаются в другом месте в кодовой базе. Там может быть IDE, которая может помочь вам в этом. Попробуйте NetBeans (я использовал его, чтобы помочь мне реорганизовать проект С++ один раз, поэтому он может помочь здесь.)
  • Как сказал кто-то другой: "узнайте, если необходимо, если используются некоторые классы, а некоторые нет, вы можете использовать get_declared_classes вместе с get_defined_vars и gettype, чтобы увидеть, какие типы создаются". Вы также можете просто написать код для поиска всех новых операторов в базе кода.
  • И так далее... просто подумайте о том, как вы можете уничтожить этого монстра. И попробуйте реорганизовать код, где вы можете.

Ответ 18

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

Вот что мне помогло:

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

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

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

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

Ответ 19

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

  • Контроль версий.

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

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

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

Ответ 20

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

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

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

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

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

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

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

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

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

Ответ 21

  • Получить его под контролем версий.

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

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

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

THEN...

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

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

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

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

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

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

Шанс Бонны!

Ответ 22

Я просто прошел через это сам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

Ответ 23

Да, Version Control определенно шаг # 0.

Я также рекомендую хороший инструмент поиска кода.

Агент Ransack довольно хорош (если вы на окнах) http://www.mythicsoft.com/agentransack/Page.aspx?page=download

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

Ответ 24

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

Ответ 25

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

Ответ 26

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

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

Ответ 27

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

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

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