​​#MoreView #17 | Адель Файзрахманов - автор acwa_book и разработчик Laravel Idea

Свои первые интервью я брал у PHP разработчиков и решил вспомнить как оно. В этот раз буду брать интервью у Аделя Файзрахманова — автора acwa_book и разработчика Laravel Idea.

Я успел с ним немного пообщаться на PHPRussia, когда объявлял его доклад. Стало крайне интересно пообщаться поподробнее с человеком, который делает крайне полезный плагин для PHPStorm и живет исключительно за счет этого плагина.

Заходите на стрим в субботу, 24 июля, в 15.00 по Москве и задавайте свои вопросы. Автору лучшего вопроса, традиционно, пицца в любую точку мира.

До встречи!

Ссылка на трансляцию: youtu.be/H1W5GmX4hvc

Если вдруг кто не знает чем себя занять сегодня в 3 часа дня по Москве, то можно посмотреть интервью Антона Морева со мной онлайн, каверзные вопросы позадавать.

Собираемся говорить про жизнь, про книжку, про Laravel Idea (Антон вроде не ларавельщик, поэтому будет спрашивать больше про плагин как бизнес). Может еще какие темы появятся.

Сегодня показательный кейс у меня был. Есть объект, для работы которого требовалось Знание. И Знание это было реализовано прямо внутри объекта, потому что никому другому оно не требовалось. Если конкретнее, то реализация той подсказки, которая на картинке выше. Знание это в том, чтобы найти все поля, которые можно подсказать в реквесте. Там надо либо найти правила валидации в этом методе, либо найти кастомный реквест и у него вытащить поля.

А сегодня я работаю над кейсом посложнее - https://github.com/laravel-idea/plugin/issues/351. Там тоже понадобилось это Знание. И возник соблазн немного модифицировать тот, первый объект, чтобы он поделился этим Знанием с новым. Но я вовремя спохватился. Это настолько явный индикатор того, что надо это Знание вытаскивать в свой, отдельный объект, что лучше и не придумать. Всегда, когда вы себя ловите на подобном, надо обязательно подумать о Extract Class рефакторинге и композиции.

Я завел канал, где буду в свободной форме делиться разными фичами Laravel Idea, которые разрабатываю сейчас. Там же можно их пообсуждать, покритиковать и т.д. Только что опубликовал там информацию про новый релиз.

https://t.me/laravel_idea

Я решил поспонсировать Laracon Online - https://laracon.net/. Сложно конечно предсказать выхлоп... Чтобы показать своё видео там нужно от 6 килобаксов выложить. А я немного лайтовее участвую. Баннер, плюс упоминание в твиттере + скидку свою дать. Посмотрим.

Мне выдали 5 билетов. Один себе возьму. Остальное готов разыграть. Кто реально хочет послушать эти доклады на английском прошу - https://forms.gle/jx2SJeT17BUd8GeB7

В 22:00(мск) 30 августа сделаю выборку в гугл таблицы. И как-нибудь рандомно выберу победителей.

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

Например, "Каждая система в конечном счёте отстой, смиритесь с этим". Да! Если это не hello world, то всегда в проекте будут места с запашком, а иногда и совсем уж выгребные ямы. Даже если проект считается хорошим. В каждом большом проекте есть места, в которые не заглядывают месяцами, а то и годами. Они работают стабильно, своё дело делают и если внутри говнокод, то это никому не мешает. Смысл рефакторить такое? Вот когда это место начинает активно меняться, тогда говнокод и начинает жрать драгоценное время. Именно такие моменты хорошие спецы чувствуют и начинают рефакторинги.

Один из плюсов Котлина легко превращается в минус. Я про "почти все операторы возвращают значения". Вот конкретно из-за этого участка кода я минут 30 не мог понять почему всё работает не так как надо.

Всё дело в забытом "return" перед when. Кстати, в PHP тоже добавили match - вполне могут быть такие же коллизии.

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

Появились проблемы с доведением дел до конца. Вместо того, чтобы делать крутые революционные фичи, я часто погружаюсь в мелочные таски и увязаю в них, ибо их сотни. Летом думал в сентябре выпускать релиз 5.0 с кучей осязаемых фич… В итоге уже не уверен, что даже в январе смогу выпустить 🙁 Ни одной статьи, ни одной видюшки за год не записал. Уровень прокрастинации сильно подрос, постоянно что-то откладываю на будущее(в черновиках штук 10 статей).

Давно пора обновить документацию, сделать видео-туториал по плагину, но как программист-недобизнесмен, приоритет отдаю фичам, чем “всякой ерунде”. И нехватка этой “ерунды” начинает сказываться. Куча жалоб на то, что люди тупо не знают всех фич. Думаю, в том числе и поэтому рост продаж замедлился. В декабре 2021 продажи выросли в два раза по сравнению с декабрем 2020, но всего на 20% от марта 2021. Рост этот вполне можно назвать органическим, поскольку единственный промоушен - это твиттер, в котором пишу новые фичи, и спонсирование Laracon Online.

Поэтому в 2022 в первую очередь надо будет заняться тем, что программисту делать ну никак не хочется: документацией, видео-туториалами, сайт переделать, чтобы народ перестал думать, что если поставить laravel-ide-helper и старый плагин Laravel к шторму, то это будет почти как Laravel Idea. Еще надо будет и SEO, и может какие рекламы покрутить… такая скукота, но если уж начал строить бизнес, то надо строить.

Есть планы еще один платный плагин выпустить, на этот раз уже для всех языков и IDE от JetBrains, только надо подумать о модели монетизации. Она наверняка будет freemium, но надо придумать при каких условиях надо за него деньги брать и сколько брать. Весьма непростое решение и нет особо данных на что опереться при обдумывании. Опять придется тыкать пальцем в небо. И как-то выкраивать время!

