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

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

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

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. Это баг в приложении одного банка. Некритичный, но неприятный)

Купил я как-то молока в 4-литровой бутылке. Думал так удобнее будет. В итоге, моя 48кг жена заставила меня наливать из этой бутыли при каждой необходимости, ибо ей тяжело. Мораль проста: прежде чем принять решение - подумай о других членах команды)

Когда я работал на галере, пришел в новую команду и там сразу же мне говорят “Слушай, у нас тут проект один есть… его написал реально крутой чел, но из команды уже ушел. И у нас никто не может код понять, а задач для него уже набралось прилично”. Я посмотрел, там C#, монады верхом на функторах и безграничная функциональщина. Данные красиво летают от функции к функции и получается результат. Но понять код - это настоящий challenge.

Вероятно, примененный подход был хорош и подходил к задаче идеально, но bus factor для этого проекта равен 1. А когда человек ушел - проект стал неподдерживаемый. Не всегда надо тащить самые продвинутые техники или игрушки, с которыми хочется поиграть(монады) в реальный проект.

P.S. Мне конечно понравилось тогда ковыряться и задачи делать для этого проекта, но я запомнил это как одно из самых деструктивных решений для команды.

P.P.S Некоторые поняли этот пост как “не тащи ничего нового в проект”. Нет. Тащить надо, но подумав как это адаптировать в команде, а не наплевав на них)

https://t.me/tg_5minphp/1008

Ох как любит народ оптимизировать такты процессора и байты оперативки. Особенно, когда это не нужно) На реальном хайлоад веб-проекте оператор new будет где-то в конце третьего десятка причин тормозов. Там тормоза в основном из-за I/O - базы данных, кеши, диски. Банально закешить грамотно запрос будет в миллионы раз эффективней, чем убрать какой-нибудь new.

Я до сих пор с содроганием вспоминаю как смотрел видео, где один из core-разрабов yii2 делал метрики и доказывал, что код без интерфейсов выполняется на наносекунды быстрее, поэтому “интерфейсы не используйте” (https://youtu.be/x7-G4tHFSj8?t=1809 - вот здесь).

Бывают, конечно, задачи называемые “числодробилками”, где I/O операций мало, зато куча вычислений. Но это весьма и весьма нетипичная для PHP задача и часто ее выделяют и реализуют отдельно на каком-нибудь go (отсюда и мода на него в последние годы).

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

Сделал одну вот фичу и сижу думаю: а что мешало ее сделать давным-давно?

https://t.me/laravel_idea/38

ChatGPT - новая разработка от OpenAI. Такого логичного обьяснения от человека сложно получить. Все еще уверены, что писать код - это перспективная профессия?)

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

Начал потихоньку готовить код Laravel Idea к работе в команде. CI с прогоном тестов и проверкой на совместимость со штормом уже давно стоит. Второй по важности пункт - натравить на проект проверятор стиля кода и тоже гонять его в CI. Несмотря на кажущуюся малую полезность, для командной разработки это чуть ли не must-have. Договориться разок о стиле(а то и деспотично назначить самому 😈), прописать в конфиге стайл-фиксера, и все. Если поддержка в IDE есть - совсем шик.

В пхп есть php-cs-fixer. В СиШарпе помню лет 10 назад был StyleCop. Для Котлин есть detekt.

Первый прогон - 2900+ ошибок. Борюсь с ними сейчас. Довел до 428.

Встретил тут один каламбур, отчего и решил написать этот пост. Function getModelFqnDeeply is nested too deeply.

Это я фиксил те 2900+ ошибок стиля, которые нашел detekt. Больше половины - автоматические замены(форматированием IDEA и маленьким своим пхп-скриптом), но и самому пришлось поработать.

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

Теперь все иммутабельное, пересчитывается на лету. Вместо codeGeneration.baseClass, теперь codeGeneration.getBaseClass(settings). Со стороны можно сказать, что стало хуже, но теперь все явно(нужны настройки, чтобы получить базовый класс) и цикл жизни простой - это неизменяемый объект с дефолтными значениями, но перекрываемыми из настроек.

