Был в Laravel Idea кусок кода, который раздражал. 150-200 строк некрасивых, которые разбирали все возможные вариации Route::resource(<тут names, only, except>)->only()->names() подобную вот конструкцию и получали из нее список имен роутов. Я несколько раз думал рефакторить этот кусок, но всегда убеждался, что там все слишком завязано друг на друге и нормально отрефакторить нереально.

Ситуация сильно поменялась когда пришлось добавлять абсолютно такой же саппорт для пакета роут-атрибутов от Спати. Там логика один в один, ибо они тупо редиректят логику в обычные роуты. И внезапно оказалось, что рефакторить можно! Быстро появилась куча вещей, которые есть и там и там. Выделил класс, который занимается обработкой общей логики. Все сильно упростилось и в процессе нашел пару багов(там сильно краевые случаи, но тем не менее).

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

Вот во что отрефакторился тот 150-200строковый кусок. Красиво!

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

PHP (Rus) — https://t.me/addlist/R7i3akzlB2kwZTMy
PHP (Eng) — https://t.me/addlist/yNksksLVT6M5NGEy

Давно хотел перевести книгу https://github.com/adelf/acwa_book_ru обратно на английский и нашел идеального переводчика - ChatGPT. После него править почти не надо. Решил еще разок проревьюить её - добавить всякие новые фичи, которые появились в PHP за эти 3-4 года. Ну и дописать пару мыслей. Приведу тут пару отрывков нового.

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

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

Выделение слоя приложения - весьма ответственный шаг и причина должна быть серьезной. Их всего две:

1. Разные интерфейсы к одним и тем же действиям (Web, API, Console, различные боты). Тут вынесение общей логики просится само.
2. Разросшиеся и сложные логики обработки веб-запроса, например, и бизнес-логики. В данном случае разделение логик по разным местам может заметно улучшить связность кода. Как правило, это ведет к повышенной багостойкости кода.

PHP-народ сегодня активно обсуждал нововведение в PHP 8.3 - #[Override] атрибут. Такой же как в Java. Он позволяет указать тот факт, что этот метод перекрывает метод у класса-родителя. Подробнее по ссылке - https://t.me/sergei_predvoditelev/33

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

Поговаривают, что в 9 или 10 версиях это может стать обязательным. Но обязательным оно наверняка станет одновременно и с обязанностью в классе-родителе указывать то, что метод может быть переопределен. Как в Котлине, Яве и куче других языков. В котлин если метод неабстрактный, но может быть переопределен в потомках, надо указать ключевое слово open. open fun method() и тогда в классе-потомке можно будет его переопределить override fun method() - тот самый override.

Для чего, кроме строгости, это нужно? Для оптимизации вызовов этих методов. Методы, про которые мы знаем точно, что их никто не перекрывает, вызывать легко. В давние стародавние времена я разбирался с тем, как выглядит вызов обычного и виртуального(так назывались те, которые можно перекрыть) методов в C++ коде(от C++ Builder компилятора). Ассемблер код вызова простого метода(забьем на параметры) - call method <aдрес где сидит код того метода>
Вызов динамического - найти в обьекте ссылку на таблицу виртуальных методов, там найти указатель на нужный метод, и вызвать метод. Для тех времен это была серьезная оптимизация, поэтому виртуальными старались делать только те методы, которые надо.

В PHP все методы виртуальные - их можно перекрыть. Но если ввести обязательное указание виртуальности метода(open/override или както иначе), то можно получить более оптимальный опкод. Насколько большим будет прирост на реальных проектах судить не берусь. Понимаю только, что это очень серьезный BC - ломает совместимость прям сильно. Сомневаюсь, что на это пойдут.

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

Картинку взял с корейского обьявления. Там логотип Laravel Idea кажется самым главным)

Пятничная мелкая тактика. Сделал тут мини-рефакторинг и решил выложить. Вначале присвоение isEnabledAndVisible казалось незаметной мелочью и проблемы видно не было. Но когда метод подрос, стало понятно, что это все-таки две логики: посчитать нужно ли показывать экшен и "присвоить" результат. Из-за лаконичности Котлина второе не казалось чем-то важным.

Вообще, isEnabledAndVisible это котлиновский сахар. На самом деле он превращается в вызов Java-метода setEnabledAndVisible, который сам по себе просто сахар над вызовом двух методов.

public void setEnabledAndVisible(boolean enabled) {
setEnabled(enabled);
setVisible(enabled);
}

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

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

Недавно сделал рефакторинг, который выглядит дико даже для меня, но в итоге, подумав, вполне нормальный.

Был класс, который размещал два компонента в окошке. Обычно это label и поле к нему. Но иногда там был только label и тогда field было null. И наоборот могло быть тоже. В итоге была огромная конструкция где проверялись все возможные варианты - кто null, кто не null. А когда добавились еще параметров стало просто невмоготу.

Что я сделал? Вместо одного класса FieldPair, в котором оба поля могли быть null, я сделал три. OnlyLabel, OnlyField and FieldPair. И в каждом только ненулевые компоненты. И все стало так сильно проще! Я даже мелкий баг нашел сразу же.

https://gist.github.com/adelf/bf9e8d6d094e5c01c24689e4c92ce9c5

