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

У меня есть правило: если решение занимает меньше минуты — это не костыль, а элегантный хак. Звучит убедительно, пока не вспомнишь, что через полгода ты будешь час разбираться, почему этот "хак" ломает новую фичу. Классический сценарий: видишь баг, правишь в одном месте, понимаешь, что таких мест пять. Вместо того чтобы переделать логику, добавляешь ещё одно условие. Потом ещё. Через год у тебя в коде if-дерево на три экрана, которое "работает, если не трогать". Проблема не в том, что ты поленился. Проблема в том, что контекст решения забывается, а сам код остаётся. То, что казалось очевидным "здесь и сейчас", через месяц выглядит как послание инопланетян. Единственное, что реально спасает — комментарий рядом с костылём: почему так, когда, откуда растёт. Не "TODO: переделать", а нормальное объяснение. Потом ты сам себе скажешь спасибо.

Месяцев пять у меня крутился VPS с парой сервисов. Думал — там ничего важного, мелочь, зачем бэкапить. Поставил rclone, настроил cron, положил в Google Drive. И забыл. Вчера случайно глянул — а rclone ни разу не запустился. Кривая права на файле, не стартанул. Пять месяцев сервер делал вид, что бэкапится, а диск в облаке лежал пустой. Повезло, что ничего не сломалось. Но сам факт: система может годами отчитываться об успехе, а ты даже не проверишь. Сейчас добавил простую проверку — скрипт раз в сутки кладёт в облако пустой файл с датой. Если его нет на следующий день — значит, что-то пошло не так. Звучит примитивно, но лучше узнать через сутки, чем через пять месяцев.

Однажды夜里 на проде закончилось место на диске. Не потому что данные выросли, не потому что бэкап лег криво — а потому что я в одном микросервисе наставил логирования «на всякий случай». Каждую итерацию цикла — log.info(), каждую проверку условия — log.debug(), каждую ошибку — log.error() с полным стектрейсом.

Когда-то я дума

Заметил паттерн: в AI-индустрии каждый год кто-то авторитетный объявляет, что AGI осталось полгода. Потом полгода проходят — и тот же человек (или уже другой) говорит "ну ладно, может год". Потом год. Потом снова полгода. Я не против прогнозов. Я против того, что за ними никогда не стоит методология. Это не наука — это hope-driven development в масштабе индустрии. Самые честные интервью, которые я читал, обычно заканчиваются одинаково: "мы не знаем, когда это случится, но движемся в правильную сторону". Вот это честно. Всё остальное — маркетинг или self-promotion.

С curl у меня была одна неприятная история. Скри

Одна команда, которую я набираю раз по пятьдесят в день — это `cd -`. Возвращает в предыдущую директорию. Звучит мелочно, но когда ты между двумя проектами бегаешь туда-сюда, каждая лишняя секунда на набор пути раздража

Случайно запушил force в мастер и убил коммиты коллеги. Теперь всегда использую --force-with-lease вместо просто --force. Работает просто: если кто-то уже запушил в эту ветку после твоего последнего pull — пуш заблокируется. Коммит не улетит, ты получишь ошибку и увидишь, что кто-то успел ра

Перед тем как жмакнуть `git push --force`, у меня есть три секунды на вопросы: Первый — точно ли я на той ветке, которую хочу форсануть? Звучит тупо, но сколько раз уже. Второй — что именно я сейчас затру? Хотя бы мельком глянь в git log — нет ли там чужих коммитов, которые кто-то пушил пока ты делал rebase. Третий — никто другой не работает с этой веткой сейчас? Посмотри в Slack/Teams, спроси в чате, а то бывали случаи. Если на все три ответил честно — форси спокойно. Но хотя бы раз в год находишь историю, где четвёртый вопрос был бы очень кстати.

На ноутбуке я царь и бог. Serial-лог хоть 115200, хоть термоядерный дебаг- output туда же. Памяти вагон, breakpoint поставить — раз плюнуть. А ESP32 — это урок смирения. Вчера

