Привет! Для начала давайте знакомиться. Меня зовут Ильяс, я руководитель группы компаний DD Group и студии DivanDesign. 12 лет мы создаём сайты на (MODX)EvolutionCMS, от супер-маленьких и простых, до огромных и сложных. В определённый момент решили делиться своими наработками с общественностью и выложили часть в свой репозиторий (пока, к сожалению, там нет и половины всего). В числе прочих, развиваем плагин ManagerManager (не без помощи сообщества, конечно же). Здесь немало текста, но я искренне надеюсь, что вы дочитаете до конца ✌

Давно хочу кардинально переработать ManagerManager, так как его код просто морально устарел. Он разрабатывался так давно, что технологии программирования не выдерживают никакой критики :-) Мы начали работу над плагином лет 10 назад, а основа сделана была и того раньше! Развитие усложнялось ещё и тем, что сам ManagerManager содержит очень много дочерних плагинов (так называемые «виджеты», что по смыслу давно не верно).


Куда хотелось бы двигаться?

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


Удобство для разработчиков плагина

Это главная задача, ведь удобный, прозрачный и согласованный единой концепцией код позволит развивать продукт меньшими усилиями. Сейчас там всё плоско и разрозненно, сплошная коллекция антипаттернов программирования, у Стива Макконнела бы волосы зашевелились :-)

Рассмотрим наиболее простые и понятные на текущий момент принципы:

  • HTML и CSS всегда отдельно от PHP. Нельзя миксовать оформление с логикой даже под страхом смерти.
  • JS, написанный прямо в PHP, допустим только в крайних случаях: когда там, условно, одна строчка и иначе никак. В основном же весь JS должен быть в отдельных файлах.
  • Избегание дублирования кода любыми средствами.
  • ООП. Комментарии, думаю, излишни.
  • Компоненты системы («виджеты») не должны напрямую взаимодействовать с CMS, только через ядро плагина.
  • Передача параметров по имени, а не по порядку (pass-by-name). Да, даже в PHP. Это повышает читабельность кода, а читабельность кода — наше всё.
  • Противодействие не предусмотренному использованию ядра плагина и его компонентов. Никаких чёртовых глобальных переменных и прочих уязвимых для грязных хаков моментов. Использование недокументированных особенностей сторонними разработчиками так сильно вставляет палки в колёса развития продуктов, что даже описать сложно! Там столько костылей порождено из-за этого, что смотреть больно.

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


Жёсткий стиль кода

Для эффективной работы, разработчики не должны отвлекаться на всякую шелуху, не имеющую отношения к логике продукта. Нам нужен единый, тщательно описанный и жёсткий стиль кода, чтобы один программист не создавал «кочки», о которые будет запинаться другой.

Представьте книгу, в которой каждое предложение набрано разной гарнитурой штифтов: Times New Roman соседствует с Comic Sans, Helvetica и ещё 500 другими. А теперь представьте, что каждое слово набрано разным размером шрифта. Ну и чтобы совсем было круто — каждая буква своим уникальным случайным цветом. Классно? Может я только что придумал произведение современного искусства, но читать эту книгу будет категорически неудобно. Ну ладно, читать. А теперь представьте, что над ней работают сразу 10 авторов и прямо сразу в процессе пишут со всем тем цирком, описанным выше. Спорим, они застрелятся раньше, чем выйдет книга? ;-)

У DD Group (моей компании) за 12 лет создан и по крупицам доработан стиль кода, связанный общей философией и часами горячих споров. К примеру, проработан в том числе общий принцип построения имён (переменных, методов, файлов, страниц документации и т. п.). Сразу хочу пресечь деструктивные дискуссии по этому поводу: стиль кода будет наш. Точка. Нет времени на бесполезные религиозные дискуссии с применением писькоизмерительных инструментов.


Документация для разработчиков

Чтобы все мы говорили на одном языке, а сердца наши бились в унисон — программистам нужна документация для программистов.

Надо не лениться и подробно описывать всё на свете. Программисты склонны к высокому контексту и слабому документированию своих великих шедевров, так что стремление к максимализму в противоположном направлении — самое оно. И здесь я говорю не о комментариях в коде (о них будет в стиле кода), а об отдельной от кода документации.

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

Документация будет в формате Markdown.


