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

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

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

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

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

Хабы: Программирование, Разработка, Управление разработкой
Теги: надёжность, архитектура, спецификация, программирование, управление разработкой

Это первый из трёх постов серии «Надёжное программирование: от кода к технологии». В нём — главный тезис и три столпа. Во втором разберём оракульное смещение и эмпирику DORA, Veracode и FormAI-v2. В третьем — конечного аудитора, шкалу L0–L4 и практические рекомендации.

Несколько месяцев назад я зачем-то полез изучать теорию категорий. Причины были примерно те же, по которым нормальные люди иногда решают разобраться в квантовой механике по роликам на YouTube: звучит умно, выглядит загадочно, а главное – можно потом с важным лицом употреблять слово «эндофунктор» в компании людей, которые не могут проверить, несёшь ты ахинею или нет. В моём случае ситуацию усугубляла любовь к функциональному программированию, поэтому рано или поздно столкновение с теоркатом было неизбежно.

Первые впечатления были соответствующими. Категории, морфизмы, функторы, естественные преобразования, монады, знаменитое «монада – это моноид в категории эндофункторов». Я читал определения, вроде бы даже понимал отдельные слова, закрывал книжку и через пару часов снова не мог ответить на простой вопрос: а зачем мне всё это как программисту? Я пишу обычные приложения, крашу кнопки, перекладываю JSON из одного места в другое. Где в этой картине должны появиться все эти стрелочки?

После маскировки ФИО в тексте может остаться номер, по которому человека найдут в открытом реестре. На восьми искусственных примерах проверим остатки по заранее заданному списку и посмотрим, что меняется при отключении нормализации и распознавания имен.

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

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

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

Представьте: вы настроили CronJob, протестировали локально и выкатили в продакшн. Всё работает как часы. А потом решили добавить отказоустойчивости и развернули приложение во втором дата‑центре. И внезапно ваша задача начала выполняться дважды. Это не баг Kubernetes, а фундаментальная проблема синхронизации.

Меня зовут Тимофей Салтымаков, я бэкенд‑разработчик в Точка Банк. В статье расскажу, как мы решили проблему дублирующихся CronJob'ов в распределённой системе. Прошли путь от advisory locks до собственной библиотеки, и в итоге поняли, что нужно перестать синхронизировать процессы и начать синхронизировать... время. Поехали!

Я не программист. По крайней мере, несмотря на то, что в 2010 году я закончил «Прикладную информатику в менеджменте» (ДГТУ) и учился писать на C++, таковым в настоящее время себя не считаю.

При этом с июля 2026 года я управляю большим продуктом (собственная фабрика аналитики, своего рода ERP внутри компании), код которого пишут ИИ‑агенты. Я даю задачи голосом (не помню, когда в последний раз формировал текст задач на клавиатуре), агенты пишут код, проверяют его и выкладывают новую версию на сайт. Продукт собран на Next.js 16, TypeScript и PostgreSQL. На 1 октября в истории проекта уже более 6500 коммитов и 1.800.000 строк кода.

Код я не читаю. Поэтому между словом агента «готово» и появлением новой версии на сайте стоят автоматические проверки. Их называют «сторожами», сейчас их около двухсот. Если хотя бы один сторож покраснел, новая версия не попадает на сайт, а я получаю в Telegram сообщение «выкат остановлен» со списком красных.

Так я узнаю, готов ли продукт. И несколько раз эти проверки говорили неправду. Ниже пять примеров: что случилось, как мы это заметили и что изменили.

Спор о русском в коде обычно ведут идеологи. Одни требуют «программировать на родном», другие крутят пальцем у виска. Но если убрать эмоции, остаётся инженерная задача: где локализация снимает трение, а где создаёт новое?

Мы 60 лет учим разработчиков думать по-английски, чтобы они могли программировать. Не «знать английский» — это нормально. А думать на нём, когда пишут код на русском домене. Юрист, читающий спецификацию, и разработчик, читающий код, говорят на разных языках — и мы называем это профессиональным стандартом.

Пора это признать. И посмотреть, во что это обходится на практике.