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

Цена в базе осталась прежней, но приложение считает, что она изменилась, и повторно отправляет событие. Причина может скрываться в масштабе 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 помогает ревью, почему аппрувы становятся менее надёжным сигналом и что мы пока не умеем измерять.

В решении «ChatGPT, Codex + Claude для 1С» появились новые возможности для разработчиков и специалистов сопровождения. Теперь помощник может изучать программный код конфигурации, находить связанные процедуры и функции, готовить изменения расширений и проверять доработки после обновления 1С.

Вчера я провел лекцию для 4 групп студентов-первокурсников, будущих программистов из нашего йошкар-олинского университета ВОЛГАТЕХ.

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

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

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

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

В этой статье я, Алексей Соболеков, архитектор решений, разберу зачем и как в агентской разработке формировать понятные спецификации. Ранее я разобрал Роль Solution Architect с приходом AI-агентов: что изменилось в 2026 году.

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

Последние месяцы я делаю 3D‑мир, который работает прямо в браузере — на Three.js: сцена, персонажи, сеть. Самое неприятное в производительности браузерного 3D — не ошибки. Ошибку видно: она в консоли, у неё есть стек и виновник. А есть второй класс проблем: всё работает, ничего не падает, просто тормозит. Консоль чистая, кадры падают, и непонятно, с чего начинать.

Ниже — три таких случая из моей практики. У всех трёх общая черта: проблема не в самой отрисовке картинки, а рядом с ней. И у каждого есть конкретные цифры до и после. Речь про Three.js, но большинство выводов переносится на любой WebGL‑стек.

Как загрузить качественным топливом конвейер разработки? Как измерить эффективность симбиоза человека и машины?

Качество данных (DQ) связано с технической зрелостью продукта, но не сводится к ней. В большой системе проблема редко ограничивается одной таблицей или ошибкой. Запись может быть технически корректной, но, например, появиться в базе дважды. Или другой пример: статус может быть допустимым для конкретной базы, но расходиться со статусом подписки в соседнем продукте. Итоговая бизнес-метрика при этом может выглядеть вполне правдоподобно, хотя ошибка уже возникла, причем давно.

Привет, жители Хабра! Я Ольга Жучкова, один из главных администраторов данных MWS. Я отвечаю за внедрение практик DG в кластере и выступаю амбассадором направления: помогаю продуктовым командам внедрять практики работы с данными и показываю, как эта работа улучшает продукт. В моем кластере работают более тысячи сотрудников. В каждом из этих продуктов, где есть БД, хранятся уникальные или критичные данные. А значит, есть свой администратор данных продукта, с которым я взаимодействую. На примере МТС Premium расскажу, как мы выстроили систему проверок качества распределенных данных — от локальных ошибок в базе до сквозных процессов и бизнес-метрик.

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

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

Чтобы не терять связь с проектами, я решил внести несколько важных правил при разработке проектов с помощью AI.

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

Чтобы это выяснить, приходится пройти от точки запуска до обработчика, от обработчика — до зависимости, от зависимости — до провайдера. Заодно проверить, кто вызывает общие функции и что останется после удаления старой ветки. Именно на восстановление этих связей я хочу тратить меньше времени.

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

Cockroach Labs обнаружила тысячи лишних слов в инструкциях агентов. Я сопоставил их опыт с собственным случаем: три предложения новых правил после проверки существующего кода свелись к одной доработке.

Часть один

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

Один, два, три

Bы нaвepнякa дeлaли этo мнoгo paз: нaшли в пpoeктe пoдxoдящий для peшeния зaдaчи кoд, cкoпиpoвaли, зaмeнили в кoпии пepeмeнныe или вызoвы фyнкций нa дpyгиe, нo пpи выпoлнeнии пoлyчили нe тo пoвeдeниe, которое oжидaли? Bepoятнo, пpи peдaктиpoвaнии чтo-тo ycкoльзнyлo oт вaшeгo внимaния. Имeннo тaк poждaютcя oшибки, o кoтopыx пoйдёт peчь в этoй cтaтьe.

Привет, Хабр! Меня зовут Иван Тарасов, я TUL Architecture Governance в техплатформе Авито. Одна из моих команд — SLA — создаёт условия для повышения технической надёжности, а также развивает инструменты NFR и сценарии стабильности.

В этой статье я расскажу, как в Авито устроена система измерения надёжности: от SLI/SLO/SLA и разницы между Stability Rate и Uptime, до устройства NFR для REST/RPC-сервисов, шин данных и кастомных операций.

Также поясню, чем концепция бюджета ошибок в Авито отличается от канонического описания в книге Google SRE, и почему это не случайное отклонение, а намеренное решение.

При проверке десяти статей Haiku совместила PASS и замечание major. Разобрали отчет по исходникам: что исправили, что отклонили и какого контекста не хватило самой модели.

Два парсера курсов месяцами возвращали пустоту. Ни ошибки, ни строчки в логе. Про то, что отсутствие данных — режим отказа по умолчанию, и про CI, который парсит и валидирует за меня.

Автор форка Pii-Mask добавил исправления и тесты обработки Word и Excel. На нашей версии 13 его тестов не прошли. Покажу один найденный пропуск и расскажу, как взаимный перенос тестов помог подготовить план исправлений и сохранить улучшения обеих веток.

Я к вам пишу — чего же боле?
Агент все может написать.
Но за ошибки поневоле
Придется вам же отвечать.

(Письмо инженера Татьяны к вайбкодеру Евгению)

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