Качество кода *

За свои 17+ лет в активной разработке я встречал много проблем, но одна преследовала меня постоянно: JSON. Нет, с самим форматом все ок, но вот с его чтением — не все норм.

Когда я только начинал работать с PHP, я списывал это на скриптовость языка. Отчасти из‑за этого я даже поменял стек. Но когда приходили по‑настоящему большие файлы, это всегда было больно. Иногда — очень. Был проект, где мы ждали не обработку информации бизнес‑логикой, а банального парсинга. Файлы доходили до десятков гигабайт и не всегда влезали в оперативку. Тогда я и заработал себе персональный todo — разобраться с этим раз и навсегда.

Сейчас, находясь в поиске новых возможностей, я решил вспомнить эту старую боль. Я уже давно не PHP‑разработчик, но проблема в индустрии всё та же. Объемы данных растут, требования тоже, а воз и ныне там. Нет, есть море крутых решений. Даже тут, на Хабре. Но для меня всё не то.

Мне нужно решение, а не костыль. То есть: никакой кодогенерации и никаких JIT (я не противник JIT, просто не хочу тянуть эту сложность).

Я ступил на тонкий лед: в Go есть классная штука — пакет unsafe. Почему классная? Потому что она позволяет обойти тяжелые ненужные проверки. Плюс побитовые операции для ускорения всего, до чего только смогли дотянуться руки. Пока изучал чужие парсеры, столкнулся с обманом в репозиториях, подкручиванием статистики (куда же без него?) и перекладыванием ответственности (и аллокаций) на сторону разработчиков.

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

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

В 1865 году британский журналист Томас Майн Рид написал роман "Всадник без головы", который послужит нам отправной точкой в вопросе о том, что же такое "безголовая" CMS и какие из них представлены сейчас на рынке веб-разработки.

История о том, как я загнал главную страницу форума с 88 запросов до 15, выяснил, что половину работы делал впустую один невинный аддон, и в конце снял ещё четверть серверного времени строчкой в конфиге — не сломав при этом ничего из того, что работало. А заодно — полная документация на стек из четырёх своих расширений и preload, на которых форум сейчас и держится.

За последний месяц я насчитал минимум семь свежих статей с заголовком в духе "Playwright быстрее Selenium на N%". Проблема в том, что N у всех разный: 23%, 42%, 63%, "1.85x". Методология почти нигде не раскрыта дальше фразы "controlled environment". Для решения, которое определяет CI-бюджет и архитектуру тестов на годы вперёд, это не цифры — это шум.

Здесь — что из этого шума реально на что-то опирается, почему остальное несопоставимо, и рабочий бенчмарк-харнесс, который вы можете прогнать на своём стеке за один CI-job и получить именно свои числа, а не чужие проценты.

Я изучил записные книжки шести писателей-классиков и обнаружил, что ни один из них не вёл "систему управления знаниями". Их тетради были хаотичны, а сам подход не навязывал структуру. В результате исследования я сделал свою полноценную "тетрадь писателя" на Go в 3253 строки с нулём фреймворков и минимумом зависимостей.

Под катом — пространное эссе о том, почему "удобно" и "просто" — разные вещи.

В 2026 году софт всё чаще пишут с участием ИИ: по данным Stackoverflow, 84% разработчиков уже используют ИИ‑инструменты или планируют начать. Но у скорости есть цена. Исследователи Faros AI зафиксировали парадокс: в командах с активным ИИ разработчики закрывают на 21% больше задач и мёржат на 98% больше пул-реквестов — а время ревью при этом выросло на 91%.

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

После нескольких месяцев работы с AI‑кодом я пришёл к неожиданному выводу: проблема может быть не в LLM, а в наших привычках проектирования. Попытка сформулировать архитектуру, которая изначально рассчитана на AI как основного автора кода.

За последний год вокруг AI-агентов сформировался довольно устойчивый набор ожиданий.

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

Я тоже так думал.

5 марта 2026 года в своём доме, в окружении семьи, тихо умер человек, чей код вы трогали на этой неделе. Возможно, прямо сегодня. Возможно, он уронил вам прод.

Звали его сэр Чарльз Энтони Ричард Хоар. Для друзей — Тони. Для пары поколений студентов — C. A. R. Hoare, тот самый, что в 26 лет придумал quicksort, выиграв у начальника спор на шесть пенсов. Тьюринговская премия 1980 года, логика Хоара, CSP, на которой потом выросла половина теории конкурентности. Большая, красивая, почти безупречная карьера.

Почти. Потому что в 1965 году тот же самый человек добавил в язык одну маленькую штуку. И эта штука пережила его, переживёт нас и, скорее всего, прямо сейчас лежит где-то в вашем стектрейсе.

Это null.

Есть расхожий сюжет: коварная индустрия наплодила багов, а гениальные инженеры героически с ними борются. Красиво. И, как обычно, неправда. Потому что самый дорогой баг в истории софта добавил не злодей и не нерадивый джун. Его добавил один из умнейших людей в истории computer science. 

Вот про эту историю и поговорим.

