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

Мысли о нейминге приватных переменных в C++ и неочевидные моменты из стандарта, о которых легко забыть в реальном коде

// todo: тут N+1 на invoice — надо переделать через entity graph.

Этот комментарий висел в коде полтора года. Все, кто заходил в файл, его видели. Никто не завёл тикет. В пятницу вечером он сработал — и забрал с собой три пода, 30% запросов на критичной ручке и моё спокойствие на выходные.

Вы меняете системный промпт, надеетесь, что все заработало и деплоите фичу в продакшен. На следующее утро прилетает жалоба: агент выдумал дедлайн или проигнорировал важную инструкцию. Вы снова открываете IDE, правите промпт, смотрите глазами на пару примеров — «вроде стало лучше» и цикл вновь повторяется.

Если это ваша повседневная реальность, у нас плохие новости: вы не управляете продуктом, вы играете в лотерею.

В мире, где LLM-агенты становятся основой бизнес-процессов, AI Evals (оценки) — это не дополнительная нагрузка на инженеров, а единственная возможность контролируемых улучшений. Лидеры индустрии, от OpenAI до Anthropic, сходятся в одном: если вы не можете измерить качество работы ИИ - вы не можете им управлять.

Взгляд на экосистему SQL-разработки под MS SQL SERVER через призму контроля качества кода. Обзор существующих инструментов, описание самостоятельной наработки для линтинга T-SQL кода.

Все мы начинали писать на Python примерно одинаково: создавали пустой список, запускали цикл for, проверяли условие через if и делали .append(). Это надежно, предсказуемо, но по мере роста кодовой базы такие конструкции начинают утомлять — мы тратим 4-5 строк на банальную трансформацию данных, которую можно уложить в одну лаконичную строку.

В этой статье мы подробно разберем встроенный инструментарий Python для работы с итерируемыми объектами: map, filter, reduce, any, all, zip и enumerate.

15 мая Vercel Labs релизнули Zero. Экспериментальный системный язык, который сами авторы называют "the programming language for agents". Версия 0.1.1, Apache 2.0, расширение .0, бинарники меньше 10 килобайт, без LLVM. На GitHub лежит компилятор, стандартная библиотека и примеры — можно ставить и щупать прямо сейчас.

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

Если коротко — наверное серьёзно, но мне сейчас не нужно. Тебе, скорее всего, тоже. Сейчас расскажу, что там и почему я так думаю.

Привет! Это снова Михаил Федоров. В первой статье — архитектура QA Assist: 11 AI-агентов от декомпозиции требований до готовых автотестов. Во второй — как «4 часа подключения» превращаются в неделю корпоративной реальности. В третьей — почему пирамида тестирования ломается, когда тест-дизайнером работает LLM. Сегодня — про то, как я решил наконец-то перестать оценивать агента «на глаз» и собрал отдельный проект-бенчмарк, на котором можно честно сравнивать прогоны: версии агента, отдельные «улучшалки», даже эксперименты с моделями. В качестве бонуса покажу все артефакты, которые агент готовит за один прогон пайплайна. И бенчмарк, и артефакты — в публичном доступе, ссылки в конце статьи. Обсудить всё это можно в Telegram-группе.

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

Исключения рождаются не только в основном коде, но и в обработчиках этих самых исключений. Зачастую вопросу не уделяется должного внимания. Действительно, что может пойти не так в блоке catch? Там ведь код тривиальный! Но это только на первый взгляд.

Например, безобидный LOG.warn("...") выливается в десяток вызовов нижележащих методов. И чем больше «наслоений» в библиотеке логгирования, тем выше вероятность сбоя. Всё бы ничего, если бы не одна особенность языка Java…

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

Знакомо?

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

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

Посмотрите на функцию загрузки инвойса:

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

Меня зовут Александр Козуб и я уже двадцать лет в финтехе, последние несколько из них в качестве CPO. Специализируюсь на ситуациях, когда очевидные рычаги роста уже не работают, и нужны системные решения, а не новые фичи. В симптомах вижу систему, об этом и пишу

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

На каждом ревью найдётся кто‑то, кто спросит: «Зачем четыре файла, если это один пайплайн?»

А затем, давайте объясню!

Размышления на тему куда катится вайбкодинг и прочие агентские разработки. Хотите я прочитаю эту статью за вас?

