Доработка сайтов на PHP

PHP — до сих пор самый распространённый язык серверной части рунета: на нём написаны и десятилетние самописные системы, и свежие проекты на Laravel или Symfony. Доработка такого сайта — это всегда сначала разбор конкретного стека, а не универсальный прайс «за строчку кода». Один и тот же запрос — «добавить личный кабинет» — может занять день на Laravel с готовой авторизацией и неделю на самописной системе без единого класса аутентификации.

Три типа PHP-проектов, которые встречаются на практике

• Легаси-самопис: процедурный код или ранний ООП без фреймворка, часто без версий и тестов
• Проект на фреймворке первого поколения: старый Yii, CodeIgniter, Zend без миграций и очередей
• Современный стек: Laravel/Symfony с composer, миграциями, тестами и CI
• Гибрид: CMS (Bitrix, MODX, самописная) плюс кастомные модули на чистом PHP

Что обычно просят доработать

1. Новый функционал: личный кабинет, калькулятор, подписка, экспорт данных
2. Интеграции: платёжные системы, CRM, службы доставки, 1С, мессенджеры
3. Исправление багов в бизнес-логике: некорректные расчёты, гонки данных, утечки памяти в долгих процессах
4. Оптимизация запросов к БД: N+1, отсутствующие индексы, тяжёлые JOIN на больших таблицах
5. Миграция части логики на актуальную версию PHP (8.x) без потери совместимости

Как оценивают доработку без документации

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

• Просмотр структуры каталогов и точек входа (index.php, роутинг)
• Поиск мест, где меняются данные — модели, DAO, прямые SQL-запросы
• Проверка версии PHP и совместимости с текущими библиотеками
• Оценка покрытия тестами (если есть) — от этого зависит риск регрессии

Безопасность точечных правок

Правки в старом PHP-коде опасны не сложностью синтаксиса, а скрытыми связями: одна и та же функция может использоваться в трёх разных сценариях, и правка ради одного из них ломает два других. Работающая практика — покрыть минимальными тестами именно тот участок, который меняется, до правки, а не после. Так регрессия видна сразу, а не через две недели в проде.

Когда пора не дорабатывать, а переписывать

• Каждая новая фича занимает больше времени, чем предыдущая аналогичная
• Нет ни одной версии PHP, под которую код можно спокойно обновить без правок в половине файлов
• Логика дублируется в пяти местах с мелкими отличиями
• Развернуть проект на новом сервере — отдельный квест на несколько дней

Если совпало три пункта из четырёх — доработка становится дороже переписывания уже на горизонте года. Здоровый средний путь — постепенный рефакторинг: новый функционал сразу пишется по современным практикам (composer-зависимости, слои, тесты), а старый код трогается только по необходимости.

Окружения, деплой и сопровождение после правки

Даже идеальная правка в локальной копии бессмысленна, если на продакшене другая версия PHP, отключены нужные расширения или cron не запускает фоновые задачи. Перед сдачей задачи стоит зафиксировать минимальные требования к серверу, порядок выкладки (миграции БД, очистка opcache, прогрев кеша) и кто отвечает за откат, если что-то пошло не так. Для проектов без CI хотя бы чек-лист ручного деплоя снижает риск «забыли залить один файл» — типичной причины странных багов, которые невозможно воспроизвести локально.

1. Сверить версию PHP и список расширений на staging и проде
2. Прописать порядок миграций и бэкапа БД перед релизом
3. Проверить права на каталоги загрузок и логов после выкладки
4. Зафиксировать в задаче, какие URL и сценарии проверены после деплоя