Простой пример реального Value Object на Котлин(из кода Laravel Idea). Скрывает свое содержание. При сравнении не учитывает регистр. Ну и еще пару фич в нем. Раньше все в строке хранил в формате "схема.таблица", но стало сложно управляться. Теперь намного проще.

Благодаря equals&hashCode, Java/Kotlin умеет их использовать в качестве ключей массива(Map) и таблички в разных регистрах спокойно работают. Удобно.

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

Я сидел там у админов и не верил в происходящее. Номер мой тест получил 347. А система огромная! Значит тестов почти не пишут. Понятно почему)

Мимо проходил знакомый, мы поздоровались и я сказал "Вот коллегой твоим стал, но видимо ненадолго"

О трудностях разработки плагинов. Я начинаю поддержку новой мажорной версии шторма сразу как только выходит EAP. Соответственно ориентируюсь на ранние релизы. Но где-то между 2023.1 и 2023.1.5 они переместили классы в другой неймспейс) Это нормально сделать между мажорными версиями, поскольку эти классы помечены как экспериментальные, и что они могут меняться. Но не между минорными же! Такое очень сложно поддерживать...

Здесь пришлось просто не использовать эти классы. Отложить их до 2023.2 и надеяться, что такого не случится еще разок

class FractalTransformerGenerationTest: BaseAppModuleSystemTestCase() {
init {
addPackageDependency<FractalPackage>()
addDependency(EloquentModelsDependency())
}

У меня сильно разрослись тесты и понадобились некоторые бест-практис, чтобы навести порядок. Тестам часто нужна какая-то инициализация. Она выполняется в setUp/tearDown. Если тестов с общей инициализацией много - то убирают дублирование путем выделения базового класса и вынесения этой инициализации туда.

До определенного момента я так и делал, а потом понял, что иногда нужны разные инициализации. Вот здесь мне нужно подключить определенный пакет(Fractal) и некоторые Eloquent модели к проекту. Плюс там BaseAppModuleSystemTestCase тоже не просто так стоит)

Пора применять композицию вместо наследования. Сделал простой интерфейс

interface TestDependency {
fun setUp(fixture: CodeInsightTestFixture)
fun tearDown(fixture: CodeInsightTestFixture) {}
}

ну а в самом базовом тестовом классе:

private val dependencies = mutableListOf<TestDependency>()

fun addDependency(dependency: TestDependency) = dependencies.add(dependency)

override fun setUp() {
super.setUp()
...

dependencies.forEach { it.setUp(myFixture) }
}

override fun tearDown() {
dependencies.forEach { it.tearDown(myFixture) }

super.tearDown()
}

Очень удобно стало. Намного меньше мусора теперь в тестах. По хорошему надо и этот BaseAppModuleSystemTestCase превратить в тестовую зависимость, но пока лень.

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

Испанский стыд - это самое точное описание того, что чувствую.

Это примерный уровень понимания всеми этими AI кода, в котором хоть какая-то крупица абстракции есть.

Код, который они генерируют, соответственно, тоже плоский, без глубины. Ибо настоящего понимания нет и долго еще не будет.

Технологическая сингулярность все еще далека.

fun getSpatieToolPackageName(methodReference: MethodReference): String? {
    return getNameMethodCall(methodReference)
        ?.getParameter(0)
        ?.getStaticStringValue()
        ?.removePrefix("laravel-")
}

Все чаще и чаще пишу в таком вот, функциональном стиле. Кратко, красиво, и комменты не нужны. Умная IDE типы возвращаемые серым справа показывает...

Для этого, правда, нужно, чтобы язык умел к любому чужому классу или интерфейсу написать метод. Kotlin и C# это умеют. Просто пишешь чтото вроде

fun String.removePrefix(s: String) { return this.что-то там... } 

и работает.

Когда внезапно осознаешь, что твое приложение - многопоточное.

Прилетает в sentry такой эксепшен:

java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0
    at java.util.ArrayList.add(ArrayList.java:455)
    at java.util.ArrayList.add(ArrayList.java:467)
    at com.laravel_idea.plugin.translation.fetching.b.b.a(b.java:24)

Я просто вызываю add() в стандартнейшем классе для списков и получаю странную ошибку. Но крайне редкую. Для тысяч юзеров всего 2 за неделю. В многопотоковом программинге я ноль, но это оно самое. Два потока одновременно пишут в один список и получают ошибку. Вчера еще более странную ошибку находил, с той же самой причиной.

java.lang.ClassCastException: class java.util.HashMap$Node cannot be cast to class java.util.HashMap$TreeNode (java.util.HashMap$Node and java.util.HashMap$TreeNode are in module java.base of loader 'bootstrap')
    at java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1986)
    at java.util.HashMap$TreeNode.treeify(HashMap.java:2102)
    at java.util.HashMap.treeifyBin(HashMap.java:770)
    at java.util.HashMap.putVal(HashMap.java:642)
    at java.util.HashMap.put(HashMap.java:610)
    at com.laravel_idea.plugin.translation.fetching.b.b.a(b.java:16)

Если данные приватные и пишутся под строгим контролем одного класса, чинить это несложно. Простые конструкции synchronized и все должно быть ок. Также, есть специальные thread-safe структуры данных(ConcurrentHashmap, ConcurrentList). Но внутри у них либо тот же syncronized, либо еще хуже, так что для меня проще так.

synchronized(this) {
    vendorData.add(data)
}