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

Если вы начинающий программист и у Вас нет машины, то лучшее решение - машина Тьюринга (МТ)! Я в этом вам помогу, а еще Макконнел. Но и не только он один.

Первая моя статья на Хабре о машинах Тьюринга это про тяжелый грузовик [1]. А оно такое надо? Начинать лучше с чего-то полегче. Этим и займемся. Хотя основа или, так сказать, базис по большому счету будет один. Но, ведь, между карьерным самосвалом и самой простой «инвалидкой» тоже есть много общего? И то и другое явно не самолет.

В монографиях Макконнела [2], Карпова [3] и еще много где устройство МТ расписано по винтикам, которых не так уж и много. Я, например, когда-то начинал с книги А.Трахтенброта [4].  Также можно, не мудрствуя лукаво, запустить эмулятор МТ. Их  в Инете найти не сложно. И сразу погонять, не вникая в «винтики». Но это для самых отвязных, т.е. тех, кто не боится снести крышу.

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

Подобие конструктора можно найти у Карпова Ю.Г. Но это пара набросков на псевдокоде. Мы же возьмем конкретный язык и конкретную реализацию. А для совсем уж ленивых будет доступен код по ссылке на Git-репозитарий.

Подобно Макконнелу я за «активный обучающий подход». Т.е. следую его заветам. Хотя следовал я им задолго до знакомства  с его идеями. И это даже хорошо, т.к. не отвлекало. В результате я пошел  даже немного дальше. Для анализа алгоритмов использовал не псевдокод, а другой вариант – формальную вычислительную модель и ее реализацию. Такой «математический псевдокод» позволяет делать  анализ проще, глубже и точнее. По результатам написал статью во времена, когда журналы еще издавались [5].

Есть такая старая программистская байка, что нельзя платить программистам за строки кода, так как тогда они будут писать длинный бестолковый код и любить метод copy-paste. Будущее наступило. Только теперь этими “программистами” является генеративный ИИ (GenAI), которому как раз платят за строки кода. Иронично.

Один из моих интересов — изучение сгенерированного С++ кода, чтобы понимать, как развивается индустрия создания ПО, какие проблемы уходят, а какие наоборот возникают. После заметки “Дайте посмотреть на нормальный С++ проект, созданный вайб-кодингом” мне предложили заглянуть в проект VibeTensor, что я и сделал.

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

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

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

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

В августе у Google вышел текст о том, почему Go хорошо подходит для разработки с агентами. С тезисами спорить трудно: единый форматтер, быстрая компиляция, строгий компилятор, большая стандартная библиотека, обещание совместимости. Беда в том, что из этих тезисов не следует ни одной строчки конфига. Хорошие свойства языка сами по себе не мешают агенту сдать диф, который собирается, проходит тесты и при этом делает совсем другое.

Дальше о том, как довести идею до инженерного состояния. Почему форма сообщения об ошибке влияет на исход правки сильнее, чем формулировка промпта. Какие поломки Go пропускает молча и чем их ловить. Как за полчаса написать свой анализатор, превращающий договорённость команды в ошибку сборки. И чем закончились попытки закрыть тот же вопрос документом AGENTS.md. Всё обкатано на монорепозитории примерно на сто восемьдесят тысяч строк, где за последний квартал около половины дифов написал агент.

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

Поводом стали два наблюдения из моего обычного рабочего процесса. А потом я полезла в Issues репозитория Codex и обнаружила, что похожее поведение замечала далеко не только я.

Благодаря искусственному интеллекту код удешевился. Но ошибочные архитектурные решения остаются такими же дорогими, как и раньше.

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

Давайте объясню это на конкретном примере. Система электронных продаж, написанная на Java — как раз такая штука, с которой большинство бэкендеров сталкивались хотя бы раз на протяжении карьеры.

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

Через несколько дней (говно)кода стало много — вменяемого сервиса не получилось.

Один BFS принимал map[string][]string. DFS жил на другом типе графа. В одной реализации направленность задавалась на уровне графа, в другой вытекала из того, как было записано ребро. Опции существовали, но их комбинации не образовывали понятной политики. Result types возвращали срезы и числа, однако я не мог внятно ответить, что именно они гарантируют.

Проблема была не в том, что LLM «не умеет BFS». Я попросил реализации раньше, чем сформулировал общий контракт данных. Генератор заполнил пустые места правдоподобными допущениями — которые, очевидно, не совпали в разных кусках кода.

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

