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

Коллекция интересных кусочков кода и дурацких картинок вам в пятницу. Предыдущая серия здесь.

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

Привет! Меня зовут Артем Валевич, я тимлид в AGIMA. Одна из важнейших моих обязанностей — код-ревью, то есть проверка кода на качество, надежность и соответствие требованиям проекта. Этот процесс может ощутимо улучшить продукт, а может превратить жизнь всей команды в ад. Ключ к этому процессу — в умении не перегибать палку. Давайте посмотрим, как может выглядеть токсичный и нетоксичной фидбек, а заодно на то, как можно оптимизировать сам процесс ревью.

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

Поднимайте If вверх

Если внутри функции есть условие if, то подумайте, нельзя ли его переместить в вызывающую сторону:

// ХОРОШО

fn frobnicate(walrus: Walrus) {

... }

// ПЛОХО

fn frobnicate(walrus: Option<Walrus>) {

let walrus = match walrus {

Some(it) => it,

None => return,

};

...

}

В подобных примерах часто существуют предварительные условия: функция может проверять предусловие внутри и «ничего не делать», если оно не выполняется, или же может передать задачу проверки предварительного условия вызывающей её стороне, а при помощи типов (или assert) принудительно удовлетворить этому условию. Подъём проверок вверх, особенно в случае предварительных условий, может иметь лавинообразный эффект и привести к уменьшению общего количества проверок. Именно поэтому и возникло это правило.

Go-разработчики часто сталкиваются с парадоксом: изначально простой и понятный проект со временем превращается в сложный для поддержки монолит.

✔️ Бизнес-логика оказывается размазана между слоями?

✔️ Замена базы данных требует переписывания половины кода?

✔️ Новым разработчикам требуется недели, чтобы разобраться в проекте?

В этой статье мы разбираем практическое применение DDD и Clean Architecture в Go. Обсуждаем возможный стандарт структуры микросервиса. Оптимизируем существующие.

🔥 Для разработчиков, которые хотят создавать проекты, остающиеся поддерживаемыми даже через годы развития.

Недавно мне попался следующий твит от OneHappyFellow:

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

— One Happy Fellow (@onehappyfellow) 5 мая 2025

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

К написанию этой статьи меня подтолкнуло изучение архитектурных подходов для Vue.js-проектов, а вдохновила - детально описанная методология Feature-Sliced Design.

К сожалению, PHP-сообществу не хватает подобных развернутых рекомендаций, да и вообще, каких-то общепризнанных стандартных подходов в структуре проекта.

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

Предисловие

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

Я решил написать серию статей, посвящённых различным аспектам проектирования программных систем, но первоначальной идеей было показать архитектурное решение моего pet-проекта на FastAPI — пример реализации «чистой архитектуры» с использованием современного стека: Python3.13, FastAPI, Uvicorn, Nginx, PostgreSQL, Alembic, Celery, Redis, Pytest, Filebeat, Logstash, Elasticsearch, Kibana, Prometheus, Grafana, Docker и Docker Compose.

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

Business Intelligence (BI) находит применение в самых разных сферах, в том числе, например, при анализе результатов бенчмарков. Часто возникает задача сравнения производительности двух версий приложения на основе результатов бенчмарков (время выполнения тестов для нескольких прогонов и нескольких тестов), например, сравнение master ветки и feature ветки. Улучшение производительности в feature ветке (особенно, если она для улучшения производительности и создавалась) проверить можно условно и вручную, но также важно проверить, что нет деградации в других кейсах бенчмарков для feature ветки по сравнению с master веткой. Это можно решить статистическими методами, например, достаточно однофакторного дисперсионного анализа (ANOVA), здесь будет рассмотрен критерий Кохрена-Кокса, особенности его имплементации на PostgreSQL и возможные виды графиков для представления результатов. Интересующимся применением BI и ANOVA для сравнения производительности двух версий приложения на бенчмарках — добро пожаловать под кат :)

Меня зовут Андрей Никольский, я Head of Platform в Банки.ру. Сегодня хочу обсудить не самую приятную, но важную тему — технический долг и как с ним работать.

Любой разработчик или руководитель неизбежно сталкивается с техдолгом: либо устраняет его, либо создает. Чаще всего — и то, и другое одновременно. Год назад я решил глубже разобраться в этом вопросе и начал изучать, что происходит в индустрии: как компании работают с техдолгом в теории и на практике, какие подходы применяют и с какими проблемами сталкиваются.

Потом я структурировал, что есть по этой теме у нас в Банки.ру и решил написать статью. Будет много ссылок на англо- и русскоязычные статьи и доклады, рекомендую изучить каждую ссылку для полноты понимания.

Я: хочу автодополнение кода
Также я: у нас уже есть автодополнение кода дома
Автодополнение кода дома:

Привет, Хабр! Я Саша, разработчик из Cloud4Y. Хочу поделиться с вами своей идеей локального развёртывания нейросети для автодополнения кода. В этом примере мы будем использовать модель Qwen2.5-Coder на 14B параметров. Есть идеи, как можно сделать это ещё лучше? С радостью послушаю.

