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

Привет, Хабр! Меня зовут Анна Саботович, я веду внедрение AI-ревьюера в продуктовой группе Garage Eight, и самый частый вопрос, который мне задают: «Ну и когда он заменит человека?» Отвечу сразу: на части кода уже заменил.

В октябре наши iOS-команды сняли третий обязательный апрув на merge request (MR). Теперь в продуктовых репозиториях их не больше двух, при этом в репозитории ревьюера за тот же октябрь влили 35 MR, и апрув кого-то, кроме автора, есть только у шести. Во внутреннем сервисе аналитики разработки влили 69 MR, и ни в одном нет апрува другого человека: автор мержит сам. Хочу рассказать, как мы учились доверять AI и что планируем делать дальше.

Иногда после git reset --hard, rebase или удаления ветки кажется, что несколько часов работы исчезли. Но Git часто не удаляет коммиты, а просто перестаёт на них ссылаться. Разбираем, как найти потерянное через reflog и fsck, восстановить ветку или stash и в каких случаях вернуть данные уже нельзя.

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

На днях наткнулся на отличную статью Никиты Тимофеенко «Вам не нужны bool и Option». Автор со стороны Rust-разработки поднимает фундаментально правильный вопрос: кодировать состояния системы разрозненными флагами вроде succeeded: bool и failed: bool — это плохой тон, ведущий к трудноуловимым багам. Система типов должна делать некорректные состояния запрещенными на этапе компиляции.

В C++ сообществе эта идея, разумеется, тоже не нова. Мы давно и успешно оборачиваем подобные вещи в std::variant, используя std::monostate как аналог отсутствия значения (можно задать псевдоним, например AbsentResult).

Но читая статью и комментарии к ней, я поймал себя на мысли: мы, разработчики, слишком сильно увлеклись мощью современных компиляторов. Как только стандарты C++ (да и Rust) дали нам инструменты для зубодробительных compile-time проверок любых сущностей, мы начали пихать эти проверки везде, где нужно и не нужно.

В этой статье я хочу показать, как правильное использование std::variant может... замаскировать серьезную ошибку проектирования архитектуры. Как увлечение построением лучшей системы типов отвлекает нас от фундаментальных вопросов проектирования систем. Мы разберем, как классические стейт-машины при поллинге (polling) заставляют нас писать тонны шаблонного кода ради проверок, которых в этой точке программы вообще не должно существовать.

Когда разработчик говорит: «Похоже, меня рано повысили», мне хочется спросить: «А что теперь от тебя ждут?» Допустим, раньше он сам доводил задачу до релиза, а теперь ещё разбирает чужой код и помогает коллегам, когда те застряли. Своих задач он закрывает меньше. Если руководитель по-прежнему судит о его работе только по этим задачам, я бы начал с разговора о нагрузке, а не с совета поверить в себя.

Бывает и иначе: человек берётся за задачу, для которой ему пока не хватает опыта. Тут полезнее вместе разобраться, где он застрял, чем заявить: «Да это у тебя синдром самозванца». И уж точно я не стал бы считать замечание «ты же сеньор» обратной связью. По нему невозможно понять, чего именно от тебя ждали и что в следующий раз сделать иначе.

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

Еще недавно вопрос о том, какой метод использовать для обработки коллекции, мог отправить разработчика в документацию, на Stack Overflow или обсуждения на Хабре. В удачный день там находился ответ. В менее удачный — обсуждение архитектуры проекта, квалификации автора и целесообразности его существования в профессии... Где-то между этими темами обычно прятались нужные три строчки кода.

Затем появились ИИ-чаты, которые можно было использовать как «продвинутый поисковик»: уточнять детали, показывать код, обсуждать варианты реализации. Заодно можно было попросить придумать имя методу, пока тот не стал processDataFinalReallyFinal.

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

Так, код стал появляться быстрее, но вместе с ним могла расти нагрузка на ревью, тестирование и сопровождение. Разработчик при этом работал еще и курьером между чатом и IDE.

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

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

В первой части я рассказал об AtsPLC - контроллере на ESP8266, который программируется на языке ladder прямо на нем самом: на OLED 128x64 и тремя кнопками. А во время работы эта же схема показывает состояние процесса.

Первая часть: Ladder на экране 0.96": программирую ПЛК тремя кнопками

Теперь расскажу, как это сделано. Речь пойдет об ESP8266, у которого всего около 80 КБ оперативной памяти, о FreeRTOS и о C++.

Расскажу, почему вам нужно отказаться от bool и Option. На примерах Rust покажу, как описать режимы и состояния через enum, чтобы код было проще читать, а компилятор не позволял создавать недопустимые состояния.

Я сделал контроллер на ESP8266, который можно программировать прямо на нем самом: на маленьком экране OLED 0.96" и всего тремя кнопками.

Программа пишется на языке Ladder Diagram. А во время работы эта же схема показывает, что происходит с процессом: какие контакты замкнуты, какие значения на входах, что включено на выходах. Компьютер для этого не нужен.

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

