Абстракция — это как слой краски: первый слой скрывает неровности, второй уже начинает загромождать, а третий просто мешает видеть, что находится под ней. Недавно переписывал старый код, где каждый уровень абстракции обещал "универсальность" и "переиспользуемость". Получилось нечто вроде матрёшки: чтобы понять, что происходит, нужно пройти через пять слоёв индирекции. Баг ловишь, а сам не знаешь, в каком слое его искать — потому что каждый слой "правильно" делегирует проблему дальше. А потом начинаешь упрощать. Убираешь "универсальность" там, где она не нужна. Оставляешь абстракцию только там, где она реально экономит повторение кода, а не просто разбивает простую логику на двадцать файлов. И вот тогда всё вдруг становится понятнее — и работает быстрее, и баги ловятся в минуту вместо часа.

Сидел вчера над старым проектом, нашёл в нём README.md. Два года назад писал — помню, что старался. Скриншоты интерфейса, пошаговая инструкция, даже FAQ был. Сейчас это выглядит как археологический артефакт. Интерфейс изменился три раза, скриншоты показывают меню которого нет, а в FAQ на вопрос "почему ничего не работает" я сам же себе отвечал неправильно. И вот что забавно: код проекта за эти два года обновился, в нём разобраться проще, чем в моём же README. Потому что код — он либо работает, либо нет. А документация может тихо лежать и врать. Почему так происходит? Код трогаешь каждый день — неправильный кусок сразу бросается в глаза. А документация лежит в README, никто её не запускает, она просто есть. Пока кто-нибудь случайно не откроет и не поймёт, что читает историю. Вывод для себя простой: если документация — не первая сущность, а "потом допишу", она умрёт. Либо код должен генерировать документацию, либо документация должна быть частью CI, которая падает когда устаревает. Либо проще: не писать её вообще, чем писать и потом врать.

Открыл вчера модуль, который сам писал в прошлом ноябре. Читал минут пятнадцать и ловил себя на мысли: это что, правда моё? Причём не потому что плохо — в целом норм. Просто не узнавал логику, не помнил, почему выбрал такой способ, зачем тут эта прослойка. Особенно повеселили комментарии. Написал "здесь костыль, поправить позже" — ага, не поправил. Или "временное решение" — сюрприз, оно уже в проде полгода. Думаю, это нормально. Код пишешь ты, а понимаешь его другой ты — тот, кто уже забыл весь контекст. Поэтому стараюсь сейчас оставлять комментарии не про то "что делает код", а про то "почему именно так, а не иначе". Через год мой мозг скажет спасибо.

Я давно думаю, что абстракция — это как соль. Чуть-чуть делает блюдо лучше, а горсть портит навсегда. В коде тоже самое. Год назад я обвязал весь датабейс слоем DAL с красивыми интерфейсами, подумав, что так будет проще переключаться между БД. Результат — код, который никто не может прочитать, потому что всё спрятано за тремя слоями абстракции. Конечно, никто так и не переключился. Абстракция осталась, а боль не ушла. Сейчас я подхожу проще: абстракция должна решать конкретную проблему прямо сейчас, не "на будущее". Если ты видишь, что есть две разные БД и их надо поддерживать параллельно — вот тогда DAL имеет смысл. А если это "может когда-нибудь понадобиться" — лучше просто написать код так, чтобы его было легко прочитать, чем предусмотрительно усложнить.

Раньше я пытался схватить задачу целиком и сразу начинать её решать. Обычно залипал на полпути — то ли какая-то часть оказывалась сложнее чем казалось, то ли отвлекался на детали, то ли просто мозг отказывался держать всё в голове одновременно. Теперь делаю проще: беру задачу и пишу четыре вопроса: что самое простое, что я здесь могу сделать? Что от этого зависит? Где может сломаться? Как я пойму, что работает? Ответы на эти вопросы обычно сразу режут задачу на куски, которые имеют смысл. Первый кусок — не самый важный, а самый скучный. Его ленче всего сделать, потому что не требует решений. Как только первый кусок готов — остальное обычно складывается быстро.

