Как по мне - идея неплохая в своей сути. Можно конечно подескутировать относительно того не создание ли это очередного велосипеда, но от себя вижу вполне полезную нишу: обмен запросами с аналитиками BI - там может приятно лечь на общий pipeline проекта или по крайней мере упростить этот обмен.
Но есть три "no":)
Я бы порекомендовал где возможность сделать runtime компиляцию без необходимости вызывать команду каждый раз. Что-то вроде простенького nOrm.actualize(). Где в рантайм не получится - набрать готовых встроек на этап компиляции.
Учитывая сколько проектов УЖЕ на ORM, неплохо бы подсластить пелюлю и добавить коннекторы на основные ORMки языков, чтобы итоговый результат запроса аккуратно упаковывался в уже сущесвующие типы объектов строк или коллекций. Тогда выше шанс, что на nORM обратят внимание.
Скажу немного крамольную фразу для Хабра, но: "В эпоху ИИ ценность утилиты уже не столь очевидна". Я бы порекомендовал развивать ее во что-то более комплексное, но направление дать не решусь. Оставлю на ваших плечах.
Вот 3 моих маленьких совета. Надеюсь они вам помогут, даже если будут отброшены)
Радует что хоть кто-то стал говорить об этой теме вслух и с пониманием на Хабре.
ИИшка хороший и мощный инструмент. Но как и водиться - каждый инструмент с нюансами. ИИ не волшебная палочка, в текущем виде это как тупенький, но очень упорный Джун под энергетиками. Все что можно дать такому Джуну - можно дать и ИИшке.
Но как и в случае с Джуном:
Не доверяй и не надейся на лучшее - только проверка и прослеживание логики
Сверяйся с условиями задачи и что реально было сделано
Базовые предельный и критические сценарии
Дай другой ИИшке сочинить тесты. Другой, которая НЕ ВИДИТ Код и не может подстроиться под него. (один Джун пишет код, другой тесты к нему)
Меняй модели, ставь условия по-другому и тп и тд
И если соблюдать хотя бы стандартные правила - выигрыш будет точно такой же как от разрабов в подчинении Лида.
Отмечу только, что скепсис по отношению к нейросетям не разляю. Если за компьютерои сидит именно специалист - скорость работы увеличивается, так как ИИ на себя берет банальную рутину или играет роль гугла.
Бойлерплейты, модели бд, конекторы и прочее, что не требует ума и что может сделать ИИ.
Но все время не покидала меня мысль.... Что вы обманули клиента и при правильных формулировках - может даже в суд на вас подать.... Возможно даже выиграв.
Очень не хватало материала о мета-навыках и очень приятно видеть его на Хабре)
Думаю вам стоит так же написать материал не о внешнем взаимодействии с людьми, а о внутреннем самоуправлении, включая дисциплину логику, как один из внутренних фильтров.
Очень понравилась идея из Челпановского учебника логики: "Наука логики не о том как мыслить правильно, а о том - как найти ошибки в мышлении"
Дам пару комментариев к вашему комментарию:) За оформление прошу прощения, привык писать заметки и прочее в Obsidian, так что оформляю как .md файлы.
>> Открыл навскидку пару интернет-магазинов на битриксе, зашёл в публичной части в раздел каталога, "отладка" -> "суммарная статистика", "сбросить кэш" и смотрим:один - 1819 запросов,другой - 1999 запросов."Криво" для Битрикса - это когда тут счёт идёт на десятки тысяч :)
За интернет магазины не могу не подтвердить, не опровергнуть, так как(говорил в изначальном комментарии) - не работал с ними. Только корпоративные порталы и иногда мелкие доработки/анализ магазинов, но не более.
Свои аргументы в первую очередь направляю в сторону Битрикс24. Корпоративный портал. Однако, учитывая популярность для магазинов(есть пара клиентов у нас), сложно поверить что в стандартной реализации магазина такой бардак. Зная ядро и его возможности - запросы в цикле нередко решаются передачей в копоненты уже готовы данных "одиночного" большего запроса. А не вызовом в каждой компоненте новой строки из БД. Если такое действительно в стандартных решениях или в решениях от золотых партнеров - мне правда их очень жаль :(. В корпоративной портале 200+ запросов - это действительно максимум, который видел на стандартных компонентах. Не говоря уже о том, что многое переписывается на реактивные компоненты, которые вместо каскадной отрисовки вложенных компонентов - просто обращаются в 2-3 запроса на бек и получают все необходимое без вложенных костылей.
>> Вот только коробочный код в не возвращает экземпляры сущностей, связанных \Bitrix\Iblock\Elements\Element{*код*}Table . Он вернёт вам экземпляр сущности, связанной с \Bitrix\Iblock\IblockElementTable , а там как раз обозначенная автором статьи проблема в наличии. И лично я с этим сталкивался, хотя сейчас не вспомню, как именно.
Тут, к сожалению, не совсем понял о чем речь, так как каждый Инфоблок имеет свой Динамически-сгенерированный класс-модель. Простой пример, только что выполнил на портале: $dataClass = Iblock::wakeUp(iblockId)->getEntityDataClass(); В итоге получился следующий класс: \Bitrix\Iblock\Elements\ElementCashExpenseTable
И если будут reference - то спокойно понятно что за модель/инфоблок. Возможно вы имели ввиду что-то иное, но ответил как смог, прошу не кидаться излишне помидорам)
>> Пример менее сложной задачи от заказчика ( лично я не готов назвать её простой): запустили интернет-магазин, всё отлично. Теперь нужно ровно то же самое, но на белорусском. В Битриксе есть многосайтовость, так что за отдельную лицензию мне платить не надо. И каталог, разумеется, должен быть один; там всего-то добавить название товара на белорусском и описание. Это же недолго, да? А потом ещё казахский сайт запустим!
Хотя мы этим редко пользуемся(просто нет многоязычности на корпоративных порталах, зачастую), но справедливости ради отмечу - что есть lang-файлы, которые легко превращают сайт, портал или что-либо еще в многоязычный сайт. Единственный вопрос - это содержимое сайта, вроде названия товаров, статьей и прочего. Но тут я бы мог предложить "вытащить" все текстовые данные из Битрикса, запомнить связку, скормить какой-нибудь нейронке(для качества), чтобы она перевела это на нужный язык и сохранить "содержимое" как альтернативу. А потом просто все новые товары/статьи вести уже на всех поддерживаемых языках или сразу доработать редактор так, чтобы он автоматом все новое кормил на перевод всех поддреживаемых языков. Примеров привести не могу, но за пару минут в голову приходит такое решение и не похоже(по крайней мере у меня в голове) - что тут что-то ломается.
>> Слишком вольно обобщаете. Мой опыт говорит так: порой нужное решение не вписывается в рамки Битрикса на считанные проценты, но именно это ставит крест на использовании того, что вписалось.
Будет похоже, словно я придираюсь к словам, но если решение не вписалось на "считанные проценты" - это победа) Значит вам вместо 100% надо выполнит оставшиеся проценты. Как минимум сделать варварское решение и просто форкнуть нужный функционал, вынести в отдельный модуль и доработать под себя несостыковки.
У нас с вами разный опыт, да и спорить тут "кто прав, а кто нет" - сложно, так как потребовало бы выйти за пределы комментирования к небольшому рабочему исследованию, но в противовсе скажу свой опыт, повторив за собой из первого комментария: "Когда нас просят о чем-то новом, первое что мы делаем - это ищем то, что уже реализовано в Битриксе и просто дорабатываем под свою задачу. В 90% случаев это работает и половина всей разработки смещается в применение уже готового, а оставшееся - в реальную разработку. И что тут хорошо для пользователя - выглядит для них это всегда знакомо. Многое можно провести либо как бизнес-процесс, либо как задачу, либо CRM-сущности(Сделки, Лиды, Смарт-процессы) и со всем этим работники портала уже знакомы и не теряются, когда эта часть просто обрастает новыми возможностями. И это действительно помогает как ускорить разработку, так и адаптацию сотрудников к "новому".
>> Как говорится, "вы или крестик снимите, или трусы наденьте". Значительная часть хейта в сторону Битрикса как раз из-за того, что в ядре что-то криво, а допустимые лицензией способы решения - это прорва работы. Если я из-за бага в ядре не могу это ядро использовать, зачем мне вообще эта система? Есть фреймворки; админка в них генерируется с помощью готовых утилит и кастомизируется при необходимости. Если вы решили посвятить себя разработке сайтов, и планируете хотя бы в среднесрочной (3-5 лет) перспективе, то лучше вкладываться не в Битрикс."Здесь и сейчас как-нибудь запуститься, лишь бы работало" - Битрикс для этого вполне годится, ибо коробка. Но таких "коробок" уже немало, кому-то и Тильда подойдёт.
Конечно немного задевает, что был использован пример с трусами и крестиком, но буду считать это вашей манерой без личночных нападок)
Относительно "НЕЛЬЗЯ ТРОГАТЬ ЯДРО" и "ПРИШЛОСЬ ВНЕСТИ ПРАВКИ" - это, в реальности, сводиться к лени создавать свой функционал, когда стандартный уже почти готов, просто бы небольшие корректировки внести)
По своему опыту могу сказать, что правка в ядро не обязательная даже в самом худшем случае. Баги - пускай и медленно, но всё же правятся(особенно если долбить в поддержку не просто "у вас косяк, ищите сами", а прямо написать "ошибка тут, выяснили что она происходит потому что, мы поравили ее таким образом и вам рекомендуем. Может нам так везло, но такие правки они вносят довольно шустро в ближайших же обновлениях(даже в их виртуальную машину(!!!) (писал им по поводу MySQL параметров Битрикса, которые подобраны не оптимальны, из-за которых обновление на MySQL8+ может падать. Поправили за 2 недели +-).
И правка в ядро - почти всегда от лени сделать более правильное решение "в обход". Почти все существующие правки, кроме багов, которые все таки редкие (правда, только 3 за всю жизнь находил) - это из-за нежелания создавать копию громоздкой копии функционала ядра со своими доработками. Проще внести изменение в пару файлов ядра и при обновлении по гиту восстанавливать их (отслеживать их не так уж и сложно).
Обходиться без правок можно. В идеальном мире - нужно обходиться без правок в ядро всегда и если уж задача может решиться хоть созданием своей полной копии ядра с изменениями - делать надо так.
Но в нашем бренном мире - правки просто экономят время. И делаются действительно только при крайней нужде)
Дам пару комментариев к вашему комментарию:) Открыл навскидку пару интернет-магазинов на битриксе, зашёл в публичной части в раздел каталога, "отладка" -> "суммарная статистика", "сбросить кэш" и смотрим:один - 1819 запросов,другой - 1999 запросов."Криво" для Битрикса - это когда тут счёт идёт на десятки тысяч :)
Редко пишу комментарии, но тут тяжело не отписаться. Сразу договорюсь, что к интернет-магазинам почти ни разу не притрагивался и работал в первую очередь с Корпоративными порталами. Однако ядро везде одинаковое и потому мое мнение имеет место быть.
Про Битрикс много всего плохого можно сказать: - Обилие легаси? Да. - Запутанный функционал и кодовая база? К сожалению да, нужен год просто чтобы начинать понимать bitrix-way (типо мы тут все молодежные). - Страх при каждом обновлении? 50/50 (об этом ниже) - Плохое мобильное приложение? Да. Без аппеляционно.
И при всем при этом.... Статья меня напрягла откровенной дезинформацией в ряде случаев.... Думаю построить свой комментарий так: 1. Сначала притензии к статье 2. Потом пояснение за все накопленные вопросы.
Тейк №1: Непродуманная система, которая генерирует 1800+ запросов на простую прогрузку и написана на PHP(!)
Я когда впервые прочитал это даже несколько раз проверял "не показалось ли". Самая тяжелая страница, на моей памяти, генерила 200+ запросов(можно даже на самой странице глянуть черещ режим откладки в админ-панели сверху) и сразу же уходила в кэш на сутки, после чего отдвалась за считанные мгновения. 1800 - для стандартной реализации Битрикса - невозможная цифра. Такое возможно только при кривой доработке и запросах к БД в цикле (кривой код - везде кривой и вопрос не к Битриксу, а к разрабу который это сделал да и еще умудрился ПОДКЛЮЧИТЬ НА КАЖДУЮ СТРАНИЦУ (!!!!) (скорее всего через события), раз такие цифры были на всем сайте. Я очень надеюсь, что это просто один гипертрофированный пример).
Конечно сам Битрикс не болид и к скорости его работы МОЖНО предъявлять притензии.... Но если его доработкой занимается человек, который хотя бы базовый экзамен прошел - он такой херни не допустит.
+ отдельно стоит упомянуть, что Битриксоиды движутся в нужную сторону и оптимизацией занимаются. Как новое ядро, так и переписывание всего в UX на реактивные фреймворки (внешний вид становиться кратно лучше и скорость работы страницы тоже повышается), да и просто переход на новые версии инструментов (вроде PHP8+) постепенно, но приводит к позитивным сдивигам в вопросах производительности. Чтобы современные версии работали медленно.... У меня много вопросов к программистам, которые довели современную систему до такого состояния....
Тейк 2. Через ORM нельзя работать с инфоблоками (основным способом хранения информации).
Тоже две строчки. И это чисто ядро, без создания своих вспомогательных классов и прочего :) ORM-вездесуще :)
Тейк 3. Функционал ради функционала. Столько всего, а толку ноль.
Должен признать, что когда впервые знакомился с системой и сам страдал такими мыслями. Одно только обучение "как пользователю" потребовало от меня 2-х недель нон-стоп чтения helpdesk (хотя я был сотрудником в компании-интеграторе, так что даже по сравнению с обычным пользователем мне нужно было знать много и досконально, чтобы хотя бы отвечать на вопросы клиентов) и назвать ее дружелюбной с первых секунд.... Несколько проблематично.
Однако со временем я стал понимать зачем там это все спрятано. И что смешно - нужно оно не столько пользователю... Сколько программисту.
Возьмем простую задачу: "Создать/развернуть систему, которая позволит контролировать работу сотрудников, унифицировать взаимодействие(в том числе документооборот) и в целом облегчать работу путем автоматических напоминаний о том-сем"
Это не космическое требование, а буквально первая необходимость с которой сталкивается молодая компания, где штат достиг хотя бы 20-30 человек.
И поставь такую задачу разработчику, который не знает о Битриксе - он как минимум афигеет и зарядит внедрение на пол-года, если не больше.
Но стоит вспомнить о Битриксе.... Там такая базовая потребность УЖЕ реализована из коробки. И премущество в том, что в любой момент у компании может быть новая потребность, которая уже "специфична" под ее род деятельности. В другом, самописном инструменте, потребовалось бы изобретать как всю логику с нуля, так и подгонять под критерии того же документооборота. А в Битриксе.... В нем столько базового функционала спрятано.... Что на его основе можно минимум половину всей работы упразднить обычными вызовами Стандартных классов. Нужен интерфейс? Вот тебе UX компоненты и расширения самого Битрикса (стили и скрипты включены). Нужно хранение? Держи инфоблоки(для пользователей) и HlBlock, если нужны просто таблицы. Работа с пользователем, правами, файлами - в том или ином виде это УЖЕ лежит в Битриксе и тем самым скорость разработки кратно повышается без необходимости тянуть внешние библиотеки, которые мог написать как уверенный разработчик, так и Вася-вайбкодер. А тут всё уже приведено к единому стилю, есть контакты разработчиков(условно) и всё это УЖЕ вплетено в экосистему. Чтобы доработать Битрикс нужно прикладывать кратно меньше усилий чем в любом другом случае. И большинство запросов от клиента решается либо ВООБЩЕ без вмешательства разработки (где-то уже лежит нужное), либо решается "поверх" уже знакомого пользователю функционала.
Ответы на накопившиеся вопросы: 1. Так неужели система всё таки прекрасна?
Смотря с чьей стороны. С точки зрения пользователя - система на самом деле хороша и решает много задач из коробки, от продаж, до документаооборота и статистики. Всё это уже завернуто в UX и позволяет даже без знания кода делать сложную автоматизацию людям, которые соврешенно не знакомы с кодом (передаем привет функционалу "Бизнес-процессов"(визуального программирования из блоков))
С точки зрения разработчика - это ад, в котором со временем становиться комфортно жить (начинаешь получать удовольствие от кипящей вокруг магмы). Порог вхождения в разработку - крайне высокий. Нужен год или два просто чтобы начать что-то понимать в этой системе и уметь ее кастомизировать. На каждом шагу будет КУЧА нюансов, начиная с "легаси" и заканчивая тем, что в Битриксе огромная проблема с документированием функционала. Не в первый раз слышу, что документация Битрикса - это его исходники - всё остальное от лукавого)
Система далеко не идеальна и мне, как разработчику, не в первой делать куклу вуду на авторов некоторых решений ядра. Но стоит признать.... Что развитие системы идет в нужном направлении. Многое легаси постепенно выноситься за скобки, производитеность и удобство повышается + само развитие идет в соответсвии с современными трендами (включая тот же ИИ).
Система не идеальна - но она не просто так держится в топе и у нее по сей день мало конкурентов.
2. А что касается обновлений? Они что, не бочка с порохом?
Если не трогать ядро - нет. У Битрикса есть постулат, что ЯДРО нельзя трогать даже под страхом расстрела. В 99% случаев, если ядро не менялось разработчиком - любое обновление пройдет спокойно и без ошибок.
Но вот возможно ли обойтись без изменения ядра?.... Тут.... Всё не просто.... Битрикс - большая система. Но далеко не на все случаи жизни ядро продумано. Периодически приходиться как редактировать стандартные компоненты (что тоже ядро(!!!)), так и некоторые системные функции, которые просто имеют БАГ(!) или наоборот НЕ ИМЕЮТ "событий", к которым можно было бы подключиться или просто стоит "хардкод" какого-то параметра.
Вот тут.... Действительно каждое обновление - как игра в русскую рулетку. Кол-во молитв и взываний к богу в момент нажатия в админке "загрузки обновлений" больше, чем в любой церви :)
И тут можно как в сторону Битрикса кидать камни.... Так и в сторону разработчиков.
3. В комментари и статьях постоянно упоминается легаси. Неужели это действительно вездесущая проблема?
Да. Я бы даже сказал это САМАЯ ГЛАВНАЯ проблема Битрикса. Даже то, что выглядит "по-современному" на интерфейсе.... Под капотом может быть таким страшным функционалом, написанным на коленке.... Что плакать хочется.
Всё что касается ядра D7 или ORM - зачастую прекрасно и удобно. Но вот проблема в том... Что D7 - это не полная замена ядра.... Это скорее огрызок на 1/3 всего функционала, который действительно осовременили. Всё остальное - может быть как идеалом отвратительно написанного спаггети кода, так и огромным костылем, который сделали из обломков других костылей. И работает оно ровно до той поры... Пока это никто не меняет.
Микро-вывод: Битрикс - это неплохой продукт. И активный пиар у них начался не так давно, чтобы говорить исключительно о маркетинге. С ним можно работать и его использование на самом деле позволяет снизить либо расходы, либо операционку.
Но и расти этой системе - еще есть куда. И я лишь желаю Битриксоидам довести D7 до абсолютной замены старому ядру и развивать систему дальше :)
P.S Но вот хардкод в модуле диска + базе знаний я вам не прощу....
Хотя так не принято на этом ресурсе, но я вступлюсь за автора.
И попробую сделать это тезисно:
Современные требования к Джунам - Неадекватные. Как говорил один мой знакомый тимлид: "По-хорошему, junior - это человек, которые ещё недавно смог усвоить синтаксис языка, умеет писать на нем просто РАБОТАЮЩИЙ код и поддаётся обучению". И лично я с этим согласен. Но на рынке существует отвратительная и откровенно диструктивная тенденция - назвать должность "Junior", вписать требования для Мидла или УЖЕ БЫВАЛОГО джуна, назначить зарплату, соответвенно указанной должности и собирать либо ТОЛЬКО СЛИВКИ, либо давать работу джунов уже действующим разработчикам с опытом и знаниями, которые и так уже зашиваются и потому им нужно пополнить штат. А нанять людей, даже за смешную зарплату в 30-40к рублей - никто даже не думает. Хотя через год, эти ребята уже как минимум смогут решать простые задачи, освободив более компетентный ресурсы. Самая рациональная причина, которую я слышал и которую даже могу понять: "На джунов придётся тратить ещё больше времени и компания от этого ничего не выиграет". Но сценарий, при котором человеку дают шанс приобрести эти навыки самостоятельно и на реальных задачах... Зачастую даже не рассматривается. И должность Junior в современном мире, это ходячий парадокс - "middle без опыта работы". Да и будем откровенны... Даже после того как Джуна взяли на работу... Далеко не везде с ним будут "возиться"... Хорошо если документацию покажут...
HR очень редко когда могут нормально оценивать кандидата. HR не знает ни терминалогии, ни общих принципов работы, а потому ведёт себя как ребёнок в магазине. Где обретка поцветастее, где шрифт поприятнее - там и пойду за приобретением. И это не "плевок" в их сторону. Это просто данность. Они такие же работники и так же "импровизируют" в процессе, если не знают обсуждаемой темы. Если они не могут проверить компетенции - то будут оценивать оформление, искать звучные имена или названия компаний. А может и, в особенно упоротых случаях, будут подкидывать монетку или выбирать по гороскопу)) По-хорошему HR должен отбирать стопку резюме, отслеживать красные флаги и передавать их целиком на рассмотрение тем, кто действительно сможет оценить проф. данные человека. Но нередко бывает, что ищет ТОЛЬКО HR, а человек устраивается на работу, если понравился ей и смог не упасть в грязь лицом на последнем этапе. Хороших и компетентный HR-ов, как и программистов - надо ещё поискать:)
Между собеседованиями Джунов и Мидлов - огромная разница. Когда я искал свою первую работу программистом - то отчётливо замечал, что тебя даже за человека не считают. Тестовое подавай, корп над ним неделю ради призоачного шанса, пять этапов собеседований, идеальное знание теории и приемлемая практика или сразу отказ. Но стоило так попасть на первую работу и продержаться там год... Тебе мало того, что предлагают запрплату неадекватно высокую, так и ещё собеседуют спустя рукава. Интереса ради я прошёл 5-6 собеседований и везде меня были согласны брать. Без тестового, вопросы - откровенно детские.... И что самое смешное. Если у тебя УЖЕ есть опыт и ты просто закинешь резюме на тот же HH.ru - тебе чуть ли не мобильник будут обрывать. И это наверное самое странное в нашей области. Джунов - собеседуют как Сеньйоров... А Сеньйоров - как Джунов...
Автору желаю поскорее найти свое место и не опускать руки. Особенно желаю даже не находя работу - профессионально расти.
Как по мне - идея неплохая в своей сути. Можно конечно подескутировать относительно того не создание ли это очередного велосипеда, но от себя вижу вполне полезную нишу: обмен запросами с аналитиками BI - там может приятно лечь на общий pipeline проекта или по крайней мере упростить этот обмен.
Но есть три "no":)
Я бы порекомендовал где возможность сделать runtime компиляцию без необходимости вызывать команду каждый раз. Что-то вроде простенького nOrm.actualize(). Где в рантайм не получится - набрать готовых встроек на этап компиляции.
Учитывая сколько проектов УЖЕ на ORM, неплохо бы подсластить пелюлю и добавить коннекторы на основные ORMки языков, чтобы итоговый результат запроса аккуратно упаковывался в уже сущесвующие типы объектов строк или коллекций. Тогда выше шанс, что на nORM обратят внимание.
Скажу немного крамольную фразу для Хабра, но: "В эпоху ИИ ценность утилиты уже не столь очевидна". Я бы порекомендовал развивать ее во что-то более комплексное, но направление дать не решусь. Оставлю на ваших плечах.
Вот 3 моих маленьких совета. Надеюсь они вам помогут, даже если будут отброшены)
Радует что хоть кто-то стал говорить об этой теме вслух и с пониманием на Хабре.
ИИшка хороший и мощный инструмент. Но как и водиться - каждый инструмент с нюансами. ИИ не волшебная палочка, в текущем виде это как тупенький, но очень упорный Джун под энергетиками. Все что можно дать такому Джуну - можно дать и ИИшке.
Но как и в случае с Джуном:
Не доверяй и не надейся на лучшее - только проверка и прослеживание логики
Сверяйся с условиями задачи и что реально было сделано
Базовые предельный и критические сценарии
Дай другой ИИшке сочинить тесты. Другой, которая НЕ ВИДИТ Код и не может подстроиться под него. (один Джун пишет код, другой тесты к нему)
Меняй модели, ставь условия по-другому и тп и тд
И если соблюдать хотя бы стандартные правила - выигрыш будет точно такой же как от разрабов в подчинении Лида.
Отмечу только, что скепсис по отношению к нейросетям не разляю. Если за компьютерои сидит именно специалист - скорость работы увеличивается, так как ИИ на себя берет банальную рутину или играет роль гугла.
Бойлерплейты, модели бд, конекторы и прочее, что не требует ума и что может сделать ИИ.
Ну или побыть тестировщиком, по крайней мере)
Смешно))
История как из кино)
Но все время не покидала меня мысль.... Что вы обманули клиента и при правильных формулировках - может даже в суд на вас подать.... Возможно даже выиграв.
Очень не хватало материала о мета-навыках и очень приятно видеть его на Хабре)
Думаю вам стоит так же написать материал не о внешнем взаимодействии с людьми, а о внутреннем самоуправлении, включая дисциплину логику, как один из внутренних фильтров.
Очень понравилась идея из Челпановского учебника логики: "Наука логики не о том как мыслить правильно, а о том - как найти ошибки в мышлении"
Прошу прощения, случайно отправил и не дописал.
Исправляюсь:
Дам пару комментариев к вашему комментарию:)
За оформление прошу прощения, привык писать заметки и прочее в Obsidian, так что оформляю как .md файлы.
>> Открыл навскидку пару интернет-магазинов на битриксе, зашёл в публичной части в раздел каталога, "отладка" -> "суммарная статистика", "сбросить кэш" и смотрим:один - 1819 запросов,другой - 1999 запросов."Криво" для Битрикса - это когда тут счёт идёт на десятки тысяч :)
За интернет магазины не могу не подтвердить, не опровергнуть, так как(говорил в изначальном комментарии) - не работал с ними. Только корпоративные порталы и иногда мелкие доработки/анализ магазинов, но не более.
Свои аргументы в первую очередь направляю в сторону Битрикс24. Корпоративный портал. Однако, учитывая популярность для магазинов(есть пара клиентов у нас), сложно поверить что в стандартной реализации магазина такой бардак. Зная ядро и его возможности - запросы в цикле нередко решаются передачей в копоненты уже готовы данных "одиночного" большего запроса. А не вызовом в каждой компоненте новой строки из БД. Если такое действительно в стандартных решениях или в решениях от золотых партнеров - мне правда их очень жаль :(. В корпоративной портале 200+ запросов - это действительно максимум, который видел на стандартных компонентах. Не говоря уже о том, что многое переписывается на реактивные компоненты, которые вместо каскадной отрисовки вложенных компонентов - просто обращаются в 2-3 запроса на бек и получают все необходимое без вложенных костылей.
>> Вот только коробочный код в не возвращает экземпляры сущностей, связанных \Bitrix\Iblock\Elements\Element{*код*}Table . Он вернёт вам экземпляр сущности, связанной с \Bitrix\Iblock\IblockElementTable , а там как раз обозначенная автором статьи проблема в наличии. И лично я с этим сталкивался, хотя сейчас не вспомню, как именно.
Тут, к сожалению, не совсем понял о чем речь, так как каждый Инфоблок имеет свой Динамически-сгенерированный класс-модель. Простой пример, только что выполнил на портале:
$dataClass = Iblock::wakeUp(iblockId)->getEntityDataClass();В итоге получился следующий класс:
\Bitrix\Iblock\Elements\ElementCashExpenseTableИ если будут reference - то спокойно понятно что за модель/инфоблок. Возможно вы имели ввиду что-то иное, но ответил как смог, прошу не кидаться излишне помидорам)
>> Пример менее сложной задачи от заказчика ( лично я не готов назвать её простой): запустили интернет-магазин, всё отлично. Теперь нужно ровно то же самое, но на белорусском. В Битриксе есть многосайтовость, так что за отдельную лицензию мне платить не надо. И каталог, разумеется, должен быть один; там всего-то добавить название товара на белорусском и описание. Это же недолго, да? А потом ещё казахский сайт запустим!
Хотя мы этим редко пользуемся(просто нет многоязычности на корпоративных порталах, зачастую), но справедливости ради отмечу - что есть lang-файлы, которые легко превращают сайт, портал или что-либо еще в многоязычный сайт. Единственный вопрос - это содержимое сайта, вроде названия товаров, статьей и прочего. Но тут я бы мог предложить "вытащить" все текстовые данные из Битрикса, запомнить связку, скормить какой-нибудь нейронке(для качества), чтобы она перевела это на нужный язык и сохранить "содержимое" как альтернативу. А потом просто все новые товары/статьи вести уже на всех поддерживаемых языках или сразу доработать редактор так, чтобы он автоматом все новое кормил на перевод всех поддреживаемых языков. Примеров привести не могу, но за пару минут в голову приходит такое решение и не похоже(по крайней мере у меня в голове) - что тут что-то ломается.
>> Слишком вольно обобщаете. Мой опыт говорит так: порой нужное решение не вписывается в рамки Битрикса на считанные проценты, но именно это ставит крест на использовании того, что вписалось.
Будет похоже, словно я придираюсь к словам, но если решение не вписалось на "считанные проценты" - это победа) Значит вам вместо 100% надо выполнит оставшиеся проценты. Как минимум сделать варварское решение и просто форкнуть нужный функционал, вынести в отдельный модуль и доработать под себя несостыковки.
У нас с вами разный опыт, да и спорить тут "кто прав, а кто нет" - сложно, так как потребовало бы выйти за пределы комментирования к небольшому рабочему исследованию, но в противовсе скажу свой опыт, повторив за собой из первого комментария: "Когда нас просят о чем-то новом, первое что мы делаем - это ищем то, что уже реализовано в Битриксе и просто дорабатываем под свою задачу. В 90% случаев это работает и половина всей разработки смещается в применение уже готового, а оставшееся - в реальную разработку. И что тут хорошо для пользователя - выглядит для них это всегда знакомо. Многое можно провести либо как бизнес-процесс, либо как задачу, либо CRM-сущности(Сделки, Лиды, Смарт-процессы) и со всем этим работники портала уже знакомы и не теряются, когда эта часть просто обрастает новыми возможностями. И это действительно помогает как ускорить разработку, так и адаптацию сотрудников к "новому".
>> Как говорится, "вы или крестик снимите, или трусы наденьте". Значительная часть хейта в сторону Битрикса как раз из-за того, что в ядре что-то криво, а допустимые лицензией способы решения - это прорва работы. Если я из-за бага в ядре не могу это ядро использовать, зачем мне вообще эта система? Есть фреймворки; админка в них генерируется с помощью готовых утилит и кастомизируется при необходимости. Если вы решили посвятить себя разработке сайтов, и планируете хотя бы в среднесрочной (3-5 лет) перспективе, то лучше вкладываться не в Битрикс."Здесь и сейчас как-нибудь запуститься, лишь бы работало" - Битрикс для этого вполне годится, ибо коробка. Но таких "коробок" уже немало, кому-то и Тильда подойдёт.
Конечно немного задевает, что был использован пример с трусами и крестиком, но буду считать это вашей манерой без личночных нападок)
Относительно "НЕЛЬЗЯ ТРОГАТЬ ЯДРО" и "ПРИШЛОСЬ ВНЕСТИ ПРАВКИ" - это, в реальности, сводиться к лени создавать свой функционал, когда стандартный уже почти готов, просто бы небольшие корректировки внести)
По своему опыту могу сказать, что правка в ядро не обязательная даже в самом худшем случае. Баги - пускай и медленно, но всё же правятся(особенно если долбить в поддержку не просто "у вас косяк, ищите сами", а прямо написать "ошибка тут, выяснили что она происходит потому что, мы поравили ее таким образом и вам рекомендуем. Может нам так везло, но такие правки они вносят довольно шустро в ближайших же обновлениях(даже в их виртуальную машину(!!!) (писал им по поводу MySQL параметров Битрикса, которые подобраны не оптимальны, из-за которых обновление на MySQL8+ может падать. Поправили за 2 недели +-).
И правка в ядро - почти всегда от лени сделать более правильное решение "в обход".
Почти все существующие правки, кроме багов, которые все таки редкие (правда, только 3 за всю жизнь находил) - это из-за нежелания создавать копию громоздкой копии функционала ядра со своими доработками. Проще внести изменение в пару файлов ядра и при обновлении по гиту восстанавливать их (отслеживать их не так уж и сложно).
Обходиться без правок можно.
В идеальном мире - нужно обходиться без правок в ядро всегда и если уж задача может решиться хоть созданием своей полной копии ядра с изменениями - делать надо так.
Но в нашем бренном мире - правки просто экономят время. И делаются действительно только при крайней нужде)
Дам пару комментариев к вашему комментарию:)
Открыл навскидку пару интернет-магазинов на битриксе, зашёл в публичной части в раздел каталога, "отладка" -> "суммарная статистика", "сбросить кэш" и смотрим:один - 1819 запросов,другой - 1999 запросов."Криво" для Битрикса - это когда тут счёт идёт на десятки тысяч :)
Редко пишу комментарии, но тут тяжело не отписаться. Сразу договорюсь, что к интернет-магазинам почти ни разу не притрагивался и работал в первую очередь с Корпоративными порталами. Однако ядро везде одинаковое и потому мое мнение имеет место быть.
Про Битрикс много всего плохого можно сказать:
- Обилие легаси? Да.
- Запутанный функционал и кодовая база? К сожалению да, нужен год просто чтобы начинать понимать bitrix-way (типо мы тут все молодежные).
- Страх при каждом обновлении? 50/50 (об этом ниже)
- Плохое мобильное приложение? Да. Без аппеляционно.
И при всем при этом.... Статья меня напрягла откровенной дезинформацией в ряде случаев....
Думаю построить свой комментарий так:
1. Сначала притензии к статье
2. Потом пояснение за все накопленные вопросы.
Тейк №1: Непродуманная система, которая генерирует 1800+ запросов на простую прогрузку и написана на PHP(!)
Я когда впервые прочитал это даже несколько раз проверял "не показалось ли". Самая тяжелая страница, на моей памяти, генерила 200+ запросов(можно даже на самой странице глянуть черещ режим откладки в админ-панели сверху) и сразу же уходила в кэш на сутки, после чего отдвалась за считанные мгновения. 1800 - для стандартной реализации Битрикса - невозможная цифра. Такое возможно только при кривой доработке и запросах к БД в цикле (кривой код - везде кривой и вопрос не к Битриксу, а к разрабу который это сделал да и еще умудрился ПОДКЛЮЧИТЬ НА КАЖДУЮ СТРАНИЦУ (!!!!) (скорее всего через события), раз такие цифры были на всем сайте. Я очень надеюсь, что это просто один гипертрофированный пример).
Конечно сам Битрикс не болид и к скорости его работы МОЖНО предъявлять притензии.... Но если его доработкой занимается человек, который хотя бы базовый экзамен прошел - он такой херни не допустит.
+ отдельно стоит упомянуть, что Битриксоиды движутся в нужную сторону и оптимизацией занимаются. Как новое ядро, так и переписывание всего в UX на реактивные фреймворки (внешний вид становиться кратно лучше и скорость работы страницы тоже повышается), да и просто переход на новые версии инструментов (вроде PHP8+) постепенно, но приводит к позитивным сдивигам в вопросах производительности. Чтобы современные версии работали медленно.... У меня много вопросов к программистам, которые довели современную систему до такого состояния....
Тейк 2. Через ORM нельзя работать с инфоблоками (основным способом хранения информации).
Откровенная дезинформация. Лови простой код:
$iblockModel = Iblock::wakeUp(*id-инфоблока*)->getEntityDataClass();
$data = $iblockModel::query()->where('ID', 1)->fetch();
Две строчки кода и ты можешь забрать информацию из инфоблока.
А как создать запись?
$row = $iblockModel::createObject();
$addResult = $row->set('NAME', 'Автор забыл')->save();
Тоже две строчки. И это чисто ядро, без создания своих вспомогательных классов и прочего :)
ORM-вездесуще :)
Тейк 3. Функционал ради функционала. Столько всего, а толку ноль.
Должен признать, что когда впервые знакомился с системой и сам страдал такими мыслями. Одно только обучение "как пользователю" потребовало от меня 2-х недель нон-стоп чтения helpdesk (хотя я был сотрудником в компании-интеграторе, так что даже по сравнению с обычным пользователем мне нужно было знать много и досконально, чтобы хотя бы отвечать на вопросы клиентов) и назвать ее дружелюбной с первых секунд.... Несколько проблематично.
Однако со временем я стал понимать зачем там это все спрятано. И что смешно - нужно оно не столько пользователю... Сколько программисту.
Возьмем простую задачу: "Создать/развернуть систему, которая позволит контролировать работу сотрудников, унифицировать взаимодействие(в том числе документооборот) и в целом облегчать работу путем автоматических напоминаний о том-сем"
Это не космическое требование, а буквально первая необходимость с которой сталкивается молодая компания, где штат достиг хотя бы 20-30 человек.
И поставь такую задачу разработчику, который не знает о Битриксе - он как минимум афигеет и зарядит внедрение на пол-года, если не больше.
Но стоит вспомнить о Битриксе.... Там такая базовая потребность УЖЕ реализована из коробки. И премущество в том, что в любой момент у компании может быть новая потребность, которая уже "специфична" под ее род деятельности. В другом, самописном инструменте, потребовалось бы изобретать как всю логику с нуля, так и подгонять под критерии того же документооборота. А в Битриксе.... В нем столько базового функционала спрятано.... Что на его основе можно минимум половину всей работы упразднить обычными вызовами Стандартных классов. Нужен интерфейс? Вот тебе UX компоненты и расширения самого Битрикса (стили и скрипты включены). Нужно хранение? Держи инфоблоки(для пользователей) и HlBlock, если нужны просто таблицы. Работа с пользователем, правами, файлами - в том или ином виде это УЖЕ лежит в Битриксе и тем самым скорость разработки кратно повышается без необходимости тянуть внешние библиотеки, которые мог написать как уверенный разработчик, так и Вася-вайбкодер. А тут всё уже приведено к единому стилю, есть контакты разработчиков(условно) и всё это УЖЕ вплетено в экосистему. Чтобы доработать Битрикс нужно прикладывать кратно меньше усилий чем в любом другом случае. И большинство запросов от клиента решается либо ВООБЩЕ без вмешательства разработки (где-то уже лежит нужное), либо решается "поверх" уже знакомого пользователю функционала.
Ответы на накопившиеся вопросы:
1. Так неужели система всё таки прекрасна?
Смотря с чьей стороны.
С точки зрения пользователя - система на самом деле хороша и решает много задач из коробки, от продаж, до документаооборота и статистики. Всё это уже завернуто в UX и позволяет даже без знания кода делать сложную автоматизацию людям, которые соврешенно не знакомы с кодом (передаем привет функционалу "Бизнес-процессов"(визуального программирования из блоков))
С точки зрения разработчика - это ад, в котором со временем становиться комфортно жить (начинаешь получать удовольствие от кипящей вокруг магмы).
Порог вхождения в разработку - крайне высокий. Нужен год или два просто чтобы начать что-то понимать в этой системе и уметь ее кастомизировать. На каждом шагу будет КУЧА нюансов, начиная с "легаси" и заканчивая тем, что в Битриксе огромная проблема с документированием функционала. Не в первый раз слышу, что документация Битрикса - это его исходники - всё остальное от лукавого)
Система далеко не идеальна и мне, как разработчику, не в первой делать куклу вуду на авторов некоторых решений ядра. Но стоит признать.... Что развитие системы идет в нужном направлении. Многое легаси постепенно выноситься за скобки, производитеность и удобство повышается + само развитие идет в соответсвии с современными трендами (включая тот же ИИ).
Система не идеальна - но она не просто так держится в топе и у нее по сей день мало конкурентов.
2. А что касается обновлений? Они что, не бочка с порохом?
Если не трогать ядро - нет. У Битрикса есть постулат, что ЯДРО нельзя трогать даже под страхом расстрела. В 99% случаев, если ядро не менялось разработчиком - любое обновление пройдет спокойно и без ошибок.
Но вот возможно ли обойтись без изменения ядра?.... Тут.... Всё не просто....
Битрикс - большая система. Но далеко не на все случаи жизни ядро продумано. Периодически приходиться как редактировать стандартные компоненты (что тоже ядро(!!!)), так и некоторые системные функции, которые просто имеют БАГ(!) или наоборот НЕ ИМЕЮТ "событий", к которым можно было бы подключиться или просто стоит "хардкод" какого-то параметра.
Вот тут.... Действительно каждое обновление - как игра в русскую рулетку. Кол-во молитв и взываний к богу в момент нажатия в админке "загрузки обновлений" больше, чем в любой церви :)
И тут можно как в сторону Битрикса кидать камни.... Так и в сторону разработчиков.
3. В комментари и статьях постоянно упоминается легаси. Неужели это действительно вездесущая проблема?
Да. Я бы даже сказал это САМАЯ ГЛАВНАЯ проблема Битрикса. Даже то, что выглядит "по-современному" на интерфейсе.... Под капотом может быть таким страшным функционалом, написанным на коленке.... Что плакать хочется.
Всё что касается ядра D7 или ORM - зачастую прекрасно и удобно.
Но вот проблема в том... Что D7 - это не полная замена ядра.... Это скорее огрызок на 1/3 всего функционала, который действительно осовременили. Всё остальное - может быть как идеалом отвратительно написанного спаггети кода, так и огромным костылем, который сделали из обломков других костылей. И работает оно ровно до той поры... Пока это никто не меняет.
Микро-вывод: Битрикс - это неплохой продукт. И активный пиар у них начался не так давно, чтобы говорить исключительно о маркетинге. С ним можно работать и его использование на самом деле позволяет снизить либо расходы, либо операционку.
Но и расти этой системе - еще есть куда. И я лишь желаю Битриксоидам довести D7 до абсолютной замены старому ядру и развивать систему дальше :)
P.S Но вот хардкод в модуле диска + базе знаний я вам не прощу....
Хотя так не принято на этом ресурсе, но я вступлюсь за автора.
И попробую сделать это тезисно:
Современные требования к Джунам - Неадекватные. Как говорил один мой знакомый тимлид: "По-хорошему, junior - это человек, которые ещё недавно смог усвоить синтаксис языка, умеет писать на нем просто РАБОТАЮЩИЙ код и поддаётся обучению". И лично я с этим согласен. Но на рынке существует отвратительная и откровенно диструктивная тенденция - назвать должность "Junior", вписать требования для Мидла или УЖЕ БЫВАЛОГО джуна, назначить зарплату, соответвенно указанной должности и собирать либо ТОЛЬКО СЛИВКИ, либо давать работу джунов уже действующим разработчикам с опытом и знаниями, которые и так уже зашиваются и потому им нужно пополнить штат. А нанять людей, даже за смешную зарплату в 30-40к рублей - никто даже не думает. Хотя через год, эти ребята уже как минимум смогут решать простые задачи, освободив более компетентный ресурсы. Самая рациональная причина, которую я слышал и которую даже могу понять: "На джунов придётся тратить ещё больше времени и компания от этого ничего не выиграет". Но сценарий, при котором человеку дают шанс приобрести эти навыки самостоятельно и на реальных задачах... Зачастую даже не рассматривается. И должность Junior в современном мире, это ходячий парадокс - "middle без опыта работы". Да и будем откровенны... Даже после того как Джуна взяли на работу... Далеко не везде с ним будут "возиться"... Хорошо если документацию покажут...
HR очень редко когда могут нормально оценивать кандидата. HR не знает ни терминалогии, ни общих принципов работы, а потому ведёт себя как ребёнок в магазине. Где обретка поцветастее, где шрифт поприятнее - там и пойду за приобретением. И это не "плевок" в их сторону. Это просто данность. Они такие же работники и так же "импровизируют" в процессе, если не знают обсуждаемой темы. Если они не могут проверить компетенции - то будут оценивать оформление, искать звучные имена или названия компаний. А может и, в особенно упоротых случаях, будут подкидывать монетку или выбирать по гороскопу)) По-хорошему HR должен отбирать стопку резюме, отслеживать красные флаги и передавать их целиком на рассмотрение тем, кто действительно сможет оценить проф. данные человека. Но нередко бывает, что ищет ТОЛЬКО HR, а человек устраивается на работу, если понравился ей и смог не упасть в грязь лицом на последнем этапе. Хороших и компетентный HR-ов, как и программистов - надо ещё поискать:)
Между собеседованиями Джунов и Мидлов - огромная разница. Когда я искал свою первую работу программистом - то отчётливо замечал, что тебя даже за человека не считают. Тестовое подавай, корп над ним неделю ради призоачного шанса, пять этапов собеседований, идеальное знание теории и приемлемая практика или сразу отказ. Но стоило так попасть на первую работу и продержаться там год... Тебе мало того, что предлагают запрплату неадекватно высокую, так и ещё собеседуют спустя рукава. Интереса ради я прошёл 5-6 собеседований и везде меня были согласны брать. Без тестового, вопросы - откровенно детские.... И что самое смешное. Если у тебя УЖЕ есть опыт и ты просто закинешь резюме на тот же HH.ru - тебе чуть ли не мобильник будут обрывать. И это наверное самое странное в нашей области. Джунов - собеседуют как Сеньйоров... А Сеньйоров - как Джунов...
Автору желаю поскорее найти свое место и не опускать руки. Особенно желаю даже не находя работу - профессионально расти.