Перейти к содержимому
DedicatedPHP Контакт
Руководство по принятию решений

Как модернизировать PHP-приложение, не нарушая работу бизнеса.

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

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

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

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

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

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

  1. ПодготовитьКонтекст, доказательства, ограничения и владельцы.
  2. ИспытаниеВарианты, предположения, риски и затраты на изменения.
  3. РешатьСледующий шаг: определение границ и критериев успеха.
  4. ОбзорРезультаты и условия, влияющие на принятие решения.

1. Дайте определение слову «модернизировать».

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

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

2. Создайте базовый уровень.

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

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

3. Выберите стратегию.

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

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

4. Защита поведения

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

  • Потоки и критерии приемки.
  • Репрезентативные данные и конфиденциальность.
  • Внешние интерфейсы и побочные эффекты.
  • Базовый режим работы.

5. Внедрение поэтапно.

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

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

6. Глубокое знание и опыт работы.

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

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

Примените это руководство к своему приложению.

Мы анализируем ситуацию, имеющиеся данные и варианты действий, не привязывая оценку к реализации.

Запросить оценку