При разработке NanoVNA-X-BM (bare metal) мне пришлось разобраться, какие ошибки можно запретить через интерфейсы, что проверять на ПК и для чего всё равно нужен настоящий board.

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

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

ghbdtn и привет — это одни и те же клавиши. Понять, что имел в виду человек, нельзя в принципе. Поэтому фиксер не угадывает, а гарантирует: откат стоит ровно одно нажатие.

Тут The Register пересказал инженерный блог Anthropic, что мае этого года компания мержила в основную ветку около 2500 изменений в день, к сентябрю уже больше 30 000. Рост более чем в 12 раз потянул за собой инфраструктуру. CI делает около 25 миллионов чекаутов в сутки, и под такую нагрузку компания строит собственную систему контроля версий. В блоге о новом хранилище кода инженеры пишут, что очень часто их роль сводилась к тому, чтобы сказать Claude «нет», потому что агенты иногда нарушают ключевые ограничения системы ради шаблона, который в этом месте не нужен.

Еще, косвенный признак дает колонка Джона Стояна на InfoWorld. Он пишет, что коммитов стало больше, а пул-реквесты двигаются быстрее, зато многие организации сообщают о замедлении деплоев. Механизм он называет следующий: циклы ревью, терпимые на человеческой скорости письма, становятся ограничением, когда разработчики с ИИ выдают в два-три раза больше кода.

Прилетает задача: «нужно прикрутить безопасность к пайплайну». Берёте популярный сканер, втыкаете в CI/CD с дефолтным конфигом — и через десять минут пайплайн с треском падает под лавиной из 480 предупреждений. Через неделю постоянных ложных блокировок команда просто забивает на алерты: безопаснее не стало, релизы замедлились, а при слове «DevSecOps» все раздражаются.

Проблема не в инструментах, а в подходе. Разбираем, как собрать минимальный рабочий пайплайн с SAST, SCA и поиском секретов, который ловит реальные угрозы и не тонет в ложных срабатываниях. Для тех, кто не безопасник.

По статистике, среди рядовых пользователей настольных компов самая распространенная видеокарта имеет 16 ГБ видеопамяти. По опросам GaugeDB, такие карты занимают 27,21% рынка. У меня как раз видеокарта NVIDIA GeForce RTX 4070 Ti SUPER с 16 ГБ видеопамяти GDDR6X, которая на текущий момент стоит 900$. До сего момента главной проблемой было то, что на видеокарте такого класса невозможно было запустить LLM-агента, который будет достаточно умным и достаточно быстрым. Если запускаешь умную модель типа Qwen 3.8 27B (Dense архитектура), то на выходе получаешь 10-20 токенов в секунду. А для комфортной работы кодинг-агента надо 100-150 токенов в секунду.

Октябрьское обновление линтера для T-SQL: выложен на маркетплейс MS, добавлены правила, исправлены ложные срабатывания.

Продолжаю делиться выложенными в OpenSource библиотеками, которые использую в работе. В этот раз речь пойдет о наиболее универсальном, на мой взгляд, подходе для валидации приходящих с бэкенда данных: в клиентской части пишутся обычные TS DTO модели, а валидаторы создаются автоматически.

Вот ссылки на документацию на русском и английском, а в статье я сравню различные подходы к валидации.

Цена в базе осталась прежней, но приложение считает, что она изменилась, и повторно отправляет событие. Причина может скрываться в масштабе BigDecimal: equals() сравнивает не только числовое значение, но и количество знаков после запятой, поэтому 1.0 и 1.00 для него не равны. Разберём, как эта особенность влияет на коллекции, денежные расчёты и сравнение данных из разных источников, а также как нормализовать суммы и избежать подобных ошибок.

Все тесты пройдены, заказчик доволен. Но какое-то странное чувство всё равно не покидает. Зачем читать код, если ИИ может его самостоятельно отревьюить? А когда найдёт проблему - и исправить. Зачем вообще мне документация в эпоху chatGPT?

Но что, если за разумное время не получится найти решения? Если ошибочна сама постановка промпта? Как заглянуть в кроличью нору? И надо ли вообще?

Спустя полгода адаптации к OpenSource выпускаю еще две библиотеки из моего рабочего контура в одном npm-пакете - ARFA Generator и api-contract-check. В этой статье расскажу про первый инструмент, а второй презентую в рамках отдельной статьи.

Когда-то давно я уже писал статью про удобство использования файловых генераторов, интегрированных в долгоживущий процесс dev-сборки, однако за несколько лет развития и обкатки в реальных проектах концепт существенно расширился. Удобнее всего оказалось сместить бандлер с центрального места в один из сайд-эффектов после стабилизации кодовой базы, а разнородные инструменты проверки качества объединить в единый пайплайн с инкрементальным watch-режимом.

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

AI-агенты увеличили поток и размер PR, но время и внимание ревьюеров остались прежними. Я стал реже читать сгенерированный код построчно и чаще проверять спецификации, архитектуру, контракты и тесты. Разобрал исследования Google, Microsoft и open-source проектов: где AI помогает ревью, почему аппрувы становятся менее надёжным сигналом и что мы пока не умеем измерять.