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

Привет. Я фронтенд-разработчик. По мнению тех, кто, по мнению некоторых, перекладывает джейсончики туда-сюда, я крашу кнопочки. Но сам я себя идентифицирую иначе: я тоже перекладываю джейсончики, и у меня всё точно так же, как у них. Даже архитектура. У меня тоже есть контроллеры, сервисы и хранилища, и я также обрабатываю запросы пользователей. Даже больше, я делаю HATEOAS, «тру» RESTful, если хотите. Давайте расскажу, как я к этому пришел.

Когда-то давно я только верстал. Накидывал разметку, добавлял классы, идентификаторы и стилизовал ЦСС-ом. И было хорошо. Потом от меня потребовали динамичности — пришлось добавить JavaScript. И было очень хорошо.

Технологии развивались, и мне хотелось пробовать новое. Я попробовал AJAX. Это было так волнительно... Я сказал бэкендерам: основную разметку жду от вас, а опции для выпадающего списка, например, отдавайте джейсоном по запросу. Они были не в восторге. «Одному HTML подавай, другому CSV, третьему ещё что-то — безобразие!» Но мы нашли компромис. Бэкэндеры сказали: «Вот вам, мол, джейсон, дальше сами как-нибудь». И назвали это REST API.

Сначала было очень круто! Мы, верстальщики, организовались. Мы стали фронтендерами! Конечно же, мы сразу побежали решать ещё нерешённые сто раз решённые задачи. Мы писали библиотеки и фреймворки — четыре миллиона штук! Да у нас даже есть библиотека с функцией для умножения чисел — lodash.multiply. Мы придумывали свои паттерны и архитектуры, например FSD. Короче, мы стали очень крутые.

Но то уже были «мы», а не я. Мне было сложно. Шутка ли, изучать по одному новому фреймворку в неделю? А ведь еще переписывать всё надо, стек-то устарел... В общем, в какой-то момент я перестал поспевать за модой и справляться со сложностью. Переходишь из одного проекта (на React) в другой (на Vue), а там всё иначе. Берешь нового разработчика в команду с опытом в React, например, а ему нужно время, чтобы вникнуть, потому что в его старой команде был другой «стейт-менеджер». Вавилон, никто друг друга не понимает.

Привет! Это снова Михаил Федоров. В первой статье я рассказал про архитектуру QA Assist — системы из 11 AI-агентов для автоматизации тестирования. Во второй — честно показал, как «4 часа подключения» превращаются в неделю корпоративной реальности.

Сегодня поговорим о штуке, которая на первый взгляд не имеет отношения к AI. О пирамиде тестирования. О том, почему классическая теория QA внезапно оказывается критически важной, когда вашим тест-дизайнером становится языковая модель с контекстным окном.

На одном из созвонов потенциальный заказчик поделился болью:

“Меньше чем за год велосити команды внешнего вендора упала в разы. Почему задачи, которые должны занимать 2–3 дня, растягиваются на недели?”

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

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

Заказчик решил разобраться и обратился к нам.

Мы посмотрели код, провели техническую оценку команды и разобрали, кто какие задачи закрывает. Важно было не то, что написано в CV, а то, как команда работает на практике.

Картина оказалась неожиданной - около 30% команды были junior-разработчиками.

Не “почти senior”.

Не middle.

Именно junior!

При этом бюджет проекта строился исходя из senior-ставок.

Когда мы начали разбираться, выяснилась еще одна деталь - на замену специалистов заказчик никакого апрува не давал. Часть senior-разработчиков постепенно заменили на junior. Это происходило не сразу, а постепенно, поэтому долго оставалось незаметным. Формально команда оставалась «той же», но по факту ее уровень изменился.

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

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

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

Прежде чем погружаться в архитектуру, давайте посмотрим на контекст, в котором всё это происходит.

По данным исследования McKinsey 2022 года, технический долг составляет до 40% всего технологического портфеля компаний. И это не просто цифра в отчёте. Согласно опросу 2024 года среди технических руководителей, у более чем 50% компаний технический долг занимает свыше четверти всего IT-бюджета, блокируя внедрение новых функций. (Источник: vFunction, 2025)

При этом исследование Carnegie Mellon выяснило, что наибольшим источником технического долга являются именно архитектурные проблемы — а не баги и не плохой код на уровне функций.

Теперь о Go. По данным Go Developer Survey 2024, главной проблемой команд, работающих с Go, названо поддержание единых стандартов кода — в том числе из-за разного уровня опыта участников и привнесения не-идиоматических паттернов из других языков. (Источник: go.dev/blog/survey2024-h2-results)

Это напрямую про нашу тему: люди приходят из Java, Python, C# и приносят с собой архитектурные привычки, которые в Go не работают. Clean Architecture и DDD — не исключение. Их часто реализуют "как в Java", а потом жалуются, что Go — многословный и неудобный язык.

Давайте разберёмся, как делать это правильно.

Как мы сюда попали?

Представьте: вы начинаете новый Go‑сервис. Читаете статьи, смотрите видео, решаете «делать по‑взрослому». Создаёте структуру:

Одна из сложностей с LLM: как понять, какая модель способнее? Их создатели наперебой кричат «мы совершили революцию», но как пробиться сквозь хайп и измерить, кто чего реально добился?

Казалось бы, для этого есть много популярных бенчмарков. И о преимуществах моделей зачастую рассуждают со ссылками на них: «Смотрите, эта на 5% лучше». Однако с такими бенчмарками связан целый ряд проблем, и им нельзя слепо доверять.