Примечание переводчика: на тему «ИИ в кодинге» есть много «хайповых» текстов, но мало технических. Вместо общих слов хотелось бы видеть разборы реальных ситуаций. Такой пост есть у Митчелла Хашимото (создателя терминала Ghostty), и мы решили перевести его для Хабра. Он опубликован ещё осенью, поэтому что-то могло устареть, но главные выводы остаются актуальными. Далее повествование идёт от лица Митчелла.

Недавно я выпустил улучшение для Ghostty (ненавязчивые автоматические обновления для macOS), которое разработал в основном с помощью ИИ.

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

Меня зовут Игорь, я тимлид в e-commerce. Когда у меня появилась вторая команда, стало понятно, что вручную следить за двумя Jira, двумя GitLab и метриками одновременно — нереально. В итоге сделал инструмент, который собирает всё в одном месте

Привет, меня зовут Смирнов Владимир, и я отвечаю за тестирование торгового бэкенда в EXANTE. Разработка кипит, регрессионные наборы автотестов растут - всё это сопровождается хаосом и различиями тестовых окружений, из-за чего неизбежно растёт и число нестабильных падений (ака флаки), за завесой которых могут теряться реальные проблемы. Как мы регулярно поддерживаем автотесты в приемлемом состоянии и стараемся не тратить на это слишком много времени? Об этом и поговорим.

HikariCP давно стал де-факто стандартом JDBC connection pooling в JVM-проектах. Но подключить его мало: важно правильно выбрать размер пула, таймауты, maxLifetime, keepaliveTime, leak detection и метрики.

Разбираем, как настроить HikariCP для Java, Kotlin, Scala и Spring Boot, какие ошибки чаще всего встречаются в проде и почему maximumPoolSize нельзя просто копировать из соседнего сервиса.

Привет, Хабр! Меня зовут Данил Чечков, я Team Lead команды High End Meta Backend в «Леста Игры». Мы занимаемся всей web‑составляющей «Мира кораблей». В нашем арсенале огромное количество микросервисов, работающих на Python и Go. Мы отвечаем за покупки в meta‑валюте, авторизацию, стабильность инвентаря и профиля игрока, клановые сервисы, а также многое‑многое другое.

Наш основной продукт — высококачественные web‑сервисы на стыке интеграции с игрой. И, да, интеграция — часть нашей работы.

А ещё мы любим новые технологии и стараемся с ними знакомиться, чтобы оценить, как они могут принести выгоду бизнесу и нам. Одна из таких технологий — LLM

Когда я начинал CodeClone, это был довольно понятный инструмент: найти структурные клоны в Python-коде и не дать им незаметно расползаться по проекту.

Сейчас вышел CodeClone 2.0.0, и это уже другой продукт.

Не “ещё один линтер”, не попытка заменить Ruff, mypy, pytest, Bandit или Semgrep, а отдельный слой ревью: он смотрит на структуру Python-кода, отделяет старый технический долг от новых регрессий, связывает находки с покрытием тестами и дает одну и ту же картину в CLI, HTML-отчете, GitHub Actions, VS Code, Claude Desktop, Codex и через MCP.

Эта статья не про список флагов CLI. Про флаги есть документация.

Здесь я хочу рассказать, во что CodeClone вырос как продукт и зачем вообще нужен такой класс инструмента сейчас, когда разработка всё заметнее смещается в сторону AI-агентов.

Вчера вышел Zed 1.0. Пять лет работы, миллион с лишним строк на Rust, публичная превьюшка, которой ежедневно пользовались сотни тысяч разработчиков, и вот команда Zed Industries во главе с Натаном Собо запостила релиз 29 апреля 2026 года. Я лет пятнадцать живу в IDE от JetBrains. Пробовал VS Code. Пробовал Cursor. Гонял code-server на удалённой виртуалке. Ничего не приживалось. Zed прижился, и релиз 1.0 — нормальный повод объяснить, почему.

Если коротко: больше десяти лет любой «новый» редактор кода — это всё тот же продукт в новой обёртке. Обёртка зависит от того, что продают сегодня: AI, коллаборация, темы, новый вендор. А под обёрткой Electron. Тот же Chromium на каждое окно, тот же JavaScript на критическом пути исполнения, тот же RSS, к обеду уходящий в гигабайты. Sublime Text держал планку нативных редакторов все 2010-е, но это был закрытый продукт одного автора, без нормальной коллаборации и без AI истории. Zed стал первым за последние десять лет убедительным опенсорс-редактором с GPU-ускорением и AI на борту, который пересобрали с нуля и без всякого браузера под капотом. С релизом 1.0 эта ставка наконец сыграла.