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

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

sa-tests-db полезен ровно потому, что это внешний набор для проверки анализаторов. Он нужен не для красивой демонстрации, а для грубой, неудобной вещи: взять инструмент и посмотреть, как он проходит квалификационный критерий на чужом корпусе, а не на примерах, которые вы сами себе подготовили.

В контексте ГОСТ Р 71207-2024 это особенно важно. Там недостаточно сказать: «в среднем по языку результат хороший». Смотреть нужно по типам ошибок. Если по какому-то типу ошибок анализатор даёт слишком много ложных срабатываний или слишком много пропусков, это уже проблема, даже если общая картинка выглядит прилично.

С 2021 года я работаю на стыке двух отраслей - цифровой и сельского хозяйства. За это время мышление у меня заметно профдеформировалось: я все чаще смотрю на другие сферы через сельхоз-призму. Мне пришла мысль провести аналоги между ИТ и племенным животноводством. Да простят меня айтишники и племенные бычки...

За свой многолетний опыт я не встречал основательного подхода к логам приложений.
Часто я слышал фразы: "что нужны логи", "логи плохие" и т.д.
Но они слишком общие и могут означать все и ничего одновременно.

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

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

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