Модульность - удобно или нет?

Правила раздела: faq.php?mode=okay
Модератор: Модераторы

korshunov
korshunov
Репутация: 89
Сообщения: 1082
Зарегистрирован: 03.12.2015
С нами: 3 года 11 месяцев
Skype

Сообщение #1 korshunov » 23.10.2019, 07:09

Несколько дней назад разговор с заказчиком возник:
- Хочу для версии 3 сделать отдельный фид как для Розетки, но с некоторыми изменениями. Сколько будет стоить?
- Столько-то.
- Дорого, там же шаблон чуть поменять.
- Тогда попробуйте сами чуть поменять.
На том и кончилось.

Через пару дней продолжение:
- Помните, я просил отдельный фид по образцу Розетки. Сделайте, согласен на Вашу цену.
- Хорошо, сделаю. А сами почему не справились? Там же вроде бы копированием основная работа должна делаться.
- Да, но потом исправлять много надо. Два часа провозился, и конца не видно.


На форуме разработчики много раз подчеркивали преимущество разработанной ими модульности - мол, скопировал папку, и все заработало.

Чтобы сделать дубль работающего модуля (Розетка для примера), просто так скопировать в соседнюю папку не выйдет, например, потому что внутри модуля почти в каждом файле прописаны установки типа
namespace Okay\Modules\OkayCMS\Rozetka\ExtendsEntities;
которые требуют, чтобы папка модуля называлась именно Rozetka, и никак иначе. Довольно неудобно.

Чтобы заработал дубль, приходится менять все такие вхождения, скажем, на Rozetka2, новую папку называть Rozetka2 и еще некоторые изменения делать. Работы довольно много, даже если использовать автоматические замены. А менять-то сотню мест в десятке файлов...

Для сравнения, в версии 2 достаточно было сделать копию feed.php - и готово, модифицируй как душе угодно. Если надо, еще для красивого адреса строчку в .htaccess добавить.

Может, я просто с модулями не освоился и какой способ попроще есть? Подскажите, кто знает...

zyxer M
zyxer M
Возраст: 28
Репутация: 27
Сообщения: 152
Зарегистрирован: 03.02.2016
С нами: 3 года 9 месяцев
Откуда: Днепр

Сообщение #2 zyxer » 23.10.2019, 10:19

то, что директория должна назваться как часть неймспейса, это прописано в стандарте PSR-4 https://github.com/codedokode/pasta/blob/master/php/autoload.md#psr-4. Действительно чтобы скопировать, нужно переименовать все неймспейсы во всех файлах модуля, PhpStornm с этим хорошо справляется, могут быть конечно нюансы, но в целом справляется.

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

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

P.S. что могу сказать наверняка, так это действительно с новым окаем нужно немного выйти из зоны комфорта, но мне кажется это не на долго.
P.P.S. Всё сказанное мной, является лично моим мнением, и не является официальной позицией OkayCMS ))

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

korshunov
korshunov
Репутация: 89
Сообщения: 1082
Зарегистрирован: 03.12.2015
С нами: 3 года 11 месяцев
Skype

Сообщение #3 korshunov » 24.10.2019, 05:57

zyxer писал(а):
мол, скопировал папку, и все заработало.
это не имелось ввиду дублирование модулей, а установка уже существующего модуля (и то, в конкретном модуле могут быть нюансы, это уже решает разработчик)
Вот и опять выходит, что модульность Ваша делалась в расчете на удобство разработчиков, а о конечных пользователях системы при этом особо не думали. Им лишь кинули косточку, себе не нужную - мол, обновляться будет легче. Да и та косточка отнюдь не деликатесная, а весьма сомнительная...

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

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

zyxer M
zyxer M
Возраст: 28
Репутация: 27
Сообщения: 152
Зарегистрирован: 03.02.2016
С нами: 3 года 9 месяцев
Откуда: Днепр

Сообщение #4 zyxer » 24.10.2019, 07:19

Вот и опять выходит, что модульность Ваша делалась в расчете на удобство разработчиков, а о конечных пользователях системы при этом особо не думали. Им лишь кинули косточку, себе не нужную - мол, обновляться будет легче. Да и та косточка отнюдь не деликатесная, а весьма сомнительная...
Вам бы книги писать, красиво пишите ))
Кто такой конечный пользователь системы? Это по сути менеджер магазина, который, по моему мнению, не должен разрабатывать модули (хотя и может это делать). Менеджер может установить модуль, сделанный разработчиком. Еще менеджер может сделать что-то по рекомендации разработчиков из форума, но здесь если менеджер вообще не знает азов программирования, я думаю будет сложно что-то пояснить (хотя при желании возможно).

