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

А сегодня я работаю над кейсом посложнее - 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”, но это больше прикольно, чем реально полезно.

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

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

Берем камень и отсекаем все лишнее

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

Не так давно стал в программировании придерживаться того же. Вот встречается задача, которая не решается в лоб: не сразу получается продумать где какая логика будет лежать и как обьекты будут друг с другом общаться. Раньше я принимал это как вызов! Тратил кучу времени, строя в голове великие конструкции, эпохальные ООП-дизайны, которые частенько оказывались плохими на практике. Я помню как мы могли часами, а иногда и сутками “продумывать дизайн” на первой работе.

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

Главный недостаток этого метода - нужна дисциплина, чтобы не бросить зверя как он есть 🙂

Если все еще используете вкладки редактора в шторме или других средах от JetBrains, то рекомендую попробовать от них отказаться. Года три назад я их выключил ради эксперименту и с тех пор не включал.

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

Вместо этого можно использовать Ctrl(Cmd)-E и просто выключить вкладки за ненадобностью. В том же окошке очень хорошо работает поиск. Крайне рекомендую.

Убрать вкладки: Preferences(Settings) | Editor | General | Editor Tabs | Tab placement: None.