Была у меня как-то задача — прикрутить авторизацию к небольшому сервису. Накидал схему в голове за вечер: JWT, роли, middleware, всё чистенько. Сел писать с нуля, потому что "там столько лишнего в готовых библиотеках, я сделаю ровно то что нужно". Две недели спустя: у меня мидлварь, который пропускает невалидные токены если в них лишний пробел, механизм ротации, который ломается на zero-decimals, и тесты, которые я пишу чтобы убедиться что мой собственный код работает. Плюс бесконечный рефакторинг "а давай всё-таки добавимrefresh token". Нашёл потом компактную библиотеку на 300 строк. Заменил всё одной строчкой. Работает уже год. Я не к тому, что библиотеки всегда хорошие. Просто недооцениваешь сколько edge-cases уже кем-то прочухано. Своё пишешь для души, для практики, для глубокого понимания. Но когда задача — решить задачу, а не написать очередной велосипед с квадратными колёсами — берёшь готовое и не комплексуешь.

Долгое время я пользовался grep как привычным молотком — вроде работает, но иногда хочется чего-то более удобного. Потом попробовал ripgrep и grep отошёл в прошлое. Основное — скорость. На большом проекте ripgrep находит текст за доли секунды там, где grep думает несколько секунд. Плюс из коробки понимает .gitignore, умеет искать по типу файла (--py, --go, --js), подсвечивает результаты и показывает контекст. Мой типичный запрос теперь выглядит так: `rg "function" --type js -C2`. Это находит все вхождения "function" в js-файлах и показывает по две строки до и после. Ещё одна штука, которая зашла — smart case. Если запрос с маленькой буквы, ищет без учёта регистра. Если есть заглавная — регистр уже важен. Не нужно запоминать флаги. Сначала казалось, что переход мелочный. Потом привык — и теперь открываю grep только если нужен какой-то совсем специфичный regex. В остальном ripgrep закрывает 90% задач поиска по коду.

Попросил у Claude код написать — красивый, элегантный, с комментариями. Попросил тот же код заставить работать с кириллицей в именах файлов — начал тупить капитально. Сижу и думаю: модель знает наизусть двенадцать способов реализации Raft consensus, может нарисовать архитектуру микросервисов для стартапа с пары подсказок, а вот простую задачу — "переименуй все файлы, заменив пробелы на underscore" — делает через задницу или вообще предлагает решение, которое не работает на пробелах в именах. Это забавно. Мы строим системы, которые понимают концепции, но глючат на граничных случаях, которые человек решает за пять секунд. Как будто кто-то отлично объяснил нейросетке теорию относительности, а про арифметику забыл упомянуть.

Писал микросервис с кучей абстракций — factory-pattern тут, dependency-injection там, interfaces везде. На бумаге выглядело идеально: легко тестировать, легко менять реализацию, можешь свопать компоненты как конструктор. Проблема в том, что через месяц я не помнил, где лежит реальная логика. Приходилось прыгать через пять слоёв оберток, чтобы найти, откуда берётся одна переменная. Потом переделал часть на простой код с явными зависимостями. Да, меньше "гибкости" на бумаге. Зато через полгода я ещё помню, как это работает. И новый разработчик разбирается за день, а не за неделю. Абстракция хороша, когда ты её переиспользуешь на пятый раз. До этого она просто усложняет. Иногда лучше написать одно и то же дважды, чем с первого раза обобщать "на вырост".

Недавно понял, что половину времени в терминале трачу на то, чтобы найти нужную команду в истории. Обычно это либо `grep` по логам, либо `curl` с кучей флагов, которые я никогда не помню наизусть. Завел себе файл с алиасами и функциями — прямо в `.bashrc`. Теперь вместо того чтобы каждый раз вводить `docker ps | grep` и потом `docker exec`, пишу просто `dex имя-контейнера` и попадаю внутрь. Или `logsize` — показывает, какой сервис съедает место в `/var/log`. Банально, но минимум минуту в день это реально экономит. Главное — не усложнять. Три-четыре самых частых операций в алиасах, и готово. Всё остальное запомнишь или найдёшь когда понадобится.

Вчера полтора часа разбирался, почему API-сервис не поднимается после переезда на новый сервер. Смотрел логи — пусто. Смотрел права — вроде норм. Смотрел зависимости — все на месте. Оказалось, я забыл пробел в одной строке конфига между именем параметра и значением. Вместо: ``` DB_HOST=localhost ``` было: ``` DB_HOST =localhost ``` Баш читает это как переменную с именем "DB_HOST " (с пробелом). Парсер YAML на это ругается, но молча. Сервис просто не стартует и всё. Смешно, но закономерность такая: чем проще ошибка, тем больше времени на неё убиваешь. Сложный баг — хотя бы интересно. А тут сидишь, смотришь на экран и не можешь понять, почему всё сломалось от одной лишней клавиши.

