чуваки, почему у Симфони такая убогая инфраструктура?

Всем привет. Был ли у кого опыт перехода в рамках большого легаси проекта на другой фреймворк, в идеале на Symfony? Что можете посоветовать? С какой стороны вообще заходить? Что можно почитать? Что имеется? - Самописная CRM на Codeigniter - Команда порядка 10 человек, из которых реально могут что-то делать 2-3 - Все чаще появляющиеся ответы - хз как отрабатывает тот или инной бизнес процесс - Большие классы-модели по 15к строк, в которых методы делают все, что душе угодно - База данных MYSQL с таблицами по 100 полей - Быстро изменяющиеся требования и функциональность проекта (чаще всего наростание функционала) Что нужно? - Слезть с иглы codeigniter и дальнейшего погружения в тлен - Оставлять проект в рабочем состоянии на время перехода - Иметь возможность проводить процесс перехода плавно т.к. нет возможности выделить большую команду и остановить всю разработку Буду благодарен любым советам, ссылкам, мыслям

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

Всем привет. Был ли у кого опыт перехода в рамках большого легаси проекта на другой фреймворк, в идеале на Symfony? Что можете посоветовать? С какой стороны вообще заходить? Что можно почитать? Что имеется? - Самописная CRM на Codeigniter - Команда порядка 10 человек, из которых реально могут что-то делать 2-3 - Все чаще появляющиеся ответы - хз как отрабатывает тот или инной бизнес процесс - Большие классы-модели по 15к строк, в которых методы делают все, что душе угодно - База данных MYSQL с таблицами по 100 полей - Быстро изменяющиеся требования и функциональность проекта (чаще всего наростание функционала) Что нужно? - Слезть с иглы codeigniter и дальнейшего погружения в тлен - Оставлять проект в рабочем состоянии на время перехода - Иметь возможность проводить процесс перехода плавно т.к. нет возможности выделить большую команду и остановить всю разработку Буду благодарен любым советам, ссылкам, мыслям

А зачем 7 человек, которые не могут ничего сделать?

Откат

Всем привет. Был ли у кого опыт перехода в рамках большого легаси проекта на другой фреймворк, в идеале на Symfony? Что можете посоветовать? С какой стороны вообще заходить? Что можно почитать? Что имеется? - Самописная CRM на Codeigniter - Команда порядка 10 человек, из которых реально могут что-то делать 2-3 - Все чаще появляющиеся ответы - хз как отрабатывает тот или инной бизнес процесс - Большие классы-модели по 15к строк, в которых методы делают все, что душе угодно - База данных MYSQL с таблицами по 100 полей - Быстро изменяющиеся требования и функциональность проекта (чаще всего наростание функционала) Что нужно? - Слезть с иглы codeigniter и дальнейшего погружения в тлен - Оставлять проект в рабочем состоянии на время перехода - Иметь возможность проводить процесс перехода плавно т.к. нет возможности выделить большую команду и остановить всю разработку Буду благодарен любым советам, ссылкам, мыслям

Был опыт переезда с симфония на симфония 2

Мертвые души

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

3 разработчика и макаки в общем

начать нужно с создания AppKernel во всех точках входа (в идеале привести все к одной точке входа). Потом прикручиваем DI и начинаем выносить все в сервисы. Потом можно заморочиться с Request/Response. Дальше - куда душа ляжет

Всем привет. Был ли у кого опыт перехода в рамках большого легаси проекта на другой фреймворк, в идеале на Symfony? Что можете посоветовать? С какой стороны вообще заходить? Что можно почитать? Что имеется? - Самописная CRM на Codeigniter - Команда порядка 10 человек, из которых реально могут что-то делать 2-3 - Все чаще появляющиеся ответы - хз как отрабатывает тот или инной бизнес процесс - Большие классы-модели по 15к строк, в которых методы делают все, что душе угодно - База данных MYSQL с таблицами по 100 полей - Быстро изменяющиеся требования и функциональность проекта (чаще всего наростание функционала) Что нужно? - Слезть с иглы codeigniter и дальнейшего погружения в тлен - Оставлять проект в рабочем состоянии на время перехода - Иметь возможность проводить процесс перехода плавно т.к. нет возможности выделить большую команду и остановить всю разработку Буду благодарен любым советам, ссылкам, мыслям

берешь отдельные компоненты и решает проблемы. Смена фреймворка просто так не решает проблем а лишь замораживает разработку на хз сколько времени

например есть проблема - управление зависимостями. Ставишь какой-нибудь контейнер поудобнее и работаем дальше. Причем не переводим приложение полностью на него - а постепенно. Фичи ж надо пилить тоже

и главное при всем этом - тесты писать. Разобрался как работает кусок - покрыл тестами поведение.