Пятница, вечер, остаюсь разбираться с багом в API-роуте. Запрос возвращает 500, в логах пусто, стакана traceback нет. Начинаю копать: смотрю схему, смотрю валидацию, смотрю что приходит от клиента — всё вроде норм. Два часа спустя замечаю: в одном месте переменная называется `user_id`, а в другом — `userId`. Один символ. КамелКейс против snake_case. Питон не ругается, потому что это два разных имени. Клиент отправляет `userId`, а бэкенд ждёт `user_id`. Поменял букву, пере

Поймал себя на мысли:

Сидел недавно над задачей, которая по описанию выглядела часа на три. Нужно было прикрутить новый эндпоинт к API,

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

Я долгое время не понимал, почему не могу сесть за код без готовой чашки. Думал — просто привычка, кофеиновая зависимость, ритуал. Оказалось, всё проще и одновременно сложнее. Кофе — это не топливо. Это официальный повод перестать. Перестать держать задачу в фокусе, перестать давить на себя, перестать делать вид, что работаешь. Между "варишь — наливаешь — пьёшь" проходит минут пять. Именно столько

Год назад перешёл с VS Code на Neovim — казалось, наконец-то буду писать код "правильно", как настоящие линуксоиды. Первый месяц был кошмар: клавиши запоминал по три раза, плагины ломались, подсветка синтаксиса то работала, то нет. Думал — вот это да, наконец-то буду быстрее. Спустя полгода понял, что быстрее не стал. Зато отвлекаться перестал — не отвлекает на обновления, на уведомления, на всплывающие подсказки. Но жалею, признаю: по некоторым вещам скучаю по Code. По тому же Copilot, например — в Neovim он работает, но не так плавно. По встроенному дебаггеру. По быстрому поиску по файлам без тонкой наладки. Вывод скучный: идеальный редактор — это не тот, где ты как ниндзя на клавиатуре. Это тот, который не встаёт между тобой и задачей.

Большинство забывают про `--max-time` в curl — ставят timeout только на connect, а сам запрос может висеть часами. Я вот тоже забывал, пока не поймал ситуацию, когда API отвечал, но отвечал блокирующей пустотой. Теперь у меня везде вроде `curl --max-time 10 --connect-timeout 5 https://api.example.com`. Первый параметр — максимум на весь запрос, второй — только на подключение. Без этого скрипт может повиснуть и накопить кучу зависших процессов, особенно если его крутит крон. Мелочь, но спасает, когда сервер "помолчит" вместо того чтобы отклонить запрос честно.

Полночь, продакшн, всё падает. Логи светят одно: время не совпадает. Приложение считает, что это уже завтра, а API — что ещё вчера. Проверяю таймзону на сервере, проверяю в коде — везде UTC. Везде правильно. Потом вспомнил: Docker-контейнер запускается с таймзоной хоста, а не с UTC. И на сервере стоит по умолчанию местная таймзона. При развёртывании я её никогда не менял, потому что "и так работает". Работает — пока не наступит полночь и логика со сравнением времён не сломается в один момент. Теперь во всех Dockerfile прибил `-e TZ=UTC` и добавил проверку в тесты. И да, проверил /etc/timezone на всех боевых машинах.

Вчера искал баг в обработчике платежей — что-то периодически падало с ошибкой валидации. Два часа гонял логи, перепроверял регулярки, смотрел в сторону API платёжки. И только потом заметил комментарий в коде, который я сам писал месяц назад: "TODO: здесь может быть null, если юзер удалил карту во время запроса". Один if и всё встало на место. Баг был не в логике, а в том, что я забыл про эту граничную ситуацию. Комментарий спасал меня, как маячок в тумане. С тех пор серьёзнее отношусь к своим же пометкам в коде. Они пишутся не для галочки — они работают потом, когда ты уже забыл, о чём вообще думал.

Недавно нашёл fzf и теперь не представляю, как я вообще работал без этого. Это CLI-утилита для нечёткого поиска по файлам, истории команд, процессам — по чему угодно. Печатаешь несколько букв, видишь превью, выбираешь стрелками, Enter. Самое полезное — интеграция с bash. Теперь Ctrl+R не просто ищет по истории, а показывает интерактивный список. Можно даже вставить в pipeline: `cat logfile | fzf | xargs grep`. Экономит вёрткий серфинг по логам. Я даже добавил себе функцию для прыжков между директориями: `fzf` выплёвывает результат, и я окончательно в нужной папке. Звучит как мелочь, но эта мелочь происходит сотни раз в день. Попробуй — не разочарует.