На душе стало приятно. Но все это время меня преследовало сомнение - а стоит ли оно того? Наша профессия очень далека от прямых денег. Если продажник вместо работы два дня будет стол свой протирать - бизнес быстро заметит просадку. Так же как и более эффективные тактики.

Проггер же может два дня стилизовать код, делать рефакторинг и уверять, что это принесет плоды в будущем, а как проверить? Код в деньги превращается очень медленно. Поэтому, крайне сложно составить эффективные метрики работы программистов. Я пока не видел ни одной рабочей.

Помните выражение "тесты как документация"? Типичный случай сейчас был.

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

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

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

В твиттере третий день обсуждают этот код. Его выложили как откровенно плохой, но куча народу написало что он практически идеален.

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

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

Пишу на Котлине и радуюсь null-safety. Везде он прикроет, не даст получить NullPointerException и все прекрасно. Опасная наивность. Нашел сегодня баг, где я спокойно складываю пустые строки, и получаю строку “null”! Причина в том, что первая строка оказалась null, а вторая - “”. Случалось это редко, поэтому нашел только сейчас, спустя три года.

Какая тут мораль? Доверяй, но проверяй? Не. Лучше так: и эти люди иногда катят бочку на PHP?!

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

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

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

Конкретно мой пример: chess.com дает бесплатно порешать 5 шахматных задачек. Когда я попытался решить шестую он, вместо нормальной ошибки стал выдавать “Insufficient permissions” и больше ничего! Ладно я сразу понял прикол, но рядовой юзер вообще в шоке наверно был)

P.S. Исправили уже сегодня. Молодцы.
P.P.S. Мне не жалко премиум купить, но я тогда по полдня буду эти задачи решать) Покупал уже…

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

Получила развитие ситуация с негативом Тейлора Отвела к разработчикам, использующим бренд Laravel в своих продуктах.

Сегодня с утра в американских газетах было объявлено о судебных исках компании Laravel против множества частных лиц и компании. Их обвиняют в нарушение прав интеллектуальной собственности на торговую марку Laravel в сети Интернет. Известно, что обвинения предъявлены: Spatie — у них под сотню пакетов, использующих бренд Laravel (Laravel Permission, Laravel Ignition, Laravel Medialibrary и т.д.), Caleb Porzio — за Laravel Livewire, Spartner — Laravel-Excel, а также множеству других лиц и компаний.

Первоначально было известно и о Barry vd. Heuvel, но, как говорят, он успел переименовать свои пакеты в Debugbar for Laravel и IDE Helper Generator for Laravel и его исключили из списков.

В рунете пока известно о двух людях, получивших иски. Это Andrey Helldar за Laravel Lang и Adel за Laravel Idea.

Общую сумму ущерба Отвел оценил в десятки миллионов долларов, заявив: «Люди, которые используют подобные поделки, думают, что их написал я. Ведь они называются Laravel. А это моя зарегистрированная торговая марка. Только я могу получать за неё деньги! Это мой Laravel. Я его придумал и написал. Не нужно за мой счёт зарабатывать себе славу и деньги. Это опенсорс — либо ты помогаешь мне, либо уходи! Создай свой уникальный бренд и зарабатывай на нём. Вы отнимаете хлеб у моих детей.»

На данный момент известно, что Гитхаб закрывает все репозитории, принадлежащие обвиняемым лицам. Позже они будут либо удалены, либо переданы компании Laravel.

Где-то в ноябре я решил побыть настоящим свободным художником и поработать в шезлонге у бассейна. Но судьба быстро дала понять, что всю жизнь мне суждено быть офисным или максимум домашним работником. Пацану лет 3 было скучно и он окатил мой ноут с водяного пистолета. Я успел посидеть там минуты две) Тогда с ноутом ничего не произошло, но на днях моник просто погас и все.
Отнес на ремонт - поменяют материнку, займет две недели. Там остались незапушенными 3 коммита. И я 2 дня вспоминал что в них было. Вспомнил. Восстанавливаю.
Мораль - пушьте свою работу в гит. Он в том числе и для этого создан.