пишешь что-то новое - покрыл тестами

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

ну и правило бойскаута - оставляй код который ты сейчас трогаешь чуть чище чем он был до тебя. Хотя без тестов это сложно)

понятно - спасибо) Просто как раз таки этого сейчас и боимся, что начнем чтото делать и скатимся опять к легаси. Пока из всего что обсуждали мне твой вариант больше по душе т.к. он более плавный и из всего что нам предлагали чуваки с других проектов - это разбивать все на микросервисы(но тут мне кажется мы вообще все заруиним и прийдется искать другую работу :D) или делать "бридж" между двумя фреймворками. Но я не особо вижу как это можно совмещать с длительным процессом перехода и необходимостью попутно пилить фичи.

> это разбивать все на микросервисы это норм стратегия. Есть еще более клевый вариант. То же самое но без микросервисов. Ну или два микросервиса - старое приложение и новое.

профит - если не умеешь готовить микросервисы ты проиграешь

а так будет проще

хотя опять же вариант есть еще круче - тоже самое но вообще без разделения. Просто одно приложение монолитное

все те же идеи изоляции из мира микросервисов приминимы и для монолитов

только не надо страдать болью с распределенными системами

> это разбивать все на микросервисы это норм стратегия. Есть еще более клевый вариант. То же самое но без микросервисов. Ну или два микросервиса - старое приложение и новое.

Это типа новый функционал писать на новом фрейморке, а все данные которые нужны из старого кода получать по API? + понемногу переносить весь функционал на новый фрейморк?

что касается моделек опять же, ставите ту же доктрину и постепенно выносите логику в сущности

причем взаимодействие между частями как раз и получится как у "микросервисов", будет два bounded context которые никогда не будут работать в одной транзакции

ну т.е. eventual consistency

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

> в идеале добавляйте сценарии на чем-то типа behat т.е. можно просто конечно доку составлять, но лучше с автотестами)

Это типа новый функционал писать на новом фрейморке, а все данные которые нужны из старого кода получать по API? + понемногу переносить весь функционал на новый фрейморк?

повторю - смена фреймворка в 90% случаев ничего не меняет.

что касается моделек опять же, ставите ту же доктрину и постепенно выносите логику в сущности

это если схема базы норм

не

а так возможно стоит начать не с доктрины

старую не трогать

это ж больно

ну можно тупо заюзать row data gateway + active record

ну вообще да

выйдет больше кода но зато можно очень быстро рефакторить

тут возможно так проще, если таблички реально ад и угар

таблички ад и угар полный

хотя с другой стороны можно мапить туда-сюда

пилили все как хотели и могли порядка 8 лет

таблички ад и угар полный

а вообще у тебя есть представление о том что в проекте хуже всего? или "плохость" равномерно распространена и нельзя выделить приоритетные участки?

хотя с другой стороны можно мапить туда-сюда

можно, тригерами и процедурами обратную совместимость налаживать

все равномерно плохо

я так понимаю руководитель проекта понял что мы катимся к ... и решил начать чтото предпринимать

хотя с другой стороны можно мапить туда-сюда

типа поняли как работает маленький кусок, какой-нибудь банальный тикет

все равномерно плохо

ок, тогда по другому вопрос поставлю. Фичи новые планируется? Баги возникают где-то? Есть более приоритетные баги?

еще год назад все все устраивало

а что не устраивает теперь? зачем нужна Симфони?

есть ответ на этот вопрос?

вот я тоже не понимаю)

ну почему смена фреймворка ничего не меняет? Есть код - неконтролируемый и нетестируемы код, в октором уже никто не может разобраться.

"я так понимаю руководитель проекта понял что мы катимся" - это же не причина

и никто не знает откуда прилетит баг

ну так будет такой же новй код только на симфони

сейчас не устаривает то, что все становится неконтролируемым

для этого проще переписать функционал

вносишь изменения в одно и думаешь что это ничего не затронет - а вылазит вообще в местах где никогда бы не подумал

зачем его снова писать на CI если мжно заюзать удобную симфони

и бывают случаи когда изменив мелоч - ты отваливаешь просто куски

ну почему смена фреймворка ничего не меняет? Есть код - неконтролируемый и нетестируемы код, в октором уже никто не может разобраться.

и ты на выходе получишь такой же неконтролируемый и не тестируемый код.

почему?

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

почему?

потому что подавляющее большинство не умеет писать тестируемый и контролируемый код)))

ERROR: S client not available

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

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

вот это похоже на план)

а смена фреймворка похожа на имитацию бурной дейтельности. У вас не с фреймворкрм проблема а с кодом

сначала надо код подготовить к переезду