Отдельный чат именно для программистов, работающих над плагином

Нужны эффективные коммуникации строго по теме, но чтобы не перегружать лишними сообщениями. Вход открыт всем желающим, но оффтоп будет нещадно удаляться.


Пользователи — не программисты

Сейчас плагин написан программистами для программистов. Необходимость уметь программировать и писать PHP-код в правилах плагина — отстой. Всё должно настраиваться совершенно каузально, кликая мышечкой в интуитивно-понятные интерфейсы, попивая смузи и параллельно крася ногти за рулём. В идеале, для использования плагина не должна быть нужна документация вообще.


Отказ от идеологии правил

В топку правила! Да, правила — это гибкость, но эта гибкость в 90% случаев не востребована, а проблем из-за неё много. Ну не нужны разные представления для одной и той же TV в разных шаблонах и у разных ролей — поддерживать это в долгосрочной перспективе становится больно. Ну заведи ты ещё одну TV и не парь мозг, зачем экономить на их количестве? Это экономия на спичках, выходящая боком.


Ну ладно, а как тогда?

Почти сразу, те самые лет 10 назад, мы разработали модуль для редактирования правил ddMMEditor, но:

  • Это отдельная сущность, а люди не любят устанавливать кучу разных вещей и вникать в них. Да и правильно, не стоит плодить сущности без необходимости.
  • Это всё равно те же правила MM, только с автозаполнением и прочим сахаром. Проще, чем правила в коде, но всё равно не достаточно.
  • Создавался программистами без дизайнера. А без дизайнера нельзя.

Вместо этого мы должны интегрировать интерфейс настройки плагина прямо в CMS. Должно быть нативно и без лишних сущностей: создаёшь/редактируешь TV и прям там же ставишь галочку «Обязательно для заполнения» — всё, TV будет обязательна для заполнения, без единой строчки кода, без дурацких правил и лишних сложностей в виде ролей и разных шаблонов. Прямо там же выбираешь, что это не просто TV, а Яндекс.Карта, к примеру, там же настраиваешь количество колонок, ресайзы изображений и всё прочее. Что может быть проще, понятней и удобнее? Ну и всё в таком стиле, всё интегрировано в CMS, всё настраивается интуитивно, не требуя ни малейших навыков программирования.

Ещё раз напомню, что обратная совместимость с динозаврами должна быть сохранена, так что любители обмазаться коддингом должны быть довольны ;-)


Звучит неплохо, дайте два!

Полагаю, вы хотя бы примерно можете представить объём работы. Причём, характерные для Open Source постулаты «работает и ладно», «сделаем на скорую руку», «нам же никто не платит» — не допустимы. На первом этапе нужна тщательная профессиональная подготовка программистом, не младше сеньора и организатором: документация, проектирование, формулирование идей, организация работы и построение коммуникаций.

Потянуть это кому-то одному ну просто не по силам. Все мы хотим кушать и жить, на одном энтузиазме и борьбе за идею далеко не уедешь, а окупить всё это дело одному разработчику или даже команде не возможно. Так что, дамы и господа, если это кому-то интересно, давайте кооперироваться.


Каков план?

  1. На текущий момент мы набросали сырой-пресырой концепт. Внимание, это точно не рабочий код, он толком не тестировался!
  2. Дальше надо протестировать текущий код, довести его до рабочего состояния в текущем виде. По возможности, пока что не вмешиваясь в код конкретных «виджетов». Пусть пока местами не совсем красиво и с кучей компромиссов, но это будет уже рабочий плагин с новой структурой ядра и старыми «виджетами».
  3. Затем надо подготовить документацию, описание стиля программирования и прочие организационные моменты.
  4. Далее перепилить все «виджеты», попутно дорабатывая структуру ядра плагина.

До этапа № 3 никто нам помочь программированием не сможет. Нужны стандарты и документация, что позволит далее подключиться без боли большому количеству людей на 4 этапе.


Но что сделать прямо сейчас?


Поддержать рублём

Сейчас мы вложили своих 70 тысяч рублей, но больше прямо сейчас не можем. Чтобы быстро дойти до 4 этапа, призываю вас поддержать проект рублём (там простая форма, можно отправить с карты любого банка). Сколько надо собрать денег? Да не знаю, честное слово ¯\_(ツ)_/¯

