Доработка и поддержка PHP-проектов, включая legacy

Система работает. Интернет-магазин принимает заказы, внутренний портал используют сотрудники, CRM обслуживает клиентов, интеграции передают данные. Но развивать проект становится всё сложнее.

Бывший разработчик больше не занимается системой. Новая команда осторожно смотрит на чужой код. Документации нет. Каждая небольшая доработка превращается в исследование. Обновление версии PHP откладывается годами, потому что никто не может заранее оценить последствия.

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

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

Когда PHP-проект становится legacy

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

Обычно владельцы обращаются за поддержкой, когда:

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

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

С какими проблемами приходят чаще всего

Разработчик ушёл, а проект остался

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

Новая задача начинается с вопроса «где это вообще меняется?». Без понимания кода даже простая правка может затянуться и создать новые ошибки.

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

Система работает на устаревшей версии PHP

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

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

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

Каждая доработка создаёт новые ошибки

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

Мы помогаем снизить хаос: выделяем критические сценарии, добавляем проверки, фиксируем взаимосвязи, документируем важные участки и постепенно делаем изменения более предсказуемыми.

Документации нет

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

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

Проект нужен бизнесу каждый день

Нельзя просто остановить CRM, интернет-магазин, B2B-портал или внутреннюю систему на несколько месяцев. Поэтому развитие legacy-проекта должно быть поэтапным.

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

Что входит в поддержку PHP-проекта

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

Технический аудит

Аудит показывает реальное состояние проекта до любых серьёзных изменений.

Мы проверяем:

• архитектуру;
• структуру кода;
• версию PHP;
• фреймворк или самописную основу;
• зависимости;
• Composer-пакеты;
• базу данных;
• интеграции;
• серверное окружение;
• безопасность;
• производительность;
• наличие тестов;
• критические пользовательские сценарии;
• документацию и доступы.

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

Приём проекта на сопровождение

Мы берём в работу существующие PHP-проекты независимо от того, кто их разрабатывал.

Это могут быть:

• кастомные сайты;
• интернет-магазины;
• CRM;
• B2B-порталы;
• личные кабинеты;
• внутренние сервисы;
• API;
• интеграционные слои;
• веб-приложения;
• старые проекты на фреймворках;
• самописные системы.

Перед началом регулярной поддержки фиксируем текущее состояние и договариваемся о правилах изменений, приоритетах и формате взаимодействия.

Исправление ошибок

Исправляем ошибки в бизнес-логике, формах, API, интеграциях, личных кабинетах, админ-панелях, заказах, авторизации, оплатах, уведомлениях и других частях системы.

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

Разработка нового функционала

После знакомства с проектом можно безопасно развивать систему: добавлять разделы, роли, интеграции, отчёты, автоматизацию, API, административные инструменты и новые пользовательские сценарии.

Наша задача — добавлять возможности так, чтобы проект становился управляемее, а не ещё сложнее для поддержки.

Обновление PHP и зависимостей

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

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

Рефакторинг и снижение технического долга

Рефакторинг не должен быть абстрактным «улучшением кода». Он нужен там, где технический долг мешает бизнесу: увеличивает сроки доработок, создаёт ошибки, блокирует обновления или делает систему слишком дорогой в поддержке.

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

Регулярная техническая поддержка

После аудита и первых задач можно перейти к постоянному сопровождению.

В поддержку могут входить:

• исправление ошибок;
• консультации;
• обновления PHP и зависимостей;
• мониторинг критических сценариев;
• развитие функциональности;
• оптимизация производительности;
• работа с интеграциями;
• документирование изменений;
• планирование модернизации.

Как мы принимаем чужой PHP-проект

Перед началом работ мы не обещаем сроки «с первого взгляда». Сначала нужно понять текущее состояние системы.

1. Собираем доступы и контекст

Запрашиваем доступ к репозиторию, серверу или тестовой копии, базе данных, логам, документации, CRM, API и связанным сервисам.

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

2. Проводим аудит

Изучаем архитектуру, код, зависимости, версию PHP, базу данных, интеграции, серверное окружение, безопасность, производительность и критические сценарии.

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

3. Готовим план работ

После аудита предлагаем понятный маршрут:

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

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

4. Выполняем изменения поэтапно

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

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

Когда нужна полная перепись, а когда нет

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

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

Поэтому мы сначала оцениваем варианты:

• поддерживать текущую систему;
• стабилизировать критические участки;
• обновить PHP и зависимости;
• вынести отдельные модули;
• заменить проблемные интеграции;
• постепенно рефакторить код;
• переписать только часть проекта;
• запускать новую систему поэтапно.

Иногда лучшая стратегия — оставить рабочее ядро и аккуратно модернизировать вокруг него. Иногда разумнее спланировать новую архитектуру. Решение принимается после аудита, а не по впечатлению от возраста проекта.

Почему Origami

Работаем с PHP с 2008 года

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

Не боимся legacy

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

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

Понимаем интеграции и бизнес-процессы

Работаем не только с приложением, но и с API, CRM, ERP, 1С, платёжными системами, логистикой, маркетинговыми сервисами, внутренними инструментами и другими корпоративными интеграциями.

Делаем процесс прозрачным

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

Сохраняем фокус на бизнесе

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

Origami работает с 2008 года и реализовала более 150 проектов. Примеры можно посмотреть в портфолио Origami.

FAQ

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

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

Что делать, если документации вообще нет?

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

Можно ли обновить старую версию PHP?

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

Можно ли поддерживать проект без полной переписи?

Да. Полная перепись требуется не всегда. Часто достаточно аудита, стабилизации, обновления окружения, исправления критических ошибок и постепенного рефакторинга.

Сколько занимает принятие проекта?

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

Как выглядит поддержка после аудита?

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

Можно ли работать без остановки бизнеса?

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

Что делать, если проект небезопасен?

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

Получите аудит PHP-проекта

Если существующая система стала сложной для развития, не обязательно начинать всё заново.

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

Обсудить задачу с Origami