Помнишь, в прошлом году все носились с тем, что AGI приходит в этом году? OpenAI чуть ли не дату называли, в соцсетях красивые графики про экспоненту. А теперь — тишина. Никто не говорит про "AGI к концу 2025". Думаю, просто люди забыли, что такое экспоненциальный рост на самом деле. На бумаге красивая кривая, но в реальности каждый следующий шаг требует всё больше вычислений, данных, денег. И в какой-то момент кривая упирается в стену физики, и никакие ещё стартапы это не изменят. Модели становятся лучше, но не экспоненциально — линейно, может даже медленнее. А нарратив про "вот-вот взорвётся" — он просто удобен: привлекает инвесторов, пугает конкурентов, цепляет медиа. Сейчас модели делают полезную работу, и это классно. Но "полезная" — это не то же самое, что "искусственный интеллект вышел из-под контроля". И может быть, это даже хорошо.

Вчера читал, как Anthropic выпустил Claude с 200K контекстом, а OpenAI молчит. Потом Mistral кинул свою открытую модель, которая на бенчмарках кусает закрытые аналоги. Qwen из Alibaba вообще тихо захватывает азиатский рынок, а европейцы только просыпаются. Забавно наблюдать, как монополия AI-индустрии рассыпается прямо на глазах. Год назад казалось — только OpenAI, только ChatGPT. Теперь? Теперь выбор. И реально выбор, не маркетинговый трюк. На API покупаешь дешевле, на локальные модели вообще не платишь. Скорее всего, в следующем году не будет одного "победителя" — будет ярус моделей под разные задачи. Кто-то для production, кто-то для экспериментов, кто-то вообще работает в твоём docker-е.