Настроил Restic на свой сервер, подключил S3-совместимое хранилище, настроил расписание — всё по уму. Бэкапы уходили каждую ночь, графики в Grafana радовали зелёными линиями, Job succeeded. Красота. Полгода спокойной жизни. А потом один диск на домашнем сервере начал сыпаться, и мне срочно понадобилось вытащить конфиги с той виртуалки, которую я считал уже мёртвой. Открываю Restic, ввожу... и не помню пароль от репозитория. Бэкап есть. Данные лежат. Доступ закрыт. Забавно, что графики строил, пароль не записал — рассчитывал на память. Перебрал пять вариантов, которые казались логичными. Ни один не подошёл. Вывод простой: бэкап без рабочего восстановления — это не бэкап, а файл, который занимает место. Теперь у меня в заметках не только команды, но и пароли лежат рядом с ними. Записывать — не зазорно. Забывать — дорого.

У меня когда-то был период, когда я открывал man-страницу find каждый второй день. Не потому что забыл синтаксис, а потому что каждый раз заново вспоминал, что именно мне нужно: найти все .log старше семи дней, или найти файл по части имени, или найти и сразу удалить. Потом я просто завёл себе файл snippets.sh и стал складывать туда однострочники, которые уже работали. За год там набралось штук тридцать. Сейчас я открываю его чаще, чем google. Совсем недавно заметил, что самые полезные из них — это те, где xargs работает в связке с grep или rm. То есть не просто "найди", а "найди и сделай что-то с результатом". Пайплайн, который ты написал один раз и потом просто подставляешь нужные параметры. Мелочь, но когда приходится делать что-то руками каждый день — экономия двух минут складывается в час к вечеру.

Вчера поймал себя на том, что пишу логи во всех местах "на всякий случай" — вдруг пригодятся. Потом поднял мониторинг на продакшене и увидел: диск забит на 95% за три дня. Иноды кончились. Сервис уже был в режиме read-only. Проблема не в самом логировании, а в том, что я не думал о volume'е. Ротация? Забыл настроить. Cleanup по возрасту? Тоже нет. Просто писал и писал, пока место не кончилось. Теперь проще: логирую только то, что мне правда нужно, а не "вдруг". И обязательно на диск с отдельным местом, с жёсткими лимитами. Один раз боль — потом автоматизм.

Год назад я был уверен — Docker решит всё. Задеплоил всё, что можно: базу, кэш, очередь, сам сервис. Красиво, воспроизводимо, как в учебнике. Потом пришлось дебажить, почему на прод-сервере всё падает каждый вечер, а локально работает идеально. Оказалось, я забыл про CPU-лимиты в compose-файле. Контейнер спокойно жрал все ядра, пока что-то другое не начинало работать — и вот уже OOMKill бьёт по памяти, вот уже health-check не успевает ответить. Теперь я понимаю: Docker — просто инструмент упаковки. Остальное — мониторинг, лимиты, правильная переработка сигналов, grace shutdown — это ты должен делать сам. Если этого нет, то контейнер просто отложенная боль.

Вчера потратил час на отладку, потому что логирование во всех функциях было настроено так: `logger.debug(f"Зашли в {func_name}, параметры: {all_vars()}")`. Звучит безобидно — мол, разберёмся потом. Но "потом" это был прод, где каждый запрос генерировал 500 логов в секунду, диск заполнился за четыре часа, и всё упало. Глупое было понимание того, что логирование "на всякий случай" — это не страховка, а бомба с часовым механизмом. Теперь логирую только то, что реально помогает понять, что пошло не так. Остальное — это просто шум, который когда-нибудь убьёт твой сервис.

Большие задачи меня парализуют. Не потому что ленюсь — а потому что в голове она рисуется такой здоровенной штукой, что непонятно, за что хвататься. Год назад заметил за собой паттерн: если сажусь делать что-то большое и сразу пытаюсь "сделать всё", то полчаса пялюсь в консоль и ничего не происходит. Но если перед этим беру и пишу себе микро-задачу — буквально один конкретный шаг, минут на пять работы — дело сдвигается. Хитрость в том, что микро-задача не про "сделать важное", а про "сделать хоть что-то". Например, не "настроить CI/CD", а "закомментировать строчку с тестом в gitlab-ci". Ерунда, но она уже создаёт файл, а файл — это точка, от которой можно оттолкнуться. Потом добавляю вторую микро-задачу, потом третью. Иногда их набирается десять, и задача оказывается почти готова. К этому моменту мозг уже вошёл в ритм, и двадцать минут пролетают незаметно. Никакой магии тут нет. Просто если не можешь съесть слона — ешь по ложке.

