Должны ли мы переписать устаревшее приложение php в рамках?

Question

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

• Бэкэнд - около 14 000 мест. Интерфейс составляет около 3000 LOC.
• Каждый url - это php-скрипт, без использования классов.
• Каждый из этих сценариев php имеет связанный с ним шаблон smarty.
• Он использует плагины формирования формы PEAR.
• Frontend предлагается на двух языках. Это делается путем дублирования php-скриптов + шаблонов.
• Это не соответствует многим лучшим практикам, таким как экранирование всех параметров sql, перенаправление на запрос на отправку, установка скриптов php из веб-корня, защита XSS, защита CRSF.
• Приложение имеет двух основных разработчиков, я работаю над этим временно, чтобы помочь.
• Приложение используется несколькими клиентами. Каждый из них может иметь слегка измененную версию.

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

Я думал, что, может быть, начните с введения ORM, чтобы избавиться от SQL-инъекции и улучшить код спагетти для создания SQL-запросов.

EDIT 1:: Поскольку люди, похоже, много говорят о проблеме SCM. Я использую git, чтобы отслеживать свои локальные изменения. Я работаю над этим приложением временно, поэтому я не могу сказать другим разработчикам, какие инструменты использовать. Кроме того, это был не вопрос.

EDIT 2: Причина, по которой я рассматривал основы был) другой разработчик поднес б) было бы дать проекту более жесткую структуру, поэтому ошибки (например, ЧСФР) более легко избежать в будущее.

Answer 1

Я бы порекомендовал Symfony PHP Framework. Две недели кажутся слишком короткими, чтобы перенести ваше приложение, особенно если у вас еще нет навыков Symfony.

Zend Framework также является очень хорошей инфраструктурой PHP.

Answer 2

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

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

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

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

Answer 3

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

1. Если вы переписываете, лучше переписать его с нуля. Это переписывает это требование.
2. Когда вы переписываете, сохраняете старый сайт. Используйте ветвление в SCM. Если SCM не существует, начните использовать его сейчас и ответьте на него.
3. Если он работает безупречно (после многократного tesing), то он стоит переосмыслить о миграции.

Answer 4

Скажем, у вас было две недели, что бы вы сделали, чтобы исправить это заявление? (Это небезопасно и имеет код спагетти.)

Прежде всего, сделайте en ligne, для чего нужны исправления.

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

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

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

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

нет SCM

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

Я дал более длинный ответ на этот вопрос: How to implement MVC style on my PHP/SQL/HTML/CSS code?.