Как специалист по безопасности получил доступ к панели администратора, почему старую версию пришлось остановить и как после этого мы заново построили защиту. 

Продолжение истории о человеке, искусственном интеллекте и безопасности 

Коротко о первой части

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

У меня 12 лет опыта в Go. И я больше не имею права назвать себя программистом: мой код не пройдёт ту планку качества, которую я выставил для своих агентов. Хотя честнее так: они сами её выставили, я лишь ставил цели.

Заявление громкое, но у меня есть график. Красная пунктирная линия на нём: уровень моего лучшего рукописного кода. Синяя кривая: код, который пишут агенты. В апреле 2026 кривая ушла под красную линию и продолжает падать.

Эта статья прежде всего будет полезна студентам и начинающим специалистам.

В отрасли разработки программного обеспечения под системным дизайном (System Design) понимают процесс проектирования архитектуры, компонентов, баз данных и связей информационной системы. Цель системного дизайна - обеспечить масштабируемость, отказоустойчивость и высокую производительность системы, в том числе при росте нагрузки. 

В первой статье по этой теме https://habr.com/ru/articles/1054184/ я рассказывал про принципы декомпозиции программной системы на модули и слои программных компонентов на примере задачи разработки бэкенда корпоративных чатов, рассмотрел пример реализации модуля идентификации и аутентификации пользователей на языке программирования Go.

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

Я Go-разработчик, но у меня есть собственный проект — и это значит, что Go только часть работы. В обычную неделю я переключаюсь между Go-бэкендом, SQL, React и TypeScript, дизайном API, архитектурой, Docker, CI/CD, инфраструктурой, тестами и UX.

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

AI помогает. И примерно здесь у всех начинается один и тот же спор: Claude или Codex? Кто лучше пишет код, за какую подписку платить.

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

задача → нейросеть сама придумала → сама написала → сама себя проверила → сказала, что всё готово

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

Поэтому я перестал выбирать и развёл роли: Claude принимает решения. Codex реализует. Claude независимо проверяет результат.

Это дало три вещи, а не одну:

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

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

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

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

Один такой размер зашит в .NET по умолчанию — им копируются потоки. Проверил на четырёх машинах и трёх рантаймах.

Дисклеймер: статья для разработчиков уровня junior и middle, которые знакомятся с принципами чистого кода и SOLID. Примеры кода — PHP 8.1+.

Всем доброго дня! На связи Валевич Артем — тимлид в компании AGIMA. В первой части серии мы разобрали Single Responsibility Principle на кейсе системы отзывов и пришли к простому выводу:

Скопированный шаблон Битрикс24 может годами работать без нареканий, а после очередного обновления оставить раздел с белым экраном.

Разберём три способа кастомизации на одном компоненте и посмотрим, какие доработки переживают обновления, а какие требуют постоянного сопровождения.

По данным GitLab, 91% компаний держат в работе минимум два ИИ‑инструмента, 54% — три и более. 78% команд пишут и коммитят код быстрее, чем раньше, 60% говорят, что отдача от ИИ превзошла ожидания, 73% отмечают рост качества кода. По любым меркам внедрение состоялось. А теперь «менее успешная цифра»: 80% признают, что подключили ИИ‑инструменты раньше, чем придумали, как ими управлять. Скорость обогнала контроль, и вся история начинается ровно на этом стыке.

В прошлый раз я писал о переходе на Spec-Driven Development и честно оговорился: над спеками у меня надстроен слой roadmap, и это не канон Spec Kit. В коробке верхний уровень - спека, ничего выше не предусмотрено. Потом я открыл concepts/spec-of-specs.html в официальной документации. Там черным по белому описано ровно то, что я делал последние недели. С той же мотивацией, с той же структурой, местами теми же словами. Но разница есть…

Точнее, на Spec Kit от GitHub. Полгода назад я бы над этим посмеялся: спеки, планы, декомпозиция задач - привет из 2010-го, когда это называлось waterfall и все дружно от него убегали. Оказалось, убегали не от спек, а от того, что их писали люди и потом никто не читал. В этой статье расскажу, где я отхожу от стандарта в угоду скорости.

Что такое SDD в исполнении Spec Kit по сути…

Привет, Хабр!
Это первая статья из планируемого цикла про мой объектно-ориентированный подход к написанию кода для микроконтроллера stm32 (а именно камня stm32f303vc на отладочной плате stm32f3discovery) с использованием возможностей языка вплоть до стандарта c++20. Но обо всём по порядку.