А нам в Kodik важно разбираться, потому что мы делаем редактор кода с ИИ, так что должны понимать, какая модель в нём как себя покажет. И в результате мы не только смотрим на результаты чужих бенчмарков, но и создали для внутреннего использования свой KodikBenchmark.

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

При решении очередной задачи по небольшой "модификации" ПО- возникло решение запуска его под ВМ. По рукой уже стояла Oracle VirtualBox. Но вот незадача- ПО опознало виртуалку и отказалось выдать триал период. 2 промпта и 3 минуты на копирование и сборку решили проблему.

Привет, Хабр! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. В предыдущих статьях я рассказывал про QA Assist — AI-ассистента для тестирования. Сейчас идёт пилот на реальном проекте, копятся метрики и грабли — но писать об этом пока рано. Результаты будут, а пока давайте поговорим о чём-то другом.

Однажды друг в шутку спросил: «А тестировщики вообще могут верить в Бога? Это же не совместимо, нет?»

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

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

Для такого вот аппаратного ключа администратора нам понадобилось провести статический анализ кода. Как мы это делали - в статье.

Добрый день, уважаемые коллеги!

Хотел бы сегодня рассказать о несколько необычном опыте анализа кода. Предваряю возмущение многих – да, мсье действительно знает толк в извращениях 😊

Итак, о них родимых. В одном нашем изделии понадобилось защитить от несанкционированного доступа администраторскую консоль управления, банальный COM-порт с мостиком USB-UART на основе FT232. К сожалению, классическое решение с логином/паролем было обставлено целым частоколом формальных требований в виде (1) срока жизни паролей, (2) логирования успешных/неуспешных попыток, (3) минимальной длины паролей, (4) минимальным их алфавитом, (5) требований к применению больших и малых букв, и цифр, и спезнаков, именно «И», а не «ИЛИ». Перечислять можно бы и дальше, но зачем?

Объехать все эти требования по обочине было решено нестандартным путём – поскольку все требования относились к программному продукту, а про аппаратные устройства ничего не было сказано, то мы просто применили АКА – аппаратный ключ администратора. Он втыкается в разрыв USB-кабеля, идущего от АРМ администратора к устройству, и по свободным линиям обменивается с Изделием сообщениями по схеме challenge-response, не передавая напрямую через линии связи общий секрет, при этом перехват сообщений злоумышленнику не даёт ровно ничего. Если кому интересно, как конкретно это сделано – пишите в комменты или в личку.

Поскольку к историческому моменту принятия решения мы все были в жёстком цейтноте, изготовление АКА поручили стажёру. А он возьми и выбери за основу для разработки «голубую пилюлю (BluePill)» и STM32. Возмущаться, спорить и учить вечному было уже некогда, и тимлид, махнув рукой, согласился. Забегая вперёд, скажу, что отказов и/или сбоев АКА как с самого начала не наблюдалось, так и не наблюдается по сей день. Да, наверное, ПЛК на Ардуине – это уже слишком, но костыль и велосипед проходит вполне (рискую быть бит жёлтыми тряпками, но что было, то было).

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

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

На каждой второй конференции по медицинскому AI звучит один и тот же сценарий: «Дообучим мультимодальную модель, скормим ей DICOM, и она сама выдаст диагноз». На практике, когда этот скрипт пытается попасть в реальную клинику, начинаются неожиданности. OOM на GPU, врачи не понимают, где галлюцинация модели, а где финальный отчёт, двухгигабайтные NIfTI-исследования рвут таймауты балансировщика.

Я какое-то время тоже думала, что главное — это модель. А потом пересмотрела собственный код. У меня уже есть MRI Second Opinion. Но это не нейросеть. Это контур с доменной моделью, конвейером приёма данных, циклом обработки, обязательным врачебным рецензированием, финализацией и отдельным репозиторием с открытым кодом. В медицинском IT модель — не главная проблема. Главная проблема — чтобы между входом и выходом ничего не потерялось и не сломалось.

PR утвердили за четыре минуты. Авторизация легла через три дня. 84% разработчиков используют AI-инструменты - 29% доверяют тому, что выкатывают в прод. Разницу между этими числами я назвал «галлюцинация продуктивности».

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

Красиво, правда? Прямо слайд для презентации. Давайте проверим эту цифру на реальном проекте — и посмотрим, насколько я был честен с вами (спойлер: не совсем).

Открыл MR на ревью. 847 строк. Тесты зелёные. Линтер чистый. Не понимаю ни одной строчки. GitClear проанализировали 211 миллионов строк - и нашли проблему, которую не видно ни в каких метриках.

Когда код уже написан, половина багов уже не исправить. Парадокс? Нет — статическое тестирование. В этой статье разбираю, как находить дефекты ещё на этапе требований, почему «большой взрыв» интеграции — это путь в никуда, и зачем знать про заглушки, драйверы и уровни от компонентного до UAT.

Почему ИИ-агенты усложняют понимание кода?
В этой статье разберем, как концепция Питера Наура «программирование как построение теории» объясняет скрытые риски использования LLM в разработке.

Итак, что мы имеем в моменте

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

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

Разбираем Common Vulnerability Scoring System – что скрывается за цифрой от 0 до 10, как читать базовые, временные и контекстные метрики, и где искать актуальную информацию об уязвимостях.

Привет! Меня зовут Михаил Федоров, я руковожу центром компетенций QA. Мы решили не нанимать ещё двух тестировщиков, а написать систему AI-агентов, которая берёт на себя 80% рутины QA-инженера – от анализа требований до Merge Request с готовыми автотестами. В этой статье расскажу, как устроена архитектура, какие грабли мы собрали, и что из этого вышло на практике.