А можете дать более-менее конкретные пояснения, с чего это поддержке "хромать" при модуле в одном файле и не "хромать" при разбросу на несколько файлов?
Простите, но здесь нет конкретного ответа, точнее любой конкретный ответ приведет к вопросу: "хорошо, а если здесь так..?". И это нормально. Но как пример можно попробовать посмотреть на интеграцию с 1С, ранее это был один файл написанный в процедурном стиле на ~1000 строк. Доступ к импорту осуществлялся через паттерн Page Controller, сейчас же вся система приведена (клиентская часть) к паттерну Front Controller (по нашему мнению так более правильно). Дальше, в контроллере 1С определяется фабрика импорта или экспорта, и далее эта фабрика создает нужный импорт или экспорт. Сами импорты уже лежат в отдельных файлах. Как видите, это не просто раскидали один файл на много, здесь применили паттерн Simple Factory, как мне кажется, оправданно. При том, поддерживать файл на 1000 строк, тяжело не только потому что нужно много скроллить...

И можете таки предоставить ТЗ, которое вам поставили. И мы может быть вместе подумаем как его лучше решить? Не потому что я считаю что вы не в состоянии его решить, а как рассмотреть типичное ТЗ

korshunov
korshunov
Репутация: 89
Сообщения: 1082
Зарегистрирован: 03.12.2015
С нами: 3 года 11 месяцев
Skype

Сообщение #5 korshunov » 24.10.2019, 10:32

zyxer писал(а):Кто такой конечный пользователь системы? Это по сути менеджер магазина, который, по моему мнению, не должен разрабатывать модули (хотя и может это делать). Менеджер может установить модуль, сделанный разработчиком. Еще менеджер может сделать что-то по рекомендации разработчиков из форума, но здесь если менеджер вообще не знает азов программирования, я думаю будет сложно что-то пояснить (хотя при желании возможно).

Опять Вы сбиваетесь на тоже самое. Если Вы разработчик тиражируемой CMS, то должны бы шире смотреть на вещи, ибо все пользователи РАЗНЫЕ. А разработчикам надо стараться давать им максимальную гибкость под их разные запросы. А Вы все на один лад "не должен", "вообще не знает азов". А из многих некоторые наверняка знают эти основы...

Вот, к примеру тема, где простенько расписано решение задачи:
viewtopic.php?f=10&t=1065
И воспользоваться им может даже тот, кто "вообще не знает азов".
Решение там для версии 2. И там же один из пользователей спросил, как сделать для версии 3. Месяц прошел, никто не ответил. Такое вот отношение разработчиков - нечего, мол, простым пользователям лезть, используйте те модули, которые Вам спецы соизволят дать, и будьте довольны. Вот Вы в своих все общие абстрактные вещи повторяете и повторяете, вместо этого на то вопрос бы ответили - лучше методом создания нового модуля - вот мы бы сравнили, что и насколько легче...


zyxer писал(а): При том, поддерживать файл на 1000 строк, тяжело не только потому что нужно много скроллить...
Это вопрос предпочтений разработчиков. Что легче поддерживать - разработку из одного файла 1000 строк или из десятка файлов суммарно на 2000 строк - вопрос спорный, и, скорее всего, индивидуальный для каждой разработки.

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

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

и на него совсем ничего по существу не сказали, а зачем-то в ответ расписываете построение текущего функционала.

zyxer писал(а):И можете таки предоставить ТЗ, которое вам поставили. И мы может быть вместе подумаем как его лучше решить? Не потому что я считаю что вы не в состоянии его решить, а как рассмотреть типичное ТЗ

Тот вопрос решен. В том ТЗ было довольно индивидуально, а не типично - добавить несколько тегов, в частности sales_notes, delivery-options, два вида цен. И вероятно, еще что-то будет менять заказчик...

zyxer M
zyxer M
Возраст: 28
Репутация: 27
Сообщения: 152
Зарегистрирован: 03.02.2016
С нами: 3 года 9 месяцев
Откуда: Днепр

Сообщение #6 zyxer » 24.10.2019, 11:48

Месяц прошел, никто не ответил. Такое вот отношение разработчиков - нечего, мол, простым пользователям лезть, используйте те модули, которые Вам спецы соизволят дать, и будьте довольны.
Прежде чем такое утверждать, убедитесь в правильности понимания ситуации...
Лично я ответил этому пользователю viewtopic.php?f=13&t=1423.

Но Вы уклонились в сторону от первонального вопроса
я вам ответил
Простите, но здесь нет конкретного ответа, точнее любой конкретный ответ приведет к вопросу: "хорошо, а если здесь так..?". И это нормально


Тот вопрос решен. В том ТЗ было довольно индивидуально, а не типично - добавить несколько тегов, в частности sales_notes, delivery-options, два вида цен. И вероятно, еще что-то будет менять заказчик...
но вот вы же разобрались...
И спрошу еще раз, вы ведёте в сторону ухода от модульности? Не пойму чем вам модульность не угодила? ))

