Комментарии 18
symfony (со строчной буквы) — это древнее legacy под PHP 5.3 (хотя есть неофициальный форк до 7.2 включительно точно), современный скелет, фреймворк и набор компонентов — это Symfony. Думал пост о переходе на него :)
А использовались сессии на проекте где-то в глубине? Чаще всего с ними больше всего проблем при переходе из всех суперглобалов, поскольку они активно модифицируются.
А использовались сессии на проекте где-то в глубине? Чаще всего с ними больше всего проблем при переходе из всех суперглобалов, поскольку они активно модифицируются.
*о переходе на symfony, aka symfony1
Исправил. Спасибо. Мы, ларавельщики, такой тонкой разницы не чувствуем.
Для аутентификации и для сохранения форм фильтров. Не припомню, каких-то особых проблем с сессией. Сложнее security было натянуть на существующую логику авторизации.
Двое нас, полгода примерно. Без фичефриза.
Не секрет
Юнит-тестирование было практически невозможным, использовали Сodeception и Selenium. Про тестирование легаси особо сказать нечего, покрыт был наиболее критичный функционал.
Про тестирование нового функционала могу заметить — сначала все тесты жили в папке проекта, потом поняли, что многие из них нужно держать в конкретных бандлах.
Файлов 281
LoC 89058
LLoC 41695
Классов 126 (из них абстрактный только один)Юнит-тестирование было практически невозможным, использовали Сodeception и Selenium. Про тестирование легаси особо сказать нечего, покрыт был наиболее критичный функционал.
Про тестирование нового функционала могу заметить — сначала все тесты жили в папке проекта, потом поняли, что многие из них нужно держать в конкретных бандлах.
очень знакомо :) вам повезло, что в команде остался хоть кто-то (не обязательно программист), который знает, как должна работать система и почему.
а то внезапно оказывается, что шаурма обеспечивала функционал
а то внезапно оказывается, что шаурма обеспечивала функционал
Наличие в первоначальной версии фронт контроллера очень сильно упрощает переписывание кода на современные технологии. А вот если бы его не было, то было бы очень больно. Все же у вас не самый хардкорный legacy был.
А что было с проектом, пока вы его переписывали? Бизнес же не может стоять. А если делать постепенно, то есть шанс превратить проект в некоторый франкенштейн, который также сложно поддерживать.
А что было с проектом, пока вы его переписывали? Бизнес же не может стоять. А если делать постепенно, то есть шанс превратить проект в некоторый франкенштейн, который также сложно поддерживать.
У нас такая же ситуация была. Но фронт контроллера не было, а было распихано по файлам. Проект был в настолько плохом состоянии, что написание тестов только навредило бы. Постелено внедрил в проект Yii2. Теперь от старого кода осталась только БД, которую я постепенно мигрирую на новый манер. Удивительно, но прям сложно это не было.
Сейчас понимаю, что Yii2 — не самый подходящий для нашего проекта инструмент и хочу как-то переползти на Symfony. Только Yii2 не очень-то учит хорошим практикам программирования, и из-за нехватки опыта в свое я успел научиться плохому и жёстко привязать проект к фреймворку. И вот теперь я понимаю, что мигрировать с одного фреймворка на другой будет сложнее, чем этого хотелось
Сейчас понимаю, что Yii2 — не самый подходящий для нашего проекта инструмент и хочу как-то переползти на Symfony. Только Yii2 не очень-то учит хорошим практикам программирования, и из-за нехватки опыта в свое я успел научиться плохому и жёстко привязать проект к фреймворку. И вот теперь я понимаю, что мигрировать с одного фреймворка на другой будет сложнее, чем этого хотелось
Закастомизировали ControllerResolver, он подцеплял легаси контроллеры. Новый функционал писали уже в стиле Symfony, чтобы потом безболезненно к фреймфорку зацепить. Попутно внедряя компоненты типа DI, Security, Twig. Как переехали на Symfony, стали в бандлах писать. А вот совсем недавно весь легась был полностью выпилен! ))
На сколько у вас деградировала производительность при переходе на Doctrine? В текущем проекте пытались переползти на Doctrine, но разница с AR существенна.(
Чтобы заставить Doctrine быть производительной нужно писать много кода.
Чтобы заставить Doctrine быть производительной нужно писать много кода.
Если сравнивать с легаси, то производительность даже выросла. Наш предшественник не много уделял внимания производительности. Например, был класс проверяющий права пользователя, который лазил в базу, кеширования никакого не было, соответственно, на каком-нибудь хитром ui, где нужно было проверять показывать или нет кнопки пользователю, выходило несколько сотен запросов. Самая жесть была на странице, где выводился график всех пользователей с задачами (примерно как в гугл-календаре), там было около 30к запросов.
Так что провести сравнение до/после доктрины возможности не было.
Так что провести сравнение до/после доктрины возможности не было.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DevConf: из шаурмы в Symfony или миграция legacy