Страна должна знать своих героев и чтобы подстегнуть интерес — все частные лица и компании, отдавшие свои кровные на поддержку общего дела будут «высечены в камне». По желанию, на страницах плагина (и в GitHub тоже) и будут размещены фотографии/логотипы, имена/названия и ссылки на всех доноров. Навсегда. То же самое будет во всех статьях по новому ManagerManager. Если вы разработчик или студия — это реклама и уважение сообщества. Если вы не разработчик, но ваш сайт на EvolutionCMS — то там скорее всего используется ManagerManager и мы вам тоже рады, это вклад в общее дело и выиграют от этого все. Для бизнеса несколько тысяч или даже десятков рублей — это копейки, а пользы будет много и навсегда: вашим людям будет проще работать, доработки сайта будут делаться быстрее и все вложенные средства окупятся слихвой.

Пожалуйста, при пожертвованиях подписывайтесь, чтобы я мог с вами связаться, поблагодарить и увековечить (в идеале — ссылку на контакт в Telegram, но подойдёт что угодно).

Если мы с вами добьёмся успеха, плагин ManagerManager навсегда останется бесплатным и открытым.


Распространить информацию

Если вы разработчик или студия — попробуйте замотивировать клиентов пожертвовать копейку на благое дело, ведь им это тоже выгодно! Доработки их сайтов станут дешевле. Скиньте ссылку на пост или просто скопируйте какую-то его часть, если так удобнее.

Запостите ссылку на пост в соц. сетях, профессиональных сообществах, форумах, у себя на сайте — да где угодно.

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


Помочь перевести пост на английский

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


Выразить желание помочь с программированием в будущем

Постараюсь организовать всё так, чтобы всем участвующим в процессе было максимально просто и комфортно. Сейчас важно заявить о себе, чтобы мы чувствовали, что дело нужное и команда будет. Пишите мне в Telegram (@Ronef).


Выразить желание помочь с тестированием будущего продукта

Нам будут нужны тесты, много и разных. Заявить о вашем желании быть бета-тестером нужно для того же — чтобы мотивировать разработчиков. Также пишите мне в Telegram (@Ronef).



Если всё это зайдёт и сообщество нас поддержит — с радостью поспособствуем экстраполяции всего доброго и светлого на всю нашу любимую EvolutionCMS, от чего все только выиграют. Если конечно высокомерие, гордыня и интриги не помешают. Не хочу ни про кого говорить плохо, но, увы, сообщество сейчас — как дети малые :-) К примеру, один из ведущих разработчиков ни разу в жизни не использовал ни один наш продукт только потому, что они имеют префикс «DD» :-| Его это напрягает, блин. Вместо того, чтобы развивать совместно общими усилиями продукты, люди предпочитают изобретать велосипеды. Я вкладываю столько своих ресурсов и ресурсов команды на благо общественности, что хочу иметь возможность подписывать свои продукты и не считаю это нарциссизмом, а дурацкое ребяческое соперничество и отношения к коллегам, как к конкурентам, считаю глупостью и не дальновидностью, растлевающей сообщество. Очнитесь, нам нечего делить! Мы конкурируем не между собой, а с Битриксом, который сожрёт нас, не моргнув, пока мы тянем канат в 120 разных сторон. Да почти сожрал уже, EvolutionCMS знает полтора землекопа, а заказчиков приходится уговаривать. Вот оно, чего мы добились! Надеюсь, все мы можем повзрослеть и двигаться дальше, со своей стороны готов идти навстречу и совместными усилиями менять климат на позитивный лад. Прошу прощения, если кого обидел или чем-то задел, не этого я хотел добиться ✌

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



Почётные доноры

Благодаря этим прекрасным людям и компаниям плагин ManagerManager будет развиваться дальше. Для всех нас. Давайте дружно скажем искреннее человеческое спасибо людям, сознательность которых заслуживает похвалы!

Первого донора, руководителя студии «Dva Kota» пришлось даже уговаривать дать разрешение на размещение этой благодарности, он говорил: «Ильяс, да не надо, я от души же! Не для рекламы же скинул благодарность, а потому что твои решения помогли мне заработать». Однако, я считаю, что сообщество должно знать своих героев в лицо!