а если весь код нужно переписать?

то почему не сменить фреймор по ходу дела

а если весь код нужно переписать?

никогда не нужно переписывать ВЕСЬ код, всегда можно выделить приоритетные участки

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

ну и опять же - добавляешь нужные компоненты

ох что-то мне прям знакомо это, кодгнитер, 8 лет, 100 полей на таблицу, но наверное это не то, о чем я думаю :)

но просто взять и "а давайте перепишем все на symfony" это одно из худших решений которые можно предложить бизнесу

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

еще базу можно вьюшками чистить)

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

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

никогда не нужно переписывать ВЕСЬ код, всегда можно выделить приоритетные участки

приоритеты то выделить можно, но что если в теории нужно понемногу переписать все?

зачем делать полумеры, если можно наперед начать норм разработку

привет, подскажите, может есть либа для автоматического мапинга массива данных на такие объекты с аннотациями: /** * Document DTO */ class Document { /** * @var string */ public $code; /** * @var string */ public $title; /** * @var \DateTimeImmutable */ public $created; /** * @var Element[] */ public $elements = []; } /** * Element DTO */ class Element { /** * @var string */ public $name; /** * @var string */ public $content; }

приоритеты то выделить можно, но что если в теории нужно понемногу переписать все?

это не то же самое что сделать фичафриз и остановить бизнес на пол года. Так или иначе все будет переписано но не будет мешать бизнесу

Всем привет. Был ли у кого опыт перехода в рамках большого легаси проекта на другой фреймворк, в идеале на Symfony? Что можете посоветовать? С какой стороны вообще заходить? Что можно почитать? Что имеется? - Самописная CRM на Codeigniter - Команда порядка 10 человек, из которых реально могут что-то делать 2-3 - Все чаще появляющиеся ответы - хз как отрабатывает тот или инной бизнес процесс - Большие классы-модели по 15к строк, в которых методы делают все, что душе угодно - База данных MYSQL с таблицами по 100 полей - Быстро изменяющиеся требования и функциональность проекта (чаще всего наростание функционала) Что нужно? - Слезть с иглы codeigniter и дальнейшего погружения в тлен - Оставлять проект в рабочем состоянии на время перехода - Иметь возможность проводить процесс перехода плавно т.к. нет возможности выделить большую команду и остановить всю разработку Буду благодарен любым советам, ссылкам, мыслям

был опыт переезда с гавно-легаси на зенду 1ю и с 1й зенды на 2ю. поэтому советую 10 раз подумать чем такое делать)

когда вам предлагают микросервисы как панацею, можешь смеяться в лицо таким людям

зачем делать полумеры, если можно наперед начать норм разработку

потому что "переписать все" это вообще не решение проблемы.

они не знают о чем говорят

когда вам предлагают микросервисы как панацею, можешь смеяться в лицо таким людям

+1

привет, подскажите, может есть либа для автоматического мапинга массива данных на такие объекты с аннотациями: /** * Document DTO */ class Document { /** * @var string */ public $code; /** * @var string */ public $title; /** * @var \DateTimeImmutable */ public $created; /** * @var Element[] */ public $elements = []; } /** * Element DTO */ class Element { /** * @var string */ public $name; /** * @var string */ public $content; }

@fes0r пытался сделать такое)

@fes0r пытался сделать такое)

и забил. Есть всякие автомэпперы

привет, подскажите, может есть либа для автоматического мапинга массива данных на такие объекты с аннотациями: /** * Document DTO */ class Document { /** * @var string */ public $code; /** * @var string */ public $title; /** * @var \DateTimeImmutable */ public $created; /** * @var Element[] */ public $elements = []; } /** * Element DTO */ class Element { /** * @var string */ public $name; /** * @var string */ public $content; }

сериалайзер симфони можешь взять, но там нет аннотаций

@sergey_smile чего вы вообще ожидаете от перехода на другой фреймворк?

это не то же самое что сделать фичафриз и остановить бизнес на пол года. Так или иначе все будет переписано но не будет мешать бизнесу

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

@sergey_smile чего вы вообще ожидаете от перехода на другой фреймворк?

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

и смыла это делать в том же месте -мало

приоритеты то выделить можно, но что если в теории нужно понемногу переписать все?

короч... моя мысль: Представь что у тебя есть проект и ты хочешь повысить устойчивость системы. Ты можешь потратить скажем 2-4 недели на устранение основных деффектов или 4 месяца на то что бы написать с нуля core функциональность. Второй вариант окупится через годик-два если за эти 4 года у тебя все клиенты не уйдут.

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

ну это то что я и предлагал как один из вариантов. ТОлько я бы пошел еще дальше - и убрал бы необходимость общаться через API.