Как восстановить архитектуру устаревшей системы (PHP)
Я пытаюсь восстановить архитектуру унаследованной системы. Это что-то новое для меня. До сих пор я читал множество исследовательских работ, в которых большинство исследователей предлагали для этого фреймворки и автоматизированные инструменты. Лучшее из этих фреймворков или инструментов. У всех исследованных есть набор общих шагов, таких как обратный инжиниринг и прямой инжиниринг. Может кто-нибудь помочь в этом? Что является основным этапом для начала построения архитектуры восстановления унаследованной системы? Какие основные шаги? Есть какие-нибудь рекомендации? Спасибо
Спасибо за помощь. Я потерял свою учетную запись google и из-за этого не смог получить доступ к стеку. Спасибо за вашу помощь.
Ваша первая проблема - определить «архитектуру»; большинство людей используют это слово, но не имеют точного определения. Имея такое точное определение, вы можете спросить, какие подходы / инструменты используются для извлечения такой архитектуры. В основном вы будете разочарованы фактическими доступными инструментами, а) потому что эти инструменты сложно построить [а язык PHP усугубляет ситуацию] и б) потому что существует так много различных возможных определений архитектуры.
Ответы 1
При преобразовании устаревшей системы вы должны помнить как о технологии, так и о команде. Изменения, которые вы должны внести, коснутся ядра приложения, и, если команда разработчиков не будет участвовать в внесении изменений, это будет долгая медленная миграция.
Ключом к переработке унаследованной системы является внедрение зависимостей и расположение службы. Первым шагом является установка контейнера внедрения зависимостей и добавление класса в контейнер (Logger всегда является хорошей первой услугой).
Следующим шагом является добавление локатора услуг. Внедрение конструктора - лучший подход для новых проектов, но для устаревших приложений это сначала невозможно. С помощью локатора сервисов вы можете получить доступ к контейнеру внедрения из любого места, что позволяет разрешать сервис там, где это необходимо. Имея это место, вы можете просмотреть и заменить код создания регистратора на код разрешения регистратора.
Замена регистратора - отличный пример того, как работает DI, так что продемонстрируйте это команде. Убедитесь, что команда полностью понимает эти концепции! Остальная часть процесса сильно зависит от DI и местоположения службы.
Контейнер DI нарушает тесную связь в устаревших системах, поэтому вы можете разорвать их на части. Начните искать стыки, где вы можете разбить приложение на более мелкие части, что позволит вам ввести модульное тестирование. Это также заложит основу для миграции DDD, микросервисов, EDA или любой другой целевой архитектуры, которую вы запланировали.
Спасибо за помощь. Думаю, теперь у меня есть над чем поработать. Я выполню эти шаги. Это было большим подспорьем. Прошу прощения за поздний ответ, так как я не смог войти в учетную запись переполнения стека.
Не забудьте пометить вопрос "отвеченным", когда будете удовлетворены.