korshunov
korshunov
Репутация: 89
Сообщения: 1082
Зарегистрирован: 03.12.2015
С нами: 3 года 11 месяцев
Skype

Сообщение #7 korshunov » 24.10.2019, 12:31

zyxer писал(а):
Месяц прошел, никто не ответил. Такое вот отношение разработчиков - нечего, мол, простым пользователям лезть, используйте те модули, которые Вам спецы соизволят дать, и будьте довольны.
Прежде чем такое утверждать, убедитесь в правильности понимания ситуации...
Лично я ответил этому пользователю viewtopic.php?f=13&t=1423.

Действительно, Вы ответили этому пользователю в ДРУГОЙ теме на этот же вопрос.
И дали решение в обычном стиле с модификацией текущих файлов.
А можете на этот же вопрос дать решение в виде отдельного модуля? Чтобы можно было сравнить решения и почувствовать преимущества модульности...

zyxer писал(а):И спрошу еще раз, вы ведёте в сторону ухода от модульности? Не пойму чем вам модульность не угодила?

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

И спрошу еще раз, на основе чего Вы сделали вывод:
zyxer писал(а):...слепить код в один более общий файл. Но тогда поддержка кода начинает храмать...

То, что Вы ранее ответили, не есть ответ, а полет безудержной фантазии...

zyxer M
zyxer M
Возраст: 28
Репутация: 27
Сообщения: 152
Зарегистрирован: 03.02.2016
С нами: 3 года 9 месяцев
Откуда: Днепр

Сообщение #8 zyxer » 30.10.2019, 12:45

думаю здесь нужно указать, что есть реализация реального функционала, который попросил пользователь на форуме viewtopic.php?f=9&t=1514 и там один и тот же функционал реализован для окая 2 и 3, где можно увидеть разницу. Изначально может казаться что разница не большая, но всё же, если модуль для третьего окая выложить в маркетплейс, его будет гораздо легче поддерживать чем аналогичный модуль для второго окая.

И спрошу еще раз, на основе чего Вы сделали вывод:
Я выше привел чёткий пример с реализацией интеграции с 1С в одном файле, и когда её части лежат в упорядоченных местах. Вам когда нужно изменить одну часть интеграции, если она в одном файле, вы вполне можете сломать другую (очень не явно), при разбивке же, вы редактируете один абсолютно конкретный функционал (часть интеграции) и очень врятли сломаете другую часть интеграции.

korshunov
korshunov
Репутация: 89
Сообщения: 1082
Зарегистрирован: 03.12.2015
С нами: 3 года 11 месяцев
Skype

Сообщение #9 korshunov » 30.10.2019, 19:17

zyxer писал(а):думаю здесь нужно указать, что есть реализация реального функционала, который попросил пользователь на форуме viewtopic.php?f=9&t=1514 и там один и тот же функционал реализован для окая 2 и 3, где можно увидеть разницу.

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

В Д2 одна коротенькая функция (в десяткок простых строк) с одним циклом, плюс 3 ее вызова. А в Д3 только первый фрагмент содержит три функции со сложным содержимым каждая. По моему, Д3 не просто сложнее Д2, а сложнее на порядок.

Вот написать человеческие объяснения для Д2 довольно легко. А сможете ли Вы написать объяснения для Д3, чтобы было легко и понятно?

zyxer писал(а):его будет гораздо легче поддерживать чем аналогичный модуль для второго окая.

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

Допустим, надо чуть переделать, для заказов в субботу и воскресенье стоимость доставки увеличить/уменьшить на %. По-моему, доработка практически одинакова для обоих случаев.
Если можете привести пример содержательный, подтверждающий Ваш тезис, буду рад.


zyxer писал(а):...когда нужно изменить одну часть интеграции, если она в одном файле, вы вполне можете сломать другую (очень не явно), при разбивке же, вы редактируете один абсолютно конкретный функционал (часть интеграции) и очень врятли сломаете другую часть интеграции.

Очень спорный тезис.

Это зависит от степени интеграции. Если она практически нулевая и не связана с другими частями (например, модуль для Розетки), то в такой ситуации это осмысленно. Но чаще встречаются другие ситуации, где слишком много взаимосвязано, чтобы можно было легко разложить на независимые части.
В данном конкретном случае, если написать с ошибкой Д3, то можно здорово подпортить ценообразование доставки, что для реального магазина может быть смерти подобно.

И наконец, возьмем для примера Вашу разработку Д3. Там есть
use Okay\Modules\OkayCMS\NovaposhtaCost\Extenders\FrontExtender;
Мелкая ошибочка, особо не проявится, но все же ошибка.
А вот в Д2 у Вас ошибок не видно.
На практике все наоборот, чем в Вашей теории...

zyxer M
zyxer M
Возраст: 28
Репутация: 27
Сообщения: 152
Зарегистрирован: 03.02.2016
С нами: 3 года 9 месяцев
Откуда: Днепр