В общем, с наступающим новым годом 🙂

Проект Laravel Idea стал большой и неудобно стало в навигацию между кодом и тестами. Захотел запретного - тесты держать как можно ближе к коду(прям в той же папке). Мысль это далеко не новая. На многих крупных проектах стараются код, который изменяется одновременно держать поближе друг к другу и тестов это тоже касается. Но с тестами есть очевидная проблема разделения - на продакшен они не должны попадать. Что в пхп-пакете например, что в сборке плагина.

В твиттере вон дискуссия на эту тему - https://twitter.com/frankdejonge/status/1482652993753333761 . Для PHP-пакета это довольно просто делается - https://github.com/thephpleague/flysystem/blob/3.x/.gitattributes#L29, но топорно. (“Просто, но топорно” - это вообще девиз многих PHP решений). Назовешь случайно класс StubbornUnicorn и он не попадет в экспорт пакета.

Для Явы/Котлин решение не особо простое, похоже. В лоб не загуглил. Поищу еще.

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

Плюс это возможность прокачать очень редкий навык - эволюционного улучшения проекта. Сказать “все говно, давайте перепишем” может каждый. А вот далеко не каждый может эффективно развивать легаси систему, оставляя ее работоспособной в течении всего этого развития. Находить слабые точки и варианты их “усиления”. Не переставая при этом делать новые фичи.

Ключевое слово “эффективно”. Лениво улучшать тоже все могут 🙂

Я частенько говорю, что ООП в его очищенном от любой процедурщины виде превращается в аналог функционального программирования. И вот эти куски кода плагина отлично это показывают. Вся логика здесь строится из комбинаций разных обьектов друг с другом, и всё выглядит как комбинация функций в ФП. Эдакое программирование конфигурацией.

О чем то подобном писал и Егор Бугаенко, но он в свойственном ему максимализме утверждал, что весь код должен быть написан таким образом. Чушь конечно. В любом большом проекте всегда найдется место ООП, ФП и процедурщине. И когда один из этих трех слишком одеяло на себя перетягивает - это ни к чему хорошему не ведёт.

Завтра утром в 11 по москве будет стрим про итоги 2021 года с результатами большого опроса PHP-программистов. Свыше 3000 ответов. Будет разыграно куча мерча и других подарков. Я лицензию на Laravel Idea добавил в общак(как же легко дарить нефизические, легко воспроизводимые, подарки).

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

Ссылка на страницу - https://phpcommunity.ru/2021-php
Ссылка на будущий стрим - https://www.youtube.com/watch?v=Nx39a7n9KIQ

Друзья, сегодня Юлия Insolita ушла из жизни.

Юля была активным участником нашего PHP-сообщества, помогала со стримами, матапами, конференциями и до последнего дня помогала делать PHP-дайджест.

Последние несколько месяцев Юля боролась с болезнью, но к сожалению победить ее не получилось.
Пусть земля будет Юле пухом.

Друзья, берегите себя и близких, будьте здоровы.

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

С одной стороны все верно. С другой - никогда не надо забывать, что все в нашей отрасли “зависит от проекта”. Для проекта на поддержке на второсортной галере мои действия были бы преступлением. Для простого сайтика - наверно тоже. Для моего продукта(Laravel Idea) - нет.

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

Мораль - всегда все зависит от проекта и каждое решение надо оценивать не только в краткосрочной, но и в долгосрочной перспективе.

Если кого интересуют детали, то у меня было несколько источников информации о том, где и под каким неймспейсом и с какими расширениями файлов лежат view-файлы. Настройки плагина, код в ServiceProvider-классах и еще ide.json файлы. Все это лежало в разных частях кода и как-то умело работать. Небольшая фича - вызов View::addExtension() метода в сервис провайдере, который добавляет расширения файлов, которые Laravel считает вьюшками. Хотелось его подхватывать самому, чтобы юзеру не надо было лазить в настройках. После рефакторинга вся необходимая информация про вью-файлы аккумулируется из разных источников в один обьект, который знает про вьюшки все и умеет делать все необходимое.

Объектное ориентирование в массы! Даешь Объекты-значения вместо примитивов!

Котлин, который поддерживает value классы, позволяет делать это, не теряя ни грамма производительности на создание обьектов. Если все данные обьекта - это одна строка, число, или другой примитив, то так можно.

Рефакторю немного Laravel Idea…

класс, кстати, выглядит весьма чистенько.

Бывает иногда - один if поставишь маленький, потом второй такой же недалеко. Потом true или else части понадобились в другом месте. Все идет на уровне 1-2 строк, и кажется, что все под контролем. Потом эти два if появляются в другом месте, но тела у них немного другие. Не каждый опытный глаз обнаружит проблему, особенно когда все разбито на методы и эти однострочные if и else глаза практически не мозолят.

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

Все эти куски логики - отдельные обьекты. If - это либо фабрики, либо декораторы. Как только все это раскидаешь по правильным обьектам - станет сильно легче дышать.

Признак будущих проблем: два и более метода взаимодополняющих друг друга, или используемые в похожих ситуациях, в отличие от других методов класса/интерфейса. Если они появились в абстрактном классе или интерфейсе и начали множиться по наследникам - жди проблем. Решение: красиво выделить их в отдельный объект или объекты.

Такое чувство, что люди очень странно понимают слова “more expressive”. Первый вариант четко говорит о том, что будет возвращен обьект редиректа на такой-то роут. А Нуно здесь очень понравилось “return to_route”, но это больше прикольно, чем реально полезно.

И, конечно, комменты в стиле “ОГО! Я теперь могу писать на несколько символов меньше!”. 🙊 Сразу видно, кто использует продвинутые средства разработки, а кто нет )

Лара-коммунити частенько так удивляет…