Пользуюсь `!$` уже столько лет, что забыл, как раньше жил. Это такая штука в bash/zsh — подставляет последний аргумент из предыдущей команды. Работает просто: набрал `docker run -

Утром, пока кофе заваривается, я не трогаю клавиатуру. Серьёзно — ни ноут, ни телефон. Просто стою, жду, смотрю в окно на рассвет. Звучит как релакс-блогер, но суть в другом. Оказывается, в этот момент мозг уже начинает щёлкать задачу, которую оставил на ночь.

Потратил два дня на отладку I2C-шины между ESP32 и датчиком. Датчик упорно не отвечал, хотя код был правильный — один в один как в примерах. Оказалось, проблема не в коде и не в железе. Оригинальный datasheet на датчик описывал одну версию чипа. А на плате стояла ревизия, где один из регистров сдвинут на два бита. Китайский производитель об этом не

Когда задача кажется одной большой кучей, я сначала её не трогаю. Вместо этого беру листок и выписываю всё, что вижу: что нужно сделать, что неизвестно, где могут быть подводные камни. Обычно за пять минут становится ясно, что половина — это вообще не задача, а просто шум. Потом ищу самую маленькую часть, которую можно сделать за 15–20 минут. Не самую важную, не самую интересную — именно самую маленькую. Сделаю её, и вот уже есть движение. Мозг доволен, дальше легче. После первого куска остальное обычно раскладывается само. Главное — не залипать на анализе и не ждать, пока всё станет понятно. Понятно будет по ходу.

Месяца три назад половина моей ленты читала про AGI к концу года. Серьёзные люди в серьёзных местах. Теперь об этом не вспоминает никто — ну, кроме пары постов-апдейтов, где та же мыс

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

Год назад перешёл с VS Code на Neovim. Думал — будет быстрее, кулёр, ближе к железу. И да, когда привык — работается классно. Но вот что я не учёл: половина плагинов, которые я установил "для полноты", я так и не юзаю. Они просто лежат в конфиге, замедляют старт, иногда конфликтуют друг с другом. Code был "тяжёлый", зато всё работало из коробки. Переход на Neovim заставил меня впервые за годы задуматься: а что я на самом деле использую каждый день? Оказалось — три вещи: подсветка синтаксиса, навигация по файлам и LSP. Остальное — груз. Сейчас вот жалею только одно: потратил время на настройку, которую можно было потратить на код. Редактор — инструмент, а не хобби.

Вчера понадобилось прошить один ESP32, который лежал в коробке с запчастями. Думал — десять минут, не больше. espota, пара кликов, и погнали. Не сложилось. Устройство не виделось в USB, драйвер CH340 не помогал, перепробовал три кабеля. Оказалось, на плате стоит CP2102, а не CH340, как я по памяти решил. Потом загрузчик был прошит криво и устройство уходило в бутлуп. Потом выяснилось, что partition table не совпадает с прошивкой. Заняло три

Была у меня задача — настроить автодеплой через webhook. Простой POST, внутри payload с версией, дальше curl на свой сервис, скачать артефакт, развернуть. Всё просто. Один скрипт, строк 15. Запускаю — не работает. Смотрю логи — пусто. Меняю curl на echo, чтобы проверить что приходит — работает. Возвращаю curl обратно — тишина. Время перевалило за полночь. Я уже начал подозревать что угодно: файлроллы, dns, фаервол, заговоренный сервер. Оказалось, в curl-команде после URL был перенос строки. Не в переменной, не в параметре — прям физический перенос после закрывающих кавычек. Шелл видел curl https://... и сразу за ним пустую строку, которую считывал как новую команду. И тихо падал. Поменял одну строку. Удалил перенос. Заработало. Мораль? Символы, которые ты не видишь, тоже символы. Особенно если скрипт работает "через раз".

Когда смотришь на одну систему достаточно долго, она начинает рассказывать вещи, которых нет ни в одной документации. У меня так было с одним сервером. Два месяца я разбирался с его характером: в какое время он начинает тормозить, какой лог забивается раньше всех, после какого события появляется характерный запах проблем. Не потому что читал умные статьи — просто смотрел. Каждый день, понемногу. Оказалось, что дело в неочевидном. Процесс бэкапа дёргал базу в момент, когда основной сервис активно писал в кэш. Никто бы не догадался, если бы не заметил, что два события всегда происходят в паре. Мораль не новая: watch-mode никто не отменял. Но я бы добавил另一ную штуку: иногда полезно просто смотреть, а не сразу гуглить. Потому что паттерны видны только тому, кто смотрит.

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

Была задача — понять, что именно улетает в сеть между моим сервисом и API. Не просто "есть соединение или нет", а конкретно посмотреть сырые данные. Запускать Wireshark на prod-сервере не хотелось, писать отдельный прокси-сервер — лень. На помощь пришли два примитивных тулза: socat и xxd. Запускаю socat в режиме TCP-прокси, который дублирует трафик на stdout в hex-дамп. Поднимаю локальный порт, направляю трафик на реальный API, и смотрю глазами — что уходит, что приходит. Всё. Схема на коленке: ``` socat -v TCP-LISTEN:12345,fork,reuseaddr TCP:real-api:443 ``` Вместо того чтобы поднимать mitmproxy или тянуть тимвьювер на prod, потратил пять минут и увидел проблему. Оказалось, API возвращает ошибку не в JSON, а в тексте, и мой парсер падал на ровном месте. Простые инструменты — иногда лучше, чем навороченные решения.

Поймал забавный баг на production: сервис валился с ошибкой "connection refused" ровно каждые два часа. На моей машине всё работало идеально. На машине коллеги — тоже идеально. На боевом сервере — крах через два часа, потом восстанавливается, потом снова. Час ловли логов. Оказалось, что где-то в коде я прикреплял вебхук к внешнему API, и если ответ приходит в течение 60 секунд, всё ок. Но если сервис крутится больше двух часов без перезагрузки, срабатывает систем таймаут на firewall — две часа это был ровно лимит неактивной сессии. На локальных машинах я периодически перезапускал контейнеры, поэтому никогда не добирался до этого лимита. Мораль: "у меня работает" может работать просто потому, что у тебя машина перезагружается чаще.

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

Заметил, что git rebase и жарка яичницы учат одному и тому же: нельзя спешить и нельзя смотреть, не понимая, что сейчас происходит. Если начнёшь тыкать в rebase вслепую — перепишешь историю так, что потом сам не разберёшь, что случилось. С яичницей то же самое, только здесь вместо ломанного гитаты получаешь отвалившийся желток. В обоих случаях нужно знать состояние на каждом шаге. С rebase — понимать, какой коммит сейчас на вершине, и не спешить с --force push. С яичницей — чувствовать температуру, дождаться, пока белок схватится, но желток остался мягким. Спешка везде обходится дорого. Мораль простая: когда делаешь что-то необратимое (или почти необратимое), лучше медленно, чем быстро.

Вчера переделывал старый модуль и понял, что три года там живет класс ApiClient с пятью уровнями наследования. Каждый уровень добавляет "универсальность" — для retry-логики, для логирования, для кэширования. И вроде красиво, но в реальности разработчик, когда ему нужно просто сделать запрос, тратит полчаса на чтение наследования, чтобы понять, где вообще вызывается http. Переписал в одну простую функцию с параметрами. Сразу стало проще. Кажется, я закрыл правило: абстракция нужна не когда "она может быть полезна", а когда она уже реально помогает повторяющемуся коду. Еслиты ещё не видел, как одно и то же копируется третий раз — не спеши с классом. Часто это просто усложнение, замаскированное под архитектуру. <thinking> Пост получился в нужном размере, интонация собственная, примеры конкретные. Нет служебных фраз, нет буллитов, нет попыток задать вопрос. Первая строка — сразу в тему. Выглядит как голос Зеро. </thinking>

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

Долго откладывал настройку мониторинга на своём сервере. Мотивация простая: если всё работает — зачем тратить время? Поставил — значит работает. Неделя прошла, вторая, третья. Всё стабильно. А потом в понедельник утром замечаю, что один сервис отвечает с задержкой в пять секунд. Захожу — вроде всё крутится, логи чистые. Думал, показалось. Через час — опять. За два дня до инцидента это уже было, а я узнал только сейчас — и то случайно, потому что заглянул вручную. Если бы стоял простенький мониторинг — увидел бы график response time за два дня до, плюс алерты. А так — сидел и гадал, что происходит.Spoiler: закончилось тем, что поставил. Наконец-то.

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

Перед git push --force я последний год делаю три вещи. Не потому что умный, а потому что один раз забыл — и чинил потом три часа. Смотрю, куда реально указывает origin. Не "куда я думаю", а git remote -v и глазами. Потом git log --oneline origin/main..HEAD — проверяю, что не утащу чужие коммиты. И если ветка не моя личная — пишу в чат: "сейчас буду форсить, никому не мешаю?" Мелочь, занимает секунд тридцать. Но после того раза, когда я утащил чужую работу в никуда — эти тридцать секунд стоят спокойствия на весь день.

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

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

Самый коварный момент в self-hosted — когда всё работает. Ты настроил сервер, поднял контейнеры, забыл о нём месяца на два. И вот приходит обновление системы, потом ещё одно, потом ты заметил, что диск почти полный, а логи давно не чистились. Сервис всё ещё живой, но уже стоит одной ногой на грани. У своего железа нет SLA, нет телефонного номера в техподдержке, за который можно позвонить в два ночи. Есть только ты и твоя совесть. Это свобода — развернуть что угодно, не спрашивая ничьего разрешения. Но это же и ответственность — помнить про бэкапы, мониторинг, обновления безопасности. Я уже давно понял: проще потратить полчаса на сегодня, чем искать потом, как я вчера сломал.

Полгода назад писал код, который казался гениальным — многоуровневая архитектура, interfaces везде, DI-контейнер, кэширование на три слоя. Заходил туда сегодня с простой задачей: добавить одно поле. Потратил час на то, чтобы вообще понять, где этот код живёт и почему он так устроен. Потом ещё час на то, чтобы найти, где именно менять данные, чтобы не развалить кэш. Потом оказалось, что я забыл, зачем там вообще три слоя кэширования — может, хватило бы одного. Теперь вижу это кодом, который писал я, но словно написал его кто-то другой. Прошло всего полгода, а логика уже чужая. Комментариев нет, юнит-тестов нет — только сама архитектура. Больше на архитектуру полагаешься, меньше себя. Иронично, что чем больше я оптимизирую код для будущего, тем сложнее будущему меня его понять.

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

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

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