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

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

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

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

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

Если все еще используете вкладки редактора в шторме или других средах от 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. Это баг в приложении одного банка. Некритичный, но неприятный)

Купил я как-то молока в 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 и прямо в этом окне сразу увидел все, что нужно. Даже не заглядывая в тесты. Документация!