Я наткнулся на подход к функциональным тестам, который меня по-настоящему удивил. Тесты в нём вообще не знают, что внутри Spring: стучатся в реально поднятый сервис по HTTP, как обычный клиент, гоняются параллельно и проходят за секунды. Я разбирал это на код-ревью и сначала прифигел, а потом не стал переходить на него сам, но кое-что забрал себе. В статье сравниваю оба подхода, разбираюсь где какой уместен, и показываю три вещи, которые подсмотрел и притащил в свой Spring

В начале 2024 года я устроилась Senior Software Test Automation Engineer в финтех-стартап. После работы в большой стабильной корпорации это был настоящий вызов ― попасть в живой дышащий мир молодой продуктовой  компании, пытающейся занять своё место на рынке. Мне понравился продукт и привлекала возможность влиять на процессы, даже устанавливать новые.

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

Так вот, в этой компании я встретила подход automation first. Это означало, что весь разрабатываемый функционал сразу же покрывался автотестами. В добавок к этому были задействованы многие продвинутые инженерные практики, к которым, как я знала из опыта, компании и проекты приходили через боль, страдания, унижения и годы беспросветного мануального регрессионного тестирования. 

Однако не всё было идеально, проблем тоже хватало, даже при том, что скорости релизов мы достигли прямо таки нереальной, обеспечивая при этом отличное качество. В этой компании существовала доселе не встречавшаяся мне структура ― инженерное комьюнити. В каждой дисциплине было своё. У инженеров по качеству ― QA Community. Польза его для процветания компании неочевидна при первом взгляде. Как человеку, который любит докопаться до причин всего на свете, мне было любопытно как это работает и почему. В том числе влекомая этом любопытством я спустя некоторое время выдвинула свою кандидатуру на должность очередного QA Community Lead. Да, должность выборная, как президенство, срок правления ― год, потом смена власти. Немного ранее выборов у нас сменился СТО и объявил, что теперь теперь избранный кандидат должен получить также апрув от него, а также он может оставаться на должности дольше, если нет возражений от комьюнити и/или СТО. Или пока не настанет импичмент, а такое тоже было в истории компании. 

Я прошёл тест на hh.ru с помощью ИИ. Мне не поверили и обвинили во лжи. Я прошёл его ещё раз. Под катом немного рассуждений, немного оскорблений и 30-минутный видеопруф.

…

За эти полгода я кое-что узнал о том, как можно (и как не стоит) обращаться с тем замечательным созданием, что живёт в вашем терминале, виэскоде, курсоре или где вы там его запускаете, и счёл не бесполезным записать некоторые наблюдения. Тем более что меня спрашивают, а каждому лекцию не прочитаешь. Собственно, на то и статья, а точнее, эссе…

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

Я всё утро вылизывал план на 1700 строк. Дольше, чем заняла бы сама задача, если бы я сел и написал её руками. И к обеду поймал себя на мысли, что я не написал ни строчки кода, я редактировал документ про то, как код будет написан, и кажется немного поехал 😁

Потом отпустило. Я не поехал. Просто работа переехала, а я не сразу заметил.

Короче. Код стал дешёвым. Любой агент перепишет тебе модуль по запросу, в третий раз, в десятый, на другой язык, ему вообще всё равно. То, за что раньше платили деньги, теперь стоит примерно ничего. А дорого стало то, что по краям от кода. Спереди и сзади. И оба края про одно: сделать правду, которую агент не сможет заболтать.

Потому что заболтать он умеет шикарно. «Готово, всё работает, тесты зелёные». Ага.

Я это понял не из статьи, а из своих же шрамов. Но статья, на которую отвечаю, попала ровно в ту же точку, просто зашла с другой стороны.

Месяц назад начал делать собственный язык программирования Nova с Claude Code. За это время агенты автономно закрыли около трёхсот инженерных планов, написали около 120 тысяч строк Rust (компилятор, рантайм, кодоген), почти две тысячи проходящих тестов и собственную стандартную библиотеку на Nova. Один человек физически такой объём не вытянет — но и автономия даётся не бесплатно.

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

AI-инструменты уже давно перестали быть просто «умными чатами». Сегодня Claude Code, Codex и другие агенты постепенно превращаются в полноценную инженерную инфраструĸтуру: с памятью, workflow, sub-agentʼами, orchestration и reusable праĸтиĸами.

В этой статье команда разработки СВОЙ Тех собрала праĸтиĸи, ĸоторые реально помогают использовать Claude Code эффеĸтивно. Дисклеймер: будет много списков — не обессудьте и, надеемся, вам так же, как и автору, легче усваивать информацию.

Привет, Хаброжители! Более десяти миллиардов строк кода C++ в настоящее время используется в реальных проектах, и 98 % разработчиков ежедневно находят и исправляют в них ошибки. Даже в критически важных приложениях встречаются баги, проблемы с производительностью и читаемостью. Эта книга поможет выявить их в коде, который вы поддерживаете, и избежать — в коде, который вы пишете.

Из трёх мажоров, описанных в предыдущей статье, два не всплыли в тестах. Они всплыли в двух дизайн-ревью, которые тесты провести не могут.