Бэкапы — это вещь, которая кажется срочной ровно до того момента, как ты их настроил. Потом проходит месяц, два, и ты забываешь, что они вообще есть. Потом проходит год, и накатывает паника: "А они точно работают? Может, я их вообще когда-то сломал?" Вчера вот решил проверить старые бэкапы — ну, так, для профилактики. Распаковал один из них, посмотрел содержимое. Пусто. Буквально ничего. Оказывается, полгода назад при миграции на новый диск я забыл обновить путь в скрипте бэкапирования. Скрипт честно работал каждый день, честно логировал успех, честно упаковывал пустоту. Теперь беру себе за правило: раз в квартал распаковываю случайный бэкап, проверяю, что там действительно то, что я думаю. Скучно, но дешевле, чем потом плакать.

Недавно понял, что постоянно переключаюсь между окнами терминала — открываю новый таб, вводу команду, потом ещё таб, ещё команда. А можно просто использовать `&&` и `||` в одной строке. Одна команда запустится только если первая прошла успешно, вторая — если первая упала. Теперь пишу `docker build -t app . && docker run app` вместо того, чтобы ждать, проверять статус, потом искать последний таб. Сэкономил минут пять в день? Нет. Но мозг доволен, что меньше движений — и это ценнее.

Сидел над умирающим кластером. Метрики из API сыпались простынями JSON, а мне нужно было в реальном времени видеть только потребление памяти и количество active connections. Сначала хотел поднять Grafana, потом пытался написать скрипт на Python, который бы полисертил API и парсил ответ. Потом забил и сделал в терминале: watch -n 1 'curl -s http://cluster/api/status | jq "{mem: .memory.used_percent, conns: .connections.active}"' Две секунды настройки. И всё — таблица с двумя цифрами, которая обновляется каждую секунду. Больше не нужно было перезапускать curl вручную после каждого изменения, не нужен браузер, не нужен Grafana. Иногда забываешь, что самые скучные утилиты из базового набора решают 80% задач. Особенно когда они хорошо комбинируются между собой.

Вчера подключал relay-модуль к котельной на Orange Pi — надо было коммутировать насос индуктивной нагрузки. Логика простая: пин высокий — реле щёлкает, насос работает. Казалось, не может быть проще. Первый запуск — реле срабатывает, но одновременно с этим микроконтроллер перезагружается. Перезагружается! Я ещё раз, ещё раз — каждый раз одно и то же. Подумал про импульсные помехи, про обратный ток, про недостаточный ток на пине. Оказалось, забыл про диод на катушке реле. Когда контакты размыкаются, индуктивность выбрасывает энергию назад, и эта волна идёт прямиком на пин контроллера. Диод нужен, чтобы замкнуть эту энергию в себе и дать ей рассеяться, а не лезть в цепь питания и логику. Минут пять с паяльником — и всё заработало. Теперь помню: индуктивная нагрузка на релейный выход всегда требует обратного диода. Неважно, насколько "по науке" ты рассчитал схему.

Вчера полтора часа искал, почему API возвращает разные результаты в продакшене и локально. Логи молчат, тесты зелёные, даже данные в базе одинаковые. Хотел уже docker бить, когда заметил в коде старый комментарий: `// TODO: убрать хардкод для дева когда-нибудь`. Оказалось, в utils.js всё ещё лежал if с проверкой на NODE_ENV, который я забыл удалить месяц назад. На проде переменная не установлена корректно — вот и расхождение. Пять строк кода, забытые под комментарием, сожрали час времени. Теперь половину таких TODO я просто выполняю сразу. Лень потом рыться и искать то, что сам же себе и подложил.

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

Все обсуждают OpenAI и Anthropic, а я тихо слежу за Qwen — и мне кажется, мы немного упускаем момент. Китайские модели всегда списывали со счетов: ну китайские, ну под цензуру, ну так, поиграться. Но Qwen постепенно закрывает бенчмарки, выдаёт нормальный код, работает на локальном железе без танцев с бубном. Для меня это практичнее, чем гоняться за GPT-5, который обещают "скоро". Неожиданный поворот простой: рынок AI-провайдеров размывается. OpenAI больше не безальтернативен, и это хорошо. Конкуренция снизу — иногда самая здоровая.

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