Сообщение #10 zyxer » 31.10.2019, 09:11

хитросплетениях Ваших довольно сложных и многочисленных классов.
о каких конкретно классах идёт речь?

В Д2 одна коротенькая функция (в десяткок простых строк) с одним циклом, плюс 3 ее вызова. А в Д3 только первый фрагмент содержит три функции со сложным содержимым каждая. По моему, Д3 не просто сложнее Д2, а сложнее на порядок.
Давайте попробуем разобраться. Я так понимаю речь идет о классе FrontExtender. Там свойство $deliveryPrices и метод getDeliveryPrice() вообще 100% аналоги доработки для второго окая.
Метод getCartDeliveriesList() он внутри себя создает экземпляр класса ServiceLocator() (что очевидно), также я думаю не нужно пояснять что такое локатор служб. затем мы из локатора достаём сервисы, которые нам нужны

Код: Выделить всё

/** @var FrontTranslations $frontTranslations */
$frontTranslations = $SL->getService(FrontTranslations::class);

/** @var EntityFactory $entityFactory */
$entityFactory = $SL->getService(EntityFactory::class);

/** @var Money $money */
$money = $SL->getService(Money::class);

По сути ранее это же делалось через $this->front_translation->getTranslation(). Но как минимум такой код морально устарел (не буду вдаваться в детали чего отказались от класса Okay и перешли на DI контейнер).

В переменной $entityFactory лежит экземпляр класса фабрики сущностей, далее мы получаем экземпляр класса Okay\Entities\CurrenciesEntity и далее уже вызываем метод get() этого экземпляра. Ранее это было как $this->currencies->get_currency((int)$_SESSION['currency_id']);
сейчас

Код: Выделить всё

$currenciesEntity = $entityFactory->get(CurrenciesEntity::class);
$currency = $currenciesEntity->get((int)$_SESSION['currency_id']);

на целую строчку сложнее. Если очень принципиально, напишите

Код: Выделить всё

$currency = $entityFactory->get(CurrenciesEntity::class)->get((int)$_SESSION['currency_id']);
то же самое, но не так читаемо.

Классы Money и CurrenciesEntity нужны для того, чтобы в $delivery->delivery_price_text можно было добавить стоимость доставки, которая выводится здесь http://prntscr.com/pqiq5x, связанно это уже с переработкой самой корзины в третьем окае. Далее мы в форыче модифицируем стоимость доставки и отдаём её. Далее вопрос, когда вызывается метод getCartDeliveriesList()? в классе Init прописана регистрация цепочного вызова метода FrontExtender::getCartDeliveriesList() после метода DeliveriesHelper::getCartDeliveriesList(). Собственно метод DeliveriesHelper::getCartDeliveriesList() возвращает массив доставок, а в метод DeliveriesHelper::getCartDeliveriesList() они попадают на вход как аргумент, и метод их модифицирует описанным выше образом и возвращает. Таким образом модули в принципе могут работать с системой.

zyxer писал(а):
его будет гораздо легче поддерживать чем аналогичный модуль для второго окая.

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

Буду выражать только своё мнение )) легче это тем, что код всего модуля собран в одном месте, мне не нужно править его по всей системе, я точно знаю что нигде не забуду отметить код комментарием (как это делалось для второго окая), потому как мой код не находится в ядре. Да, эта доработка попала в те места, которые приктически не менялись с 2.0.0, но допустим бы мы вставляли свой код между строк, которые правились в окае, вам нужно обязательно обновлять свой модуль, т.к. пользователи не смогут его ставить (как я уже говорил, все ориентируются по соседним строкам). В случае с 3, такой проблемы быть не должно.

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

И наконец, возьмем для примера Вашу разработку Д3. Там есть
use Okay\Modules\OkayCMS\NovaposhtaCost\Extenders\FrontExtender;
Мелкая ошибочка, особо не проявится, но все же ошибка.
да, писал на коленке в обед, и не обратил внимания )) Спасибо за замечание. Тот файл на самом деле вообще не нужен.

Так же вы как разработчик модуля вполне можете покрывать его автотестами, чего ранее нельзя было сделать при всём желании.
Еще, я чтобы не усложнять код для 3 сделал методы getCartDeliveriesList и getDeliveryPrice в одном классе, но они должны быть в разных классах. Один это часть приложения, второй это часть бизнес-логики.


Название раздела: Вопросы по работе с OkayCMS
Правила раздела: faq.php?mode=okay

Быстрый ответ


Введите код в точности так, как вы его видите. Регистр символов не имеет значения.
Код подтверждения

   

Вернуться в «Вопросы по работе с OkayCMS»

Кто сейчас на форуме (по активности за 5 минут)

Сейчас этот раздел просматривают: 1 гость