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

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

Знакомо?

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

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

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

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

Меня зовут Александр Козуб и я уже двадцать лет в финтехе, последние несколько из них в качестве 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 эта ставка наконец сыграла.

Cursor или его аналоги, здорово облегчают написание кода, когда речь идет о каких‑то не очень больших проектах. Но стоит попробовать применить их к серьезному, сложному проекту, состоящему из нескольких репозиториев, и тут же сталкиваешься с тем, что эти «чудеса» оборачиваются просто огромными счетами за токены. Я в этой статье поделюсь, как мне удалось перестать впустую сжигать миллионы токенов. Для этого пришлось собрать и запустить три MCP‑сервера по протоколу Model Context Protocol, что позволило сэкономить до 90% бюджета, при этом совершенно не потеряв в эффективности модели при работе с кодом.

По мере того как современная разработка программного обеспечения движется в сторону непрерывной доставки и микросервисов, цена ошибок возрастает. Нестабильные тесты, плохо масштабируемый код автотестов или неправильное использование инструментов могут приводить к задержкам релизов или к росту количества багов из‑за затрат времени и ресурсов на выявление причин падения автотестов. То, что сначала кажется временным исправлением, впоследствии может обернуться отложенными последствиями для всей команды.

В этой статье мы рассмотрим семь распространенных ошибок, которые совершают начинающие SDET. Разберем не только то, что идет не так, но и почему это имеет значение и как подходить к решению каждой из проблем наиболее эффективно. Цель статьи — помочь начинающим SDET заложить прочный фундамент для эффективного тестирования, основанного на качестве, масштабируемости и взаимодействии с командой.

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

Мы столкнулись с этим во время миграции большого исторического проекта на Next.js 15. Вайбкодинг сначала выглядел как идеальное ускорение: модель за минуты переносила страницы, компоненты, хуки и server actions. Но затем на ревью начали прилетать огромные PR с тысячами строк сгенерированного кода.

На детальном ревью выяснилось, что AI часто переносит поведение неточно, пишет собственные велосипеды вместо использования готовых open source решений, не подтягивает дизайн-токены из Figma, не делает Storybook stories и не запускает тесты, если его явно об этом не попросить.

В статье рассказываю, почему проблема не в самом AI, а в отсутствии процесса вокруг него. И предлагаю prompt-first подход: сначала ревьюить короткий промт-план с контекстом, ограничениями, файлами и критериями приёмки, а уже потом генерировать код и открывать PR.

Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».

В разработке качество часто ломается не только на самих багах — но и в тех местах, где работа переходит от одного этапа к другому без ясных условий. Задача уже поехала дальше, хотя acceptance criteria ещё сырые. Формально её можно тестировать, но по факту сначала нужно собирать контекст. Пайплайн зелёный, при этом важная проверка вообще осталась за его пределами.

Такие ситуации обычно показывают не частную ошибку, а устройство процесса в целом. Когда важные условия нигде не закреплены, команда расплачивается за это уточнениями, возвратами и лишней синхронизацией. И напротив — если критерии перехода определены заранее, работать проще. Поэтому Quality Gates для нас в Островке — не только способ ничего не упустить, но и понятный маркер того, насколько процесс разработки вообще выстроен и управляем. 

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

Под катом — практический разбор того, что вообще можно считать Quality Gate, где такие механизмы реально работают и как подбирать их под задачи команды.

Привет, Хабр!

Меня зовут Александр Сахаров, я директор по работе с партнерами в «Диасофт». Последние пять лет мы строим экосистему Digital Q - набор low-code платформ для enterprise-разработки в микросервисной архитектуре. Внутри у нас около двух тысяч разработчиков, и мы на собственном опыте знаем, что бывает, когда каждая вторая команда изобретает велосипед.

Но в этой статье я хочу показать не только наш взгляд. На конференции Deckhouse Conf 2026 мне удалось собрать за одним столом людей, которые каждый день живут внутри этой проблемы: это руководители в ИТ в крупнейших банках и телеком компаний, помогал мне Артем Гениев из «Фланта», руководитель бизнес-юнита «Экспресс 42» - ребята, которые строят платформу со стороны DevOps и инфраструктуры.

Меня зовут Александр Сахаров, я директор по партнерствам в компании Диасофт. И тезис, с которого начну, довольно дерзкий: старый айтишный треугольник «быстро, дешево, качественно, выберите два» в 2026 году можно закрывать. Правда, с одним условием, о котором почему-то  практически не говорят.

На днях мы собрались с коллегами обсудить мифы вокруг искусственного интеллекта. Поговорили про AGI и массовые увольнения из-за внедрения ИИ, но с определенной долей скепсиса. И вот почему. Дело в том, что по свежим данным 56 процентов CIO в мире за последний год не получили от ИИ ни роста выручки, ни снижения затрат. Удивлены?

Если вы часто упираетесь в лимиты Claude Code / Codex и не понимаете, куда улетают токены — этот лонгрид для вас

Да и вообще всем, кто хочет разбираться в современных AI инструментах, будет полезно

Разбираемся

1. Как устроено контекстное окно изнутри: 7 слоёв (от весов модели до MCP и skills)
2. Что такое attention и при чем тут O(n²)
3. Как работает agent loop на примере 4 вызовов модели
4. Почему prompt caching экономит до 10× в лимитах при правильной работе с ним

Сууупер длинная статья