В статье обсудим антипаттерн Primitive obsession, разберём на примерах способы его устранения в разных языках программирования.

Python... язык программирования, не нуждающийся в особом представлении. За удобство в обработке "больших данных" заслуженно получил звание "лучшего Excel". За удобство интеграции в C и C++ код его любит геймдев. А также у него низкий порог вхождения!

«Тайный редактор» будет на регулярной основе коротко разжевывать суть научных публикаций по технологиям искусственного интеллекта, отвечать на неудобные вопросы по ИИ, объяснять события, развеивать мифы и разоблачать пустой хайп вокруг технологий.

Сегодня разбираем статью от исследователей MTS AI Iterative Self‑Training for Code Generation via Reinforced Re‑Ranking — о том, как можно обучить реранжирующую модель выбирать качественные варианты кода, сгенерированные другой моделью. Спойлер: с этим подходом удается сделать так, что модель на 13B параметров может обогнать по качеству 33B.

Привет, Хабр! Часто при тестировании идет сравнение производительности двух версий, например, master ветки и feature ветки. Допустим, идет сравнение по бенчмаркам, т.е. сравнивается время выполнения запросов для некоторого количества кейсов. Понятно, что если, например, в feature ветке есть улучшение производительности (и ветка создавалась как раз для улучшения производительности), это улучшение на целевых кейсах можно проверить даже вручную. Однако, осталось проверить, нет ли ухудшения производительности в остальных кейсах. Относительно точное вычисление производительности в смысле среднего времени выполнения запроса в конкретном кейсе требует нескольких прогонов кейса и может занять некоторое время, поэтому полная проверка всех кейсов (с десятками прогонов каждого кейса для получения более точного среднего результата) может занять, например, дни.

Однако, часто требуется лишь проверить лишь наличие деградации в feature ветке по сравнению с master, а не знать относительно точное время выполнения каждого запроса в feature ветке, это зачастую актуально для PR. Например, в feature ветке в одном кейсе два запроса выполняются за 300 и 300 секунд, а в master ветке для этого кейса за 12, 11, 10 секунд, нужно ли проводить несколько запусков кейса в feature ветке, или и так понятно, что есть деградация? Методы математической статистики позволяет формально ответить на этот вопрос с заданной вероятностью, например, 0.95, чтобы можно было принять решение формально, а не интуитивно. Интересующимся статистическими методами проверки отсутствия деградации — добро пожаловать под кат :)

Ещё год назад я смеялся над мемами про Copilot, который «пишет весь код за тебя». Теперь — я уже не смеюсь. Потому что вижу, как всё чаще код влетает в main почти без участия человека. Его не пишут — его принимают. Почти как оракульское послание.

Это не всегда плохо. Но иногда — страшно.

PowerShell — известный инструмент от Microsoft. Но какие секреты сможет найти статический анализатор в его исходном коде? Посмотрим в этой статье.

Проверяя код проекта TDengine с помощью PVS-Studio, можно встретить код с запахом, канонические ошибки и опечатки. Многое из этого можно избежать, если изначально аккуратно оформлять код, делать логику простой и избегать макросов. Давайте рассмотрим некоторые фрагменты кода и подумаем, как можно провести его рефакторинг так, чтобы багам просто не было там места.

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

Часто ли вы слышите о новом принципе проектирования IT-архитектуры? А об обновлении классических принципов? Попробую вас удивить и привнести что-то новое. 😎

У вас никогда не вызывало недоумения, что связанность и прочность (или связность) — это про примерно одно и то же (и то, и другое — это некая связь), но одно — хорошо, а другое — почему-то плохо? 🙂
Но давайте по порядку.

Привет, Хабр! Достаточно часто используются иерархические фильтры или отчеты с иерархией, и представление иерархии может быть актуально как для UI (например, иерархических фильтров), так и для отчетов или дашбордов. Если рассматривать только структуру запроса с иерархией, без расчета промежуточных итогов и т.д., то сохранение структуры иерархического UI элемента при большом уровне вложенности, а также передача этой иерархии с UI на бэкенд и дальше, например, в виде SQL запроса в СУБД может быть относительно нетривиальной задачей. При относительно большом уровне вложенности (например, иерархия в 10 уровней), при решении «в лоб» и сохранении всех 10 выбранных значений на последнем уровне иерархии, станет неудобно хранить и передавать в качестве параметров с UI на бэкенд (для 1000 строк и 10 уровней вложенности может быть уже условно 10000 параметров), также растет и количество параметров в SQL, и проблемы усугубляются в случае микросервисной архитектуры, когда запрос SQL не сразу отправляется, например, в ClickHouse, а ещё эти 10000 параметров «путешествуют» из UI в один или несколько микросервисов, пока не попадут в ClickHouse. В связи с этим хочу рассмотреть одно из возможных решений проблемы с помощью хеширования на примере C# и ClickHouse, но это «не идеи, проверенные на продакшене», больше тема к обсуждению. Тем, кому интересно решение проблем иерархических запросов на примере C# и ClickHouse — добро пожаловать под кат :)