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

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

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

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

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

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

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

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

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

Удачи.

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

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

Это будет включать в себя механизм Webserver / script engine / database engine и, скорее всего, IDE.

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

• 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 then 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"; } } } 

1. Настройте сервер разработки (как отметил Грег Хьюглил, VirtualBox и Virtual PC – хороший выбор для этого).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я бы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Получите его под контролем ревизии.

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

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

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

ТОГДА …

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

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

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

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

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

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

Шанс Бонны!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

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

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

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

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

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

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

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

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

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

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

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