В прошлой статье я показывал CodeClone как инструмент для поиска структурного дублирования в Python-коде. Не только буквальной копипасты, но и повторяющихся функций, похожих блоков и одинаковых контрольных конструкций.
За это время проект заметно изменился. Если раньше это был в первую очередь детектор клонов, то 2.0.0b1 — уже скорее инструмент для контроля структурного здоровья проекта в CI.
Программисты много пользуются библиотеками. Но спроектировать библиотеку сложно. В этой статье я изложу некоторые соображения по поводу того, как создавать библиотеки.
Для начала разграничим, чем нам приходится заниматься при программировании. Попробуем представить акты программирования как беседы. Далее разберём, какие основные виды деятельности складываются в «программирование», как его принято понимать. Всё это послужит нам основой для разработки более качественных программных библиотек.
Я довольно долго жил с привычной инженерной отговоркой: ну да, поиск по шаблонам шумит, зато работает быстро. Где-то подсветит лишнее, где-то что-то пропустит, но в целом жить можно. Так обычно и живут, пока не появляется внешний корпус, который не интересуют наши внутренние оправдания.
У меня таким холодным душем стал свежий прогон sa-tests-db по ГОСТ Р 71207-2024 на текущем HEAD CodeGraph. Это уже не история в духе «нам кажется, стало лучше». Тут либо проходишь критерий, либо нет. Причём не по красивой суммарной цифре, а по каждому типу ошибки отдельно.
И вот здесь самое интересное: что именно пришлось добавить в анализатор, чтобы он перестал смотреть на код как на набор соседних строк и начал видеть реальные пути данных.
С 2021 года я работаю на стыке двух отраслей - цифровой и сельского хозяйства. За это время мышление у меня заметно профдеформировалось: я все чаще смотрю на другие сферы через сельхоз-призму. Мне пришла мысль провести аналоги между ИТ и племенным животноводством. Да простят меня айтишники и племенные бычки...
За свой многолетний опыт я не встречал основательного подхода к логам приложений.
Часто я слышал фразы: "что нужны логи", "логи плохие" и т.д.
Но они слишком общие и могут означать все и ничего одновременно.
Предлагаю детально разобраться, как именно можно писать логи в этой статье.
В прошлую пятницу я объяснял джуну, почему его код на отсортированном массиве работает в шесть раз быстрее, чем на неотсортированном. Тот же массив, тот же алгоритм, и те же данные. Просто в другом порядке. Джун смотрел на меня как на сумасшедшего и, честно говоря, я его понимаю.
Потому что ответ звучит безумно: процессор внутри вашего ноутбука постоянно пытается предсказать будущее. Буквально. Он гадает, какая ветка if выполнится ещё до того, как условие будет вычислено. И на отсортированных данных ему угадывать проще.
Ну, давайте разбираться.
Простой вопрос, который разделяет инженеров и «операторов фреймворков»
Дисклеймер для опытных: если вы знаете ответ – внутри реальный кейс, как этот баг сломал мой паспорт в проде, и история с собеседования, от которой хочется плакать.
12 093 метода из 19 880 в моём проекте — ни одного комментария. Покрытие документацией — 39%.
Это не чужой легаси-код. Это мой собственный проект, который я пишу прямо сейчас. Я направил свой инструмент на самого себя и увидел то, от чего у любого техлида дёргается глаз: кодовая база растёт быстрее, чем документация. 1183 файла на Python. 480 коммитов за полгода. 21 аналитический сценарий, которые я наваял за это время. А документация покрывает меньше половины.
Новый разработчик приходит в проект, открывает src/workflow/scenarios/audit_composite.py — а там 6318 строк, 114 вызовов в другие модули, цикломатическая сложность 80. И задаёт первый вопрос: «Кто мне объяснит, как это работает?»
Раньше ответ был: «Спроси Мишу». Теперь — запрос к графу свойств кода. И я наконец-то могу заниматься своей работой, а не быть живой документацией.
Я думал, у меня всё чисто. 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; Разработка ПО в привычном нам виде, сложившаяся в течение десятков лет, уходит в прошлое. БЯМ-ассистенты для программирования фундаментальным образом изменили наше ремесло, и ещё не известно, к добру или к худу.
