Мне больше нравится как оно звучит на английском языке, лучше передает суть — boilerplate code.
Да, именно такого кода, который программист обычно copy-paste-ит мы хотим избегать.
Немного смешно звучит учитывая что при создании модуля мы постоянно делаем рутинные действия, например создание модели, с ресурс моделью и коллекцией.
Magento по-факту сама вставит вам кастомизированную зависимость в Child, если кто-то кастомизировал ее для Parent, а для Child она не переопределена. Вам для этого не нужно ничего указывать.
А это в каком случае? В случае использования Context? В случаях в preference или в случаях virtual types?
Декларацию parent, как в Symfony мы также хотим избегать, во-первых, по причине описанной выше, а во-вторых, потому что Magento не рекомендует использовать Inheritance Based API, т.е. расширение путем наследования в целом. Мадженто для этого предоставляет достатоно других механизмов взамен. И рекомендованным путем является композиция объектов.
Ну для начала parent в Symfony это не более чем механизм который позволяет избавится от дублирующего кода, так же как динамическое создание формы минуя создание класса. Ну и потом, звучит немного странно на фоне того, что при создании модуля мы все так же наследуем базовые классы(раз, два, три, четыре, пять, шесть), при том что ничего плохого в наследовании нет, поскольку композиция не всегда является гибким решением.
Но Magento — это Open Source проект, об этом была моя первая презентация, видео которой тут выложено. Поэтому если Вы видите как Вы можете что-то улучшить в коде или в документации, Вы можете поставить Pull Request, и если он соответствует нашим требованиям, то мы его обязательно приймем, а если не соответсвует, но идея покажется нам полезной — поможем доработать его до вида, чтобы влить его в мейнлайн.
Это касается и автоматического отслеживания изменений и тегов @ see, которые мы пока не бекпортировали в 2.1.*
Я ждал несто подобное) Увы, пока есть куча работы основной, но как только выдастся минутка обязательно внесу свой вклад. И раз пошла такая петрушка, куда я могу оформить баг, при котором админка мадженты уходит в цыклический редирект?
мы сделали auto-injection в DI, в отличие от Symfony опять же, чтобы избавить программиста от написания шаблонного кода.
Интересно, шаблонный код это явно указание зависимости, например, в yml?
И чтобы он конфигурировал, только то, что ему нужно конфигурировать. А не все зависимости класса.
В симфони для этого существует parent, который избавляет от внедрения всех зависимостей, а так же повторного вызова методов необходимых для создания класса.
когда пишешь код в режиме Develop (а именно в этом режиме обычно пишут код программисты) нет надобности перегенеривать после любых изменений все код-генерированные сущности.
Достатчоно удалить, только нужные файлы, которые были изменены. И система пересоздаст только их. Не нужно удалять всю папку 'generated' при этом. Это не должно занять много времени.
Вероятно сейчас после каждых изменений Вы запускаете DI компиляцию всего. Этого делать не нужно
Хорошо, допустим. Почему тогда это нигде не отражено в офф документации? Почему об этом нигде не написанно в той же офф документации? И почему бы не реализовать механизм автоматического отслеживания измененых файлов что бы перегенерировать только измененные код-герерированые сущности? Или как с методами save и load в модели. @deprecated есть, а see нет. И ищи информацию по форумам))) Хорошо что хоть описание в последнюю версию добавили.
3. Не совсем понятен вопрос. Тоесть таки нарушаем но чуть чуть? Это как? Вы проде бы и согласны что построение зависимости на основе реализации, а не на основе абстракций это нарушение принципа OCP, но вроде бы и не согласны. Более того я говорю о том что иногда мы можем отходить от следования данного принципа, но все таки это будет отхождение а не «вопиющее» или не «вопиющие» нарушение. Вопрос в том оправдано ли оно. Если мы знаем что мы никогда не будем менять зависимость, то возможно нам и не нужно создавать зависимость на абстракции. Но в случае Magento 2, когда нам предоставлен механизм указания нужной реализации, я считаю, что все таки стоит избегать таких случаев. Где вычитал — Agile Principles, Patterns, and Practices in C# By Martin C. Robert, Martin Micah (http://druss.co/wp-content/uploads/2013/10/Agile-Principles-Patterns-and-Practices-in-C.pdf).
Да в принципе в другой ветке был дан ответ на вопрос по поводу нарушения solid. Magento2 представляет механизм несовсем указания. Посути это просто механизм подмены интерфейса или конкретного класса, поскольку можно написать
Принцип Лисков в первую очередь говорит о том, что Наследование это очень сложное отношение между объектами, которое добавляет большой coupling, и многие его используют не правильно. Большинство использует его только чтобы избавиться от дублирования кода. Но для наследования должно еще выполняться отношение is_a (является).
То что докладчик выбрал механизм консольных команд представленный в Magento 2 (которые действительно расширяют Symfony\Component\Console\Command\Command) не есть проблемой.
В данном примере, новая команда чистит кеш, но при этом отношение is_a по отношению к родительской команде соблюдается.
Спасибо за ответ. Пересмотрел класс родитель, да, если прочитать Ваш ответ, так и есть.
Класс это тоже интерфейс, точней два интерфейса — один открытый, второй защищенный. Поэтому зависимость на конкретный класс, в месте, которое предполагает расширение в будущем — это плохо, так как программист, который захочет расширить базовое поведение, будет вынужден наследоваться от вашего класса. А это не правильно, так как с высокой долей вероятности вы нарушите принцип Лисков
Да, но докладчик говорит о нарушении ссылаясь на «конкретную реализации», т.е. ссылаясь на предыдущий пункт Dependency Inversion. И из-за этого складывается ощущение что он сам слабо понимает о чем говорит.
Вы про код генерацию в принципе или про что-то конкретное Interceptor, Factory, Proxy?
Мы используем код генерацию там, где считаем она избавит программиста от написания шаблонного кода (boilerplate code).
Например, логика Factory и Proxy в шаблонном случае одинакова — поэтому мы кодгенерим классы просто когда программист указывает нужный суфикс (Factory или Proxy) добавляя его к имени сущности, которую он хочет создать.
в случае интерсептеров мы также избавляем программиста от написания шаблонного кода. А меньше кода — меньше возможностей допустить ошибку.
Да именно про это. Ок, допустим. Но теперь времяна разработку увеличилось, за счет того что при добавлении новой зависимости в класс, например кастомной CollectionFactory(и кстати это не очевидно, поскольку на момент добавления зависимости класс еще не сгенерирован), нужно заново перегенирировать код. У меня на ноуте(i3, 8GB Ram, 512 SSD) на перегенерацию кода на чистой мадженте с одним катсомным модулем уходит 4 минуты! И при том, я так понимаю, про механизм отслеживания изменений и перегенерацию только необходимого никто не задумывался и реализовывать не будет?
В Magento 2 используется концепт Service Layer, и API находятся в папках каждого модуля. На эти API мапятся Web API. Например, здесь можно почитать как API добавлялись для одного из модулей.
Я не понял какая именно магия имеется в виду.
Я прошу прощения, если ввел в заблуждение. Когда я говрил сервис, я имел ввиду описание создание класса для DI Container как это наприммер сделано в symfony, пример 1, пример 2
Пользуясь случаем. раз мне ответил сам Magento 2 Architect(если верить описанию), хочу задать пару вопросов.
Почему в magento2 была выбрана стратегия кодогенерации?
Почему в magento2 не сделали явное описание создания сервисов, как например в symfony? Зачем нужна эта магия?
Вопрос не в том сложно их было назвать unit или нет. Вопрос в том, что докладчик утверждает что unit тесты отстутствуют в M1(наверное потому что не шли с под коробки), а это как минимум не совсем корректно. Опять же наскидку про unit tests упоминается на Inchoo и на Atwix
Обратите еще внимание, что класс Mage был объявлен как final
https://github.com/engineyard/magento-ce-1.9/blob/master/app/Mage.php
Про unit тестирование https://youtu.be/FquSm_LOmS4?t=1304
Никто не запрещал в M1 писать юнит тесты(вот на вскидку пример подключения ), другое дело что в большинстве случаев заказчик не оплачивал тесты и их не писали. Да, DI, SOLID помогает в написание тестов, но это не одначает что из-за этого в M1 их небыло.
Про нарушение принципов SOLID https://youtu.be/FquSm_LOmS4?t=1344
Мне интересно где это вычитал докладчик? В какой конкретно статье или литературе? Или он только ссылается на Mаgento? Да, использовать в construct в качестве тайп хинта конкретный класс вместо интерфейса не привествуется, но и не описывается как вопиющее нарушение принципа. А если нам в конкретной реализации класса нужно будет внедрить несколько хелперов и сторонний класс которые не имеют интерфейсов?
Часть Битрикса теперь официально именуется Bitrix Framework
Ну именовать они могут как угодно, но это не означает что так и есть.
Никто не запрещает не использовать админку Битрикса, не использовать никакие штатные компонента Битрикса и использовать Битрикс только в качестве фреймворка.
Ну во первых это не тоже самое, с тем что я приводил для примера с symfony components. Во вторых, мне страшно представить, что будет если брать их сборник низкокачественного кода и что-то на нем делать.
Если битрикс — фреймверк, то где я могу найти описание как я могу использовать его компоненты в других проектах(не битрикс)? Вот например в symfony это реализовано так http://symfony.com/components
Если бы разработчики битрикса использовали нормальную архитектуру, то это бы позволило внедрить TDD который бы еще на этапе разработки исключал 85% — 95% багов и брешей безопасности. А данный костыль в виде «авто-тесты кода» не более чем «подорожник» который просто не способен качественно обработать кучи строк низкокачественного кода самого битрикса.
Нет там связей, ни одного foreign key во всем дампе. Со связями конечно все проще, никто и не спорит.
Речь шла об одном конкретном продукте.
Смотрите. Вот еще один трюк как можно получить готовый sql запрос и не лезть в код движка. Включаем логирование SQL запросов, и находим нужный. Вот уже второй способ. И этот способ работает для любого продукта.
Нет желания играть в телепатию, извините.
Но как же так? Вы же так яро пытаетесь доказать, что я заблуждаюсь давая оптимистичные оценки. Это видно по данным фразам:
Посмотрите, сколько у вас уйдет времени и других ресурсов.
и
Вы сказали «не думаю что сильно много». Я предложил вам не гадать, а попробовать.
Видимо, вам очень нравится теоретизировать. Мне теперь тоже начинает казаться, что вы живете в стране розовых пони. Потому что EAV, и основных таблиц у вас всего 2 — iblock_element и iblock_element_property. В них, кроме товаров, могут храниться еще и новости, например. К ним сбоку приделывается catalog_price, и поверх всего этого навешивается система скидок. Чтобы понять, в каком порядке и по какому условию надо джойнить iblock_element_property с iblock_element_property, надо залезть в код.
Ну не Вам мне, как человеку который очень долго работает с Magento, рассказывать про EAV. Еще раз, я привел вполне конкретный пример(кстати из реальной задачи), с вполне конкретными данными. Я вижу все таблицы и связи между ними. Зачем мне лезть в код, если все связи, индексы и таблицы, а так же данные для сравнения у меня на виду? И это кстати, один из способов переноса данных.
могут храниться еще и новости, например
Как это мне мешает получить нужные мне данные по продукту?
Мир шире, чем вам кажется.
Сказал мне человек который доказывает, что что бы понять как спарсить данные с БД обязательно нужно лезть в код движка.
P.S. Я вот кстати знаю в каком случае придется лезть в код. Интересно догадаетесь ли Вы, что это за место и что делать если нет доступа к данной логике.
Я не буду отвечать на всю простыню. Надоело писать одно и тоже.
Нисколько, речь не об этом. Вы сказали «не думаю что сильно много». Я предложил вам не гадать, а попробовать. Также вы сказали, что «Перенести данные» и «Разрабатывать на битриксе» немного разные понятия. Это не так, и чтобы разобраться, как правильно перенести данные, вам надо разобраться в логике работы битрикса, то есть какое-то время с ним поработать. Это не означает, что надо обязательно писать новый код, но надо разобраться в старом. В общем-то, это справедливо для любой сложной системы, но весь вопрос в коэффициентах.
B так. Задача перенести данный с одной абстрактной системы А в другую системы Б имея только дамп базы. Возьмем пример продуктов. Допустим у продуктов должна быть цена, артикул, атрибуты, количество, картинки, и статус. И так захожу на сайт и беру первый попавшийся продукт, нахожу его по артикулу, смотрю связи таблицы нахожу остальные данные, пишу SQL запрос который вытащит все необходимое мне поля, и допустим запишу в csv файл для дальнейшего импорта. Теперь внимание вопрос. Зачем нужно лезть в код?
Эхх, и так всегда. Диалог начинается с одного, а заканчивается отнекиванием.
Достаточно просто не работать с такими заказчиками, которые за разработчиков решают на чем строить систему
Ну да ладно, это частое явление на хабре )
Не работать с некоторыми заказчиками === ставить им условия? Прям так радикально? Ну ок, пусть будет так.
Видимо написать «Ответ на этот вопрос я написал ранее» вам проще, чем «Да» или «Нет» ) Чтож, вам счастливого дня. На этом наш диалог можно заканчивать.
Видимо Вы осознал что больше нечем поживиться и решили ретироваться. Правильное решени. И Вам хорошего дня.
Вы были одним из тех людей, кто занимался наймом сотрудников?
Не просто занимался, а еще и собеседовал.
Ну судя по вашим ответам, нужно поставить условие заказчику и отказаться от него, если он с этими условиями не соглашается. Разве нет?
Нужно меньше строить всяких домыслов. Я лишь описал вариант общения. И опять же, поскольку я общаюсь с троллем, напоминаю, что я предложил вариант решения как уйти от работы с битриксом, не более. А потом уже мне тут начали рассказывать свой неудачный опыт поиска работ и рабскую жизнь, доказывая что так везде и вся.
Человек правильно вам говорит. Если вы с этим не сталкивались, это не значит, что этого нет.
Нет чего?
Ок, часть джуниоров попала к этой части работодателей. Что делать остальным? А еще, представьте себе, бывает так, что нет денег на переезд в другой город. Как их заработать? Правильно, выполняя такую работу, которую готовы доверить джуниору без опыта.
Я привел пример как можно переехат в другой город работая на фрилансе. Не могу понять, что мешает остальным повышать скилл и продолжать мониторить крупные компании? Ну и пусть выполняет. Я не могу понять где опровержение сказанного мной.
Вот вы и признались, что у вас нет опыта в поиске работы. Вы искали работу всего 2 недели, а в следующий раз вы были уже не джуниор.
И что? 2 недели не поиск? Или всю жизнь быть джуном и постоянно нужно искать работу и выполнять самые каловые поручения за еду? Хотя если так, то да. Все будет печально и будут рассказы про «реалии рынка» и «пони»
а в следующий раз вы были уже не джуниор.
Можно три года проработать с ZF/Symfony, а потом взяться за мадженту и первое время не понимать как сделать ту или иную задачу, которая на фреймверке давалась легко. И стать джуниорам при работе с маджентой. Случаи не единичный.
Поставьте себе демо-версию битрикса и попробуйте вынести все сущности, связанные с товарами, в отдельные таблицы. С сохранением ценообразования и прочими необходимыми финтифлюшками. Посмотрите, сколько у вас уйдет времени и других ресурсов.
Опять абстрактная постановка задачи. От трех дней. А сколько по вашему? Мне интересно послушать. А какими инструментами пользовались при переносе данных из одной базы в другую? А с какими трудностями предстоит столкнуться? Мне интересно послушать про ваш опыт переноса данных.
Немного смешно звучит учитывая что при создании модуля мы постоянно делаем рутинные действия, например создание модели, с ресурс моделью и коллекцией.
А это в каком случае? В случае использования Context? В случаях в preference или в случаях virtual types?
Ну для начала parent в Symfony это не более чем механизм который позволяет избавится от дублирующего кода, так же как динамическое создание формы минуя создание класса. Ну и потом, звучит немного странно на фоне того, что при создании модуля мы все так же наследуем базовые классы(раз, два, три, четыре, пять, шесть), при том что ничего плохого в наследовании нет, поскольку композиция не всегда является гибким решением.
Я ждал несто подобное) Увы, пока есть куча работы основной, но как только выдастся минутка обязательно внесу свой вклад. И раз пошла такая петрушка, куда я могу оформить баг, при котором админка мадженты уходит в цыклический редирект?
Интересно, шаблонный код это явно указание зависимости, например, в yml?
В симфони для этого существует parent, который избавляет от внедрения всех зависимостей, а так же повторного вызова методов необходимых для создания класса.
Хорошо, допустим. Почему тогда это нигде не отражено в офф документации? Почему об этом нигде не написанно в той же офф документации? И почему бы не реализовать механизм автоматического отслеживания измененых файлов что бы перегенерировать только измененные код-герерированые сущности? Или как с методами save и load в модели. @deprecated есть, а see нет. И ищи информацию по форумам))) Хорошо что хоть описание в последнюю версию добавили.
Да в принципе в другой ветке был дан ответ на вопрос по поводу нарушения solid. Magento2 представляет механизм несовсем указания. Посути это просто механизм подмены интерфейса или конкретного класса, поскольку можно написать
preference for="Magento\Framework\Logger\Monolog" type="Coolryan\PreferenceExample\Model\Log"
И спокойно подменить логер.
В любом случае спасибо за ответ.
Спасибо за ответ. Пересмотрел класс родитель, да, если прочитать Ваш ответ, так и есть.
Да, но докладчик говорит о нарушении ссылаясь на «конкретную реализации», т.е. ссылаясь на предыдущий пункт Dependency Inversion. И из-за этого складывается ощущение что он сам слабо понимает о чем говорит.
Да именно про это. Ок, допустим. Но теперь времяна разработку увеличилось, за счет того что при добавлении новой зависимости в класс, например кастомной CollectionFactory(и кстати это не очевидно, поскольку на момент добавления зависимости класс еще не сгенерирован), нужно заново перегенирировать код. У меня на ноуте(i3, 8GB Ram, 512 SSD) на перегенерацию кода на чистой мадженте с одним катсомным модулем уходит 4 минуты! И при том, я так понимаю, про механизм отслеживания изменений и перегенерацию только необходимого никто не задумывался и реализовывать не будет?
Я прошу прощения, если ввел в заблуждение. Когда я говрил сервис, я имел ввиду описание создание класса для DI Container как это наприммер сделано в symfony, пример 1, пример 2
Почему в magento2 была выбрана стратегия кодогенерации?
Почему в magento2 не сделали явное описание создания сервисов, как например в symfony? Зачем нужна эта магия?
Ну если сильно извратится то можно мокнуть и финальный класс , но изврат еще тот, так что согласен.
Чисто ради интереса, понимает ли докладчик, что показывает прмер использования Symfony Console Component и почему он считает что именно это пример принципа подстановки Барбары Лисков?
Про unit тестирование https://youtu.be/FquSm_LOmS4?t=1304
Никто не запрещал в M1 писать юнит тесты(вот на вскидку пример подключения ), другое дело что в большинстве случаев заказчик не оплачивал тесты и их не писали. Да, DI, SOLID помогает в написание тестов, но это не одначает что из-за этого в M1 их небыло.
Про нарушение принципов SOLID https://youtu.be/FquSm_LOmS4?t=1344
Мне интересно где это вычитал докладчик? В какой конкретно статье или литературе? Или он только ссылается на Mаgento? Да, использовать в construct в качестве тайп хинта конкретный класс вместо интерфейса не привествуется, но и не описывается как вопиющее нарушение принципа. А если нам в конкретной реализации класса нужно будет внедрить несколько хелперов и сторонний класс которые не имеют интерфейсов?
Ну именовать они могут как угодно, но это не означает что так и есть.
Ну во первых это не тоже самое, с тем что я приводил для примера с symfony components. Во вторых, мне страшно представить, что будет если брать их сборник низкокачественного кода и что-то на нем делать.
Смотрите. Вот еще один трюк как можно получить готовый sql запрос и не лезть в код движка. Включаем логирование SQL запросов, и находим нужный. Вот уже второй способ. И этот способ работает для любого продукта.
Но как же так? Вы же так яро пытаетесь доказать, что я заблуждаюсь давая оптимистичные оценки. Это видно по данным фразам:
и
А сами оказывается не компетентны в вопросе?
Ну не Вам мне, как человеку который очень долго работает с Magento, рассказывать про EAV. Еще раз, я привел вполне конкретный пример(кстати из реальной задачи), с вполне конкретными данными. Я вижу все таблицы и связи между ними. Зачем мне лезть в код, если все связи, индексы и таблицы, а так же данные для сравнения у меня на виду? И это кстати, один из способов переноса данных.
Как это мне мешает получить нужные мне данные по продукту?
Сказал мне человек который доказывает, что что бы понять как спарсить данные с БД обязательно нужно лезть в код движка.
P.S. Я вот кстати знаю в каком случае придется лезть в код. Интересно догадаетесь ли Вы, что это за место и что делать если нет доступа к данной логике.
B так. Задача перенести данный с одной абстрактной системы А в другую системы Б имея только дамп базы. Возьмем пример продуктов. Допустим у продуктов должна быть цена, артикул, атрибуты, количество, картинки, и статус. И так захожу на сайт и беру первый попавшийся продукт, нахожу его по артикулу, смотрю связи таблицы нахожу остальные данные, пишу SQL запрос который вытащит все необходимое мне поля, и допустим запишу в csv файл для дальнейшего импорта. Теперь внимание вопрос. Зачем нужно лезть в код?
Да
Не работать с некоторыми заказчиками === ставить им условия? Прям так радикально? Ну ок, пусть будет так.
Видимо Вы осознал что больше нечем поживиться и решили ретироваться. Правильное решени. И Вам хорошего дня.
Не просто занимался, а еще и собеседовал.
Нужно меньше строить всяких домыслов. Я лишь описал вариант общения. И опять же, поскольку я общаюсь с троллем, напоминаю, что я предложил вариант решения как уйти от работы с битриксом, не более. А потом уже мне тут начали рассказывать свой неудачный опыт поиска работ и рабскую жизнь, доказывая что так везде и вся.
Ответ на этот вопрос я написал ранее.
Нет чего?
Я привел пример как можно переехат в другой город работая на фрилансе. Не могу понять, что мешает остальным повышать скилл и продолжать мониторить крупные компании? Ну и пусть выполняет. Я не могу понять где опровержение сказанного мной.
И что? 2 недели не поиск? Или всю жизнь быть джуном и постоянно нужно искать работу и выполнять самые каловые поручения за еду? Хотя если так, то да. Все будет печально и будут рассказы про «реалии рынка» и «пони»
Можно три года проработать с ZF/Symfony, а потом взяться за мадженту и первое время не понимать как сделать ту или иную задачу, которая на фреймверке давалась легко. И стать джуниорам при работе с маджентой. Случаи не единичный.
Опять абстрактная постановка задачи. От трех дней. А сколько по вашему? Мне интересно послушать. А какими инструментами пользовались при переносе данных из одной базы в другую? А с какими трудностями предстоит столкнуться? Мне интересно послушать про ваш опыт переноса данных.