Перспектива прототипа в ближайшую пятилетку

[gromdron]

Перспектива прототипа в ближайшую пятилетку

[dmbitrix]

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

Либо если смотреть с другой стороны - в рамках старого проекта параллельно подселить новый фреймворк.

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

[north-leshiy]

В чем тогда смысл использовать его, а не например symfony?

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

Писать свою кастомную админку долго, муторно.

Однако ничего не мешает использовать больше компонентов symfony в новой реализации

[gromdron]

@north-leshiy, возвращаясь к сути дискуссии в сухом остатке, ты за развитие этого в рамках отдельного продукта? Условно - вот у нас есть Битрикс24 - он отдельно, вот у нас есть БУС - он отдельно, а вот у нас есть BF3, который используется отдельно, но может использовать частично тот же код. Берите что хотите.

Я тебя верно понял?

[north-leshiy]

@gromdron Я за плавный переход как было с d7.

Что нужно сейчас нам для поддержки проектов:

1. Шильдик битрикса (требуется по условиям многих контрактов)
2. Админка Битрикса
3. Готовая бизнес логика битрикса (экономит время в ряде случаев)
4. Удобный фреймверк под капотом чтобы это все дружить со современным фронтом

Причем не только для БУС, но и для б24. Мы не первый проект делаем на кастомном фронте.

Наибольшая боль

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

Прогресс не остановить

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

Выпуск альтернативного продукта - тупик

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

[gromdron]

@north-leshiy, ты пишешь очевидные и понятные хотелки, а я говорю исключительно о фактах.
А факт состоит в следующем: представленная структура фреймворка не предполагает миграций существующих проектов архитектурно.

Не надо отвечать мне, попробуй ответить себе:

• Кто будет "переваривать" старые файлы в рабочей директории в новые роуты? 99.9% Битрикс24 это не роуты, а старый urlrewrite.
• Как скрипт миграции будет определять солюшены? Есть много проектов с кастомными страницами в публичке, есть переопределенные компоненты.

Ты много пишешь про то что ты хочешь, а я хочу чтобы ты посмотрел на этот прототип максимально реалистично.
Еще один факт: сейчас у команды 1С-Битрикс распланировано фич и загрузки разработчиков на ~3 года (информация с одной из встреч с вендором по развитию Б24 в 2023 году)
В ближайшие ~3 года революции не будет, так что рассматривать колоссальную работу по изменению не стоит.

Отсюда вопрос: какие перспективы такого революционного подхода? Я вижу 0.

[north-leshiy]

• У меня есть другая информация. Рассчитываю что вендор с этой инициативой нас не обманывает, это не фикция и движение будет.
• Проект по обратной совместимости еще не проработан, о чем Дмитрий говорил на презентаици.
  На эти вопросы вендор должен ответить когда будет их прорабатывать к альфе/бете.
  Сейчас нам показали целевой результат, но детали перехода не проработаны полностью чтобы их обсуждать. Я считаю что вполне можно найти удачный компромис с обратной совместимостью чтобы не жить ближайший десяток лет по уши в устаревших концепциях и коде, а плавно перейти на более свежие рельсы.
• Я понимаю твою обеспокоенность, наличие обратной совместимости важно. Но развитие не менее важно, нельзя жить много лет на легаси и концепциях уровня 5 версии PHP. Нужен компромис.

[gromdron]

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

Каким образом сочетается это решение с солюшенами, сайтами и разделением публички?
Ну например: вот у меня есть классический Б24 развернут as is - куда будут физически классы сайта и солюшены складироваться? В модули? В код? Куда-нибудь-пока-не-определились?

Хотелось бы больше подробностей не столько про новое видение фреймворка, а какой-то более-менее хотя бы гипотетический roadmap на переход/обновление. Т.е. не просто к чему хоти прийти, но и какими шагами.