В международном чате Joomla-сообщества в Mattermost идёт обсуждение статьи команды JoomlaShack "Мысли о миграциях Joomla и Joomla 5".Вступление
В статье говорится о том, что в истории развития Joomla было уже 4 крупных миграции кодовой базы:
1.0 to 1.5
1.5 to 1.6
1.6 to 3
3 to 4
Эти миграции вызваны тем, что новая версия CMS претерпевает такие изменения, что код расширений во многом оказывается не совместим и требует переписывания но новую систему классов или файловую структуру. Такие изменения "под капотом" напрямую не видны пользователям, нередко очень трудоёмки. Разработчики расширений вынуждены выбирать между тем, что обновлять кодовую базу расширения ради совместимости с новой версией CMS или направлять усилия на развитие продукта - внедрять новый функционал, улучшать старый, исправлять ошибки.
Стив из Joomlashack рассказал, что самые простые свои расширения они адаптировали для Joomla 4 за несколько часов (каждое). Steve
CEO of Joomlashack. Originally from the UK, he now lives in Sarasota in the USA. Steve has been involved with Joomla since 2006.
Расширение средней сложности обновлялось от 3 до 4 месяцев. В то время как обновление "тяжёлых" компонентов занимает около года. При этом у одного разработчика (как Ян Павелка, Phoca.cz) или команды (те же JoomlaShack; MAXXmarketing - JoomShopping; Virtuemart) может быть несколько десятков, даже больше сотни расширений. От "тяжелых" компонентов зависит также и сложившаяся вокруг них экосистема расширений сторонних разработчиков.
Посыл статьи в целом таков: "Мы давно с Joomla. Мы любим Joomla. Но ещё одной такой миграции мы не выдержим. Скоро Joomla 5 и мы нервничаем."Что будет меняться в Joomla 5 и Joomla 6
В сентябре 2022 на хабре был опубликован скорректированный план выпуска релизов Joomla 4 и Joomla 5. В нём говорится о том, что переход с одной мажорной версии на другую (Joomla 4 -> Joomla 5, Joomla 5 -> Joomla 6) будет максимально сглажен:
Joomla 5 не будет включать в себя критические изменения для шаблонов и сторонних расширений.
Не будет удален код, который был помечен как устаревший в Joomla 4.
Joomla 5 будет иметь минимальную версию PHP 8.1.
Компоненты, которые работают в Joomla 4, также должны работать в Joomla 5, если они поддерживают PHP 8.1.
Joomla 5 выйдет в октябре 2023 года. Из-за вышеперечисленных моментов это не будет большим и болезненным обновлением, как в прошлых выпусках.
Минорные релизы (4.1 -> 4.2 -> 4.3 etc) продолжат выходить раз в 6 месяцев. Все релизы будут перенесены на апрель и октябрь, начиная с выпуска версии 4.3 в апреле 2023 года. Joomla 6
В 2023 году Joomla исполнится 18 лет. Последнее обновление, ломавшее обратную совместимость было больше 10 лет назад. Даже сейчас встречаются расширения, использующие внутри код, написанный для 1.0 или 1.5, но всё ещё работающий на 3.10. И даже попытки перенести этот код в Joomla 4 нередко связаны с тем, "лишь бы завелось".
Сообщалось, что в Joomla 5 классы, обеспечивающие обратную совместимость для расширений будут вынесены в отдельный плагин. Таким образом в Joomla 5 продолжат работу расширения написанные для Joomla 3. Но это в целом отодвигает проблему на пару лет в будущее. Поэтому разработчики расширений задают вопросы о том, будет ли сохранена поддержка старой файловой структуры расширений вида views/view/view.html.php -> views/view/tmpl/default...
На что представитель Production Department Hannes Papenberg ответил, что:
Строго рекомендуется начать использовать новую структуру расширений для Joomla, но я так же не вижу причин для удаления поддержки старой структуры расширений.Hannes Papenberg
один из разработчиков ядра Joomla, Team Leader of Bug Squad, участник Automated Testing Team, Framework Working Group, CMS Maintenance Team, Production Department,
В Joomla 6 предполагается перевести class mapping со старых имён вида JModelAdmin и т.д. в новые namespaced classes.У нас нет интереса ломать что-то просто ради удовольствия. Для этого должна быть причина, а ее нет. Аналогично и с классами MVC. В какой-то момент мы могли бы создать второй набор классов MVC, которые каким-то образом лучше того, что у нас есть в настоящее время, но даже если бы мы это сделали, классы работали бы параллельно. Эти классы не появятся в версии 5.0, а старый хлам не будет удален до Joomla 8.0, если вообще будут удалён.
Hannes PapenbergТехнический долг
В целом, эта дискуссия относится к борьбе отдела продаж/маркетинга и отдела разработки в условной IT-компании.
Приведу слова одного знакомого разработчика:
Да, с точки зрения заказчика это вообще что-то непонятное. Но технический долг крайне негативно влияет на психику разработчика, непредсказуемо увеличивает трудоемкость в будущем и крайне несвоевременно напоминает о себе в самое неподходящее время....
Если переделать и уменьшить, то в 99% внешне ничего не изменится. Но если оставить как есть и допустить бесконтрольный рост, то рано или поздно задача, которая обычно решалась бы за 2 недели, становится не решаемой или требует 1-2 месяца (
Была на одном проекте ситуация, что опять прибежали менеджеры и хотели много и всего. А у нас уж совсем много накопилось и были вполне конкретные планы по рефакторингу. Они спросили, что поменяется — мы сказали, что для клиента ничего, и они (менеджеры) тоже ничего не заметят. Ну, тогда мол лучше сделайте очень срочную задачу, которую мы уже продали клиентам неделю назад, а вот это ваше непонятное — как-нибудь потом.
Мы тогда уперлись и сказали, что либо нас 1.5-2 недели не трогают, мы наводим порядок (как вообще изначально планировали), либо мы беремся за очередную «срочную» задачу, но пусть потом не удивляются, когда вместо обычных оценок в 1-2 недели мы скажем «полгода» или «вообще не реализуемо в рамках текущей архитектуры».
С моей точки зрения и отсутствие тестов, и всякое legacy, и плохая кодовая база — это всё тоже технический долг, наравне с костылями, компромиссными решениями и всякими TODO в коде в стиле «потом надо будет поправить».
У нас вообще было правило: нашел что-то странное в коде при решении задачи — сразу заводится JIRA. Если можно впихнуть исправление в рамках текущей задачи - то подзадачей и быстро исправляется, если нет — то сразу на вершину backlog.
Причем, если в процессе разработки поменялась концепция, и очередной кусок попробовали сделать иначе, с другим подходом, и получилось хорошо, то все предыдущие тоже помечаются на рефакторинг — и это тоже технический долг. Потому, что кодовая база должна быть равномерна и однообразна. Нет ничего хуже «письма дяди Фёдора», когда в соседних классах/сервисах/модулях примерно одно и то же делается 8-10 разными способами. Это потом существенно ухудшает управляемость и препятствует масштабируемости.
Нет ничего плохого в инновациях и пересмотре концепции, но нет ничего хуже, если предыдущие куски остаются как есть с походом «работает — не трогай», вот с этим я непрерывно борюсь) Но это вечный и в каком-то смысле неравный бой…Так же полезные ресурсыРесурсы сообщества:
форум русской поддержки Joomla.
интернет-портал Joomla-сообщества.
Сообщество Joomla на VC.Telegram:
чат сообщества «Joomla! по-русски».
Joomla для профессионалов, разработчики Joomla.
Новости о Joomla! и веб-разработке по-русски.
Новости о Joomla! и веб-разработке по-английски.
вакансии и предложения работы по Joomla: фуллтайм, частичная занятость и разовые подработки. Размещение вакансий здесь.
Англоязычный чат сообщества.
Источник новости: habr.com
