Завтра утром в 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.

Всегда старался уделять время таким вот фичам. Не сказать, что сэкономят много времени, но некий вау-эффект(“Ого какой софт умный!”) - он важен.

Переработал первую главу книги. Она стала сильно структурированнее, ну и добавил довольно много всякого материала. Даже подглаву про преждевременную оптимизацию. Странно, что я это не описал ранее. Вот небольшой отрывок из добавленного текста:

Замечаете один и тот же шаблон? Разработчик принимает неудачное решение, которое кажется удачным поначалу. По мере усложнения проекта это решение все больше и больше усложняет жизнь. Вместо того чтобы собрать волю в кулак и признать, что решение было плохим, разработчик не исправляет его, а исправляет лишь его последствия, что делает код все хуже и хуже. Одним из главных умений разработчика является то шестое чувство, когда начинаешь понимать, что твой код "сопротивляется" изменениям - не хочет меняться легко и плавно, а требует все больше и больше усилий, заплаток и сделок с совестью для реализации таких изменений. Почувствовав такое сопротивление, надо искать его причины, найти те самые неудачные решения в дизайне кода, и исправить их. Это сделает проект намного более податливым к следующим изменениям. Именно это шестое чувство и позволяет большим проектам долго оставаться на плаву, не превращаясь в то самое "легаси", которого мы все стараемся избежать при приеме на работу.

Если вдруг кто-то захочет почитать главу - https://github.com/adelf/acwa_book_ru/blob/master/manuscript/1-bad-habits.md

Позволю себе в пятницу небольшой более казуальный совет. Очень помогают в некоторых ситуациях мульти-курсоры. А делаются очень просто. Кликнуть Option(Alt). Потом еще разок, но уже зажав клавишу, стрелкой вверх или вниз плодим курсоры.

Каждый курсор весьма самостоятельный: у каждого свой буфер для копипаста и это позволяет даже сложные вещи делать. Весьма регулярно пользуюсь.

Мотивация путем уменьшения неопределенности

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

Реализуй эту фичу или пофикси баг - далеко не всегда четко определенные цели. У фичи могут быть полно деталей, а у бага несколько возможных причин или целый лабиринт вероятностей. А еще бывает назначают кучу тасков и сложно определиться какой делать 🙂

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

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

P.S. Другой очевидный способ уменьшения неопределенности - бить большую задачу на маленькие.

Ничего нет более постоянного, чем временное?

Отмазка хреновеньких проггеров, которые сделали кое-как и забыли. Либо префекционистов-вредителей, которым надо сделать сразу все правильно и красиво.

Намного проще сделать таску как можно более простым способом, немного(!) подумав о возможных изменениях и насколько тяжело будет в будущем поменять. А когда будущее настанет - найти в себе силы, мужества, смелости, но скорее всего банальной мотивашки реально изменить “временное” решение под новые условия.

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

Кому заходят ИТ-баттлы, то недавно вот выпустили - https://www.youtube.com/watch?v=4_Q1ck1gRx0

“PHP: Фреймворки против Битрикса” Саша Макаров отбивается от битриксоидов. Прослушал немного по диагонали. Аргументы в стиле “а в Yii всё через массивы и вообще никаких бест практис”, “рынок требует Битрикс”(видимо российский рынок имеется ввиду) и т.д., а потом они ушли обсуждать фронтенд (что как-то странно соотносится с темой).

Вообще не понимаю идею генерации changelog из гит коммитов. Она везде проскакивает. Есть даже готовая команда в шаблоне для плагинов от JetBrains. Это для совсем уж ленивых. Текст в коммите - для команды продукта, чтобы было понятно что и как конкретно сделано. Текст changelog - для юзеров. Если юзеры - это такие же php-програмисты, то наверно им будет понятен текст коммитов для юзаемого ими php-пакета.

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

Другой вариант - генерить из тасков багтрекера. Это уже чуть более солидно, так делают сами JetBrains. Пример. Но это тоже для ленивых. Мало кому из юзеров интересно такое читать. Поэтому они делают более user-friendly страницы типа этой - https://www.jetbrains.com/phpstorm/whatsnew/

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

Скопировал if, чтобы немного изменить поля и обратил внимание на это предупреждение. В очередной раз меня поразил ум IntelliJ IDEA.

Она поняла что если уcловие сверху выполнится, то defaultPath поменяется и такое же условие уже всегда будет false. Иногда это может помочь поймать очень неявные баги. Я помню где-то год назад смотрел доклад Тагира Валиева, который главный там по этим предсказаниям и умным инспекциям. Он рассказывал про случаи когда народ жаловался на эти инспекции, они садились и вместе выясняли, что это реально в коде баг.

Помню когда скринил этот класс сюда было много критики, что все методы начинаются как isSomething(). “Не по английски”. Исправил. Доволен)

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

Или того, что тебе больше нечем заняться.

Одним из стабильных холиваров среди разработчиков является - как хранить деньги. Либо какой-нибудь decimal(*,2): доллары - целая часть, центы - дробная, либо integer - просто количество центов.

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

Однако, при работе с целыми числами-копейками надо быть весьма осторожным. Их очень легко принять за рубли или доллары. Вот недавно волосы дыбом встали от таких коммиссий. 1750 долларов за перевод - звучит страшно). А на самом деле это 17,5 доллара. Вообще, надо иметь хороший Value Object-класс Money и через него работать.

P.S. Это баг в приложении одного банка. Некритичный, но неприятный)