Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Спасибо за статью, полезная информация)
На картинке типичный костыль.
в этом и была идея — показать костыль, кстати он и выглядит буквально как костыль. Ввиду больших ограничений, которые привносит обратная совместимость иногда сделать «фикс», качество кода которого будет высокое, и мы не будем наращивать технический долг — очень теяжело. Во второй части стать будут конкретные примеры с кодом и как они должны решаться. И будет эволюция ремонта этого крана, так как в офисе у нас было несколько попыток его починить
Я отвечу на комментарий, который юзер donvictorio оставил, а потом удалил:
Релизы 2.0 и 2.1 являются коммерческими релизами платформы, а не релизами компонентов. Они вполне могут быть несовместимы между собой. Хотя между 2.0 и 2.1 несовместимости были минимальны.
Здесь об этом можно почитать подробней
Такая основная идея связи между версиями платформы и версиями компонентов
И когда 2.1 релизилась Magento публиковала список обратно несовметимых измениний для 2.1
именно поэтому 2.0 и 2.1 ветки несовместимы друг с другом и разрабатываются параллельно?
Релизы 2.0 и 2.1 являются коммерческими релизами платформы, а не релизами компонентов. Они вполне могут быть несовместимы между собой. Хотя между 2.0 и 2.1 несовместимости были минимальны.
Здесь об этом можно почитать подробней
Такая основная идея связи между версиями платформы и версиями компонентов
И когда 2.1 релизилась Magento публиковала список обратно несовметимых измениний для 2.1
не понял, ведь magento Это просто CMS причём тут фреймворк? не слышал о таком фреймворке
Двоякое впечатление от статьи. Звучит всё красиво, вот только разрабатывать модули под М2 стало намного проблематичнее. Буду рад, если ошибаюсь.
Практика показывает, что без зависимости от приватного кода сделать можно далеко не всё. Особенно это касается JS части. А значит прощай, обратная совместимость для многих модулей. В этом случае, я так понимаю, единственный выбор — либо держать несколько веток для модуля, либо забивать на старые версии Magento. Первый вариант, мягко говоря, не очень удобен, а второй нереален, если вспомнить, как разработчики в одном из обновлений поломали всю мультисайтовость и потом долго тянули с переносом bugfix из develop ветки. При этом, в М1 с версии 1.4 на моей памяти никогда не было такого, что функционал разительно менялся в рамках одной и той же мажорной версии. Бывало, что закрывали какой-то спорный функционал, но ты всегда мог выпустить новую версию модуля, которая бы работала и на старых версиях тоже. В М2 — не уверен.
Поэтому, допустим, мы всё таки будем держать несколько веток модуля и при каждом багфиксе обновлять их все. Как организовать удобную доставку модуля клиенту исходя из его версии Magento? Казалось бы, ответ очевиден — Magento Marketplace. Нам надо только расписать какие версии модуля подходят для каких версий М2 и Marketplace/composer сам решит, что отдать клиенту. Но в Marketplace ещё надо попасть. А это, как оказалось, в отличие от Magento Connect, совсем нетривиальная задача, решение которой от разработчика вообще мало зависит. Выложить модуль — не меньше месяца ожидания. Выложить обновление модуля — не меньше. Не хочешь использовать Marketplace, ставь себе Satis или какой-нибудь другой аналог packagist для приватных модулей — может, и не суперсложно, но это ещё одна вещь, в которой нужно разобраться.
В результате получается, что по сравнению с разработкой модулей для М1, разработка для М2, которая и так занимает значительно больше времени, обрастает ещё и дополнительными накладными временными расходами, которые далеко не каждый разработчик может себе позволить.
Практика показывает, что без зависимости от приватного кода сделать можно далеко не всё. Особенно это касается JS части. А значит прощай, обратная совместимость для многих модулей. В этом случае, я так понимаю, единственный выбор — либо держать несколько веток для модуля, либо забивать на старые версии Magento. Первый вариант, мягко говоря, не очень удобен, а второй нереален, если вспомнить, как разработчики в одном из обновлений поломали всю мультисайтовость и потом долго тянули с переносом bugfix из develop ветки. При этом, в М1 с версии 1.4 на моей памяти никогда не было такого, что функционал разительно менялся в рамках одной и той же мажорной версии. Бывало, что закрывали какой-то спорный функционал, но ты всегда мог выпустить новую версию модуля, которая бы работала и на старых версиях тоже. В М2 — не уверен.
Поэтому, допустим, мы всё таки будем держать несколько веток модуля и при каждом багфиксе обновлять их все. Как организовать удобную доставку модуля клиенту исходя из его версии Magento? Казалось бы, ответ очевиден — Magento Marketplace. Нам надо только расписать какие версии модуля подходят для каких версий М2 и Marketplace/composer сам решит, что отдать клиенту. Но в Marketplace ещё надо попасть. А это, как оказалось, в отличие от Magento Connect, совсем нетривиальная задача, решение которой от разработчика вообще мало зависит. Выложить модуль — не меньше месяца ожидания. Выложить обновление модуля — не меньше. Не хочешь использовать Marketplace, ставь себе Satis или какой-нибудь другой аналог packagist для приватных модулей — может, и не суперсложно, но это ещё одна вещь, в которой нужно разобраться.
В результате получается, что по сравнению с разработкой модулей для М1, разработка для М2, которая и так занимает значительно больше времени, обрастает ещё и дополнительными накладными временными расходами, которые далеко не каждый разработчик может себе позволить.
В текущих версиях Magento 2.0.x и 2.1.x нельзя обойтись без зависимостей на приватный код.
Потому что у нас недостаточное покрытие
Разработка API — самый сложный процесс в проектировании и разработке программного обеспечения. И так как мы пока не знаем когда именно закончится работа по добавлению сервис контрактов во все модули Magento мы решили в релизе 2.2 отметить
Т.е. в 2.2 мы отметим все «честные контракты», т.е. если функциональность, которую предоставляет модуль реализуется хелпером или ресурс моделью. И получить данную функциональность путем вызова API модуля нельзя, то мы пометим данный хелпер как
Для примера, у нас есть ProductInterface, который определяет набор операций над сущностью продукта. И есть продуктовая модель, которая имплементирует этот интерфейс. Так как сейчас продуктовая модель наследуется от абстрактной модели и соответственно имеет контракт абстрактной модели, то мы не можем сказать сейчас, что сторонний разработчик можем полагаться только на ProductInterface, и если кто-то предоставит свою реализацию этого интерфейса, то сможет легко подменить внутреннюю реализацию мадженто (если это не будет наследник продуктовой модели). Т.е. достаточно много кода в Magento использует метод get/setData который пришел из абстрактной модели. Поэтому в 2.2 мы пометим продуктовую модель как
До релиза 2.2. мы считаем весь код — публичным, т.е. на все классы распространяется политика обратной совместимости. Не только на классы, помеченные
Теперь как мы определяем, что используют, а что нет.
Мы анализируем какие зависимости между модулями Magento использует внутри себя. А также мы анализируем какие зависимости используются экстеншенами на Marketplace (non api dependency). И если зависимости валидны, т.е. такой результат нельзя получить используя текущие API модуля — мы помечаем сущность как
Потому что у нас недостаточное покрытие
@api для этого. Некоторые модули не имеют сервис контрактов вообще (например, wishlist). Поэтому у сторонних разработчиков нет другого выхода кроме как не помеченные api аннотацией.Разработка API — самый сложный процесс в проектировании и разработке программного обеспечения. И так как мы пока не знаем когда именно закончится работа по добавлению сервис контрактов во все модули Magento мы решили в релизе 2.2 отметить
@api все сущности, которые необходимы для написания/кастомизации модулей на мадженто сторонними программистами.Т.е. в 2.2 мы отметим все «честные контракты», т.е. если функциональность, которую предоставляет модуль реализуется хелпером или ресурс моделью. И получить данную функциональность путем вызова API модуля нельзя, то мы пометим данный хелпер как
@api.Для примера, у нас есть ProductInterface, который определяет набор операций над сущностью продукта. И есть продуктовая модель, которая имплементирует этот интерфейс. Так как сейчас продуктовая модель наследуется от абстрактной модели и соответственно имеет контракт абстрактной модели, то мы не можем сказать сейчас, что сторонний разработчик можем полагаться только на ProductInterface, и если кто-то предоставит свою реализацию этого интерфейса, то сможет легко подменить внутреннюю реализацию мадженто (если это не будет наследник продуктовой модели). Т.е. достаточно много кода в Magento использует метод get/setData который пришел из абстрактной модели. Поэтому в 2.2 мы пометим продуктовую модель как
@api, не смотря на то, что у нас уже есть API в виде ProductInterface.До релиза 2.2. мы считаем весь код — публичным, т.е. на все классы распространяется политика обратной совместимости. Не только на классы, помеченные
@api. Разделение концепта на публичный и приватный начнется с 2.2 релиза.Теперь как мы определяем, что используют, а что нет.
Мы анализируем какие зависимости между модулями Magento использует внутри себя. А также мы анализируем какие зависимости используются экстеншенами на Marketplace (non api dependency). И если зависимости валидны, т.е. такой результат нельзя получить используя текущие API модуля — мы помечаем сущность как
@api
Мы анализируем какие зависимости между модулями Magento использует внутри себя. А также мы анализируем какие зависимости используются экстеншенами на Marketplace (non api dependency). И если зависимости валидны, т.е. такой результат нельзя получить используя текущие API модуля — мы помечаем сущность как api
как устроен этот процесс? я так понимаю зависимости вы собираете в автоматическом режиме, а что с определением валидности?
Во время разработки часто встречаются дырявые абстракции, из-за чего приходится юзать приватные части модулей. Причем простым просмотром кода обычно не определить, что использование приватных моделей вместо API это вынужденная необходимость, а не недостаток квалификации разработчика.
Как вы определяете (на основе данных с маркетплейса) сущности, которые необходимо пометить тегом api?
да, зависимости на сущности не отмеченные
После чего списки зависимостей были переданы командам, которые отвечают за конкретные модули.
И команды вместе с командным архитектором проходятся по этому списку в мануальном режиме (анализирую код и зависимости) отмечая какие зависимости являются валидными (т.е. Magento не предоставляет альтернативных API) и для них добавляются
@api собрали в автоматическом режиме.После чего списки зависимостей были переданы командам, которые отвечают за конкретные модули.
И команды вместе с командным архитектором проходятся по этому списку в мануальном режиме (анализирую код и зависимости) отмечая какие зависимости являются валидными (т.е. Magento не предоставляет альтернативных API) и для них добавляются
@api
аннотации, а какие — нет (для которых API аннотация добавлена не будет)Теперь по поводу разработки.
Фактически каждая коммерческая версия Magento — 2.0.*, 2.1.*, 2.2.* это отдельный продукт.
Поэтому имеет смысл иметь отдельные ветки и версии вашего экстеншена под каждую из мажорных коммерческих веток Magento.
Фактически каждая коммерческая версия Magento — 2.0.*, 2.1.*, 2.2.* это отдельный продукт.
Поэтому имеет смысл иметь отдельные ветки и версии вашего экстеншена под каждую из мажорных коммерческих веток Magento.
Про мажорные версии я понимаю.
Просто до этой фразы мне из статьи не было понятно, что это только начиная с 2.2. И что если модуль зависит от приватного кода, то ветки придётся держать не только по мажорным версиям, но и по патч версиям, которые меняют то, от чего модуль зависит. Но если это только с 2.2 и если там действительно можно будет обойтись без зависимостей от приватного кода, то отлично.
До релиза 2.2. мы считаем весь код — публичным, т.е. на все классы распространяется политика обратной совместимости. Не только на классы, помеченные api. Разделение концепта на публичный и приватный начнется с 2.2 релиза.
Просто до этой фразы мне из статьи не было понятно, что это только начиная с 2.2. И что если модуль зависит от приватного кода, то ветки придётся держать не только по мажорным версиям, но и по патч версиям, которые меняют то, от чего модуль зависит. Но если это только с 2.2 и если там действительно можно будет обойтись без зависимостей от приватного кода, то отлично.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Политика обратной совместимости при разработке фреймворка на примере Magento 2. Часть 1