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

В прошлую пятницу я объяснял джуну, почему его код на отсортированном массиве работает в шесть раз быстрее, чем на неотсортированном. Тот же массив, тот же алгоритм, и те же данные. Просто в другом порядке. Джун смотрел на меня как на сумасшедшего и, честно говоря, я его понимаю.

Потому что ответ звучит безумно: процессор внутри вашего ноутбука постоянно пытается предсказать будущее. Буквально. Он гадает, какая ветка if выполнится ещё до того, как условие будет вычислено. И на отсортированных данных ему угадывать проще.

Ну, давайте разбираться.

Простой вопрос, который разделяет инженеров и «операторов фреймворков»

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

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

В кодовой базе оказалось 41 034 метода и 2 170 файлов. Если считать только основной код, без тестов, 12 093 метода из 19 880 были вообще без комментариев. Покрытие документацией получилось 39%.

Это не история про чужой легаси-проект. Это мой текущий код. Он просто рос быстрее, чем я успевал его объяснять.

На бумаге у меня всё было нормально: README, заметки по архитектуре, большой CLAUDE.md, отдельные пояснения по важным решениям. Но когда смотришь на реальные вопросы, которые возникают по ходу работы, быстро выясняется, что документация покрывает только часть из них.

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

Я думал, у меня всё чисто. Bandit стоял, правила регулярно обновлялись, pipeline на каждый PR ругался на опасные места. Ну, знаете, как это бывает: где-то что-то подсветит, мы правим, живём дальше, чувствуем себя молодцами, прикрыв тыл статическим анализом.

А потом я решил копнуть глубже. Не для галочки, а руками, с инструментом, который умеет ходить по коду не линейно, а как по графу.

Знаете, сколько нашлось?

У вычислительной программы есть два ресурса: время (циклы CPU) и пространство (оперативная память). Но как они заменяют друг от друга? Правда ли задачу, которая решается в полиномиальном пространстве , можно решить за полиномиальное время ?

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

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

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

Привет, Хабр! На связи Алина, старший Android-разработчик в команде Инвестиций «Совкомбанк Технологии». Сегодня поговорим о том, как заставить Android Studio самостоятельно следить за порядком в коде – без ручных проверок и без вечных напоминаний в командном чате.

В этой статье мы создадим практические правила для инструментов статического анализа кода и разберем, как внедрить их в проект. На примере lint рассмотрим контроль архитектуры пакетов и обязательную документацию с QuickFix, а на примере detekt – проверку неизменяемого состояния представления без Android-зависимостей и миграцию с RxJava на Coroutines.

В данной статье вы познакомитесь с типичными ошибками и привлекающими внимание подходами, которые можно встретить в разных Open Source проектах. Без воды, только конкретные комментарии. Будет полезно и для своих проектов.

Я написал CLAUDE.md на 200 строк. Исследование ETH Zurich на 138 репозиториях говорит: мой агент стал от этого тупее на 3%, а я плачу на 20% больше за токены. Разбираюсь, что пошло не так.

Дисклеймер: Эта статья не о том, что «Vibe Coding — это зло». Если вам нужно быстро склепать прототип для презентации инвесторам или сделать лендинг за час — вперед, это легитимный инструмент. Эта статья о том, почему для профессионального роста и долгосрочной устойчивости как инженера важно разделять понятия «погонщик ИИ» и «инженер, использующий ИИ».

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

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

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

Здесь я не буду обсуждать, стоит ли использовать ИИ в разработке. Ответ однозначный: это новая реальность. Нейроагенты дали нам новый уровень абстракции, так же как от ассемблера мы перешли к компилируемым языкам, от них к скриптам, от скриптов к декларативному программированию. Цель у всего одна: научить компьютер понимать человеческий язык. И вот — цель достигнута.

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

В 1988 году бортовой компьютер с памятью 128 КБ посадил космический корабль в шторм. Сегодня ваш смартфон с многоядерным процессором заикается при скролле списка контактов. Мы привыкли думать, что данные невесомы, а JSON – это «просто текст». В этой статье мы препарируем один обычный fetch-запрос и посчитаем его реальную цену: в байтах, миллисекундах и скрытых архитектурных издержках. Разберемся, почему мы стали «поколением JSON» и как вернуть себе инженерную осознанность в эпоху избыточности.

Написал небольшую библиотеку для Spring Boot, которая добавляет типизированные @Conditional-аннотации для работы с конфигурацией через Environment...

TLDR; Разработка ПО в привычном нам виде, сложившаяся в течение десятков лет, уходит в прошлое. БЯМ-ассистенты для программирования фундаментальным образом изменили наше ремесло, и ещё не известно, к добру или к худу.

Я работаю тимлидом в достаточно крупной компании и хочу поделиться некоторыми мыслями относительно AI: как его применяют в моей команде и как я использую его сам, а также описать некоторые наблюдения и личные ощущения. В IT я работаю уже около 20 лет, соответственно, повидал всякое, но AI, на мой взгляд — нечто совершенно новое.

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

Всем привет!

Некоторое время назад я опубликовал статью о своём опыте AI-кодинга и поделился рабочими практиками. В комментариях нашёл много полезного — в частности, упоминания методологии SDD.

Это натолкнуло меня на идею: собрать инструмент, который позволяет управлять и автоматизировать процесс разработки, основанной на спецификациях и контроле генерации кода. Я приступил к реализации — очень плотно и почти без сна за все эти дни o_O.

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

Code Metal привлёк $125 млн на переписывание кода оборонки с помощью ИИ. Google и Microsoft сообщают, что 25–30% нового кода генерируется ИИ. AWS перевёл 40 млн строк COBOL для Toyota. CTO Microsoft прогнозирует, что к 2030 году 95% кода будет написано ИИ. Переписывание мирового софта — не прогноз, а факт.

Anthropic недавно построила C-компилятор на 100 000 строк за две недели силами параллельных ИИ-агентов — меньше чем за $20 000. Он загружает Linux, компилирует SQLite, PostgreSQL, Redis. ИИ создаёт масштабный софт с поразительной скоростью. Но может ли он доказать корректность компилятора? Пока нет. Формальную верификацию результата никто не делает.

Андрей Карпати описал типичный паттерн: «Я нажимаю "Принять всё", я больше не читаю диффы». Когда ИИ-код достаточно хорош в большинстве случаев, люди перестают внимательно проверять его. При этом почти половина ИИ-кода не проходит базовые тесты безопасности, и более крупные модели не генерируют более безопасный код, чем предшественники.