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

В статье обсудим антипаттерн 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 — добро пожаловать под кат :)

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

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

Сергей Каличев, старший разработчик, Angie Software

Однажды, давным-давно, я наткнулся на одну хорошую статью по разработке переносимого кода и решил её перевести. Когда же это было... ё-моё, в 2008 году, 17 лет назад! Обалдеть, как время летит. Статья называлась "Fighting the Lemmings", автор Martin Husemann. Выложил перевод на LOR. С тех пор много воды утекло и, когда я попытался поискать статью в Интернете, то обнаружил, что ни оригинальной статьи, ни перевода, найти практически невозможно. Перевод ещё сохранился в глубоких закромах OpenNet, а оригинал только в архиве Интернета. Ссылки на PDF-ки тоже протухли и больше не работают. Обидно, это ведь такая нетленка для системщиков. Понятно, что переносимость уже сто раз пережёвана в других статьях и книгах, но тут всё было сконцентрировано и написано доходчиво. При этом актуальность до сих пор не потеряна. Ну а что, собственно, кардинально поменялось в разработке переносимого кода на C с тех пор? Если не обращать внимание на упоминания некоторых архитектур и ОС, которые сейчас, да и во времена перевода, звучат, как придания старины глубокой, то в остальном, обо всех особенностях разработки переносимого кода, описанных в статье, надо помнить и сегодня. Выкладываю текст, как он есть, без каких-либо современных правок.

Для тех, кому удобнее читать в PDF, вот ссылки:

PDF оригинальной статьи

PDF перевода

А теперь сама статья.

Разработчики любят чистый код, а "Правило бойскаута", по слухам, делает его еще чище. На первый взгляд, подход кажется разумным: исправляешь мелкие недочёты, переименовываешь переменные, удаляешь лишние комментарии — удобно, быстро, безопасно. А главное, можно сказать, что внёс вклад!

Однако если такие правки не решают реальных проблем, это превращается в поверхностный рефакторинг, создающий лишь иллюзию прогресса. Это можно описать метафорой low-hanging fruit — когда разработчики выбирают самые лёгкие и очевидные задачи, избегая более сложных и значимых изменений.

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

Привет, Хабр!

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

Я честно, не знаю как в других профессиях, но в программировании, как мне кажется, собеседования — это чистая лотерея. Мое видение этого возможно подтверждает рынок труда — накрути себе опыта побольше, примени нейросеть, расскажи красиво о себе и вот работа (зарплата) мечты уже твоя. Следствием этого — по 300 отзывов на вакансию. Но, к слову, вакансии эти висят месяцами. Ты просто попадаешь в огромную кучу кандидатов, которых работодатель хочет отсеять и выбрать лучшего из вас. По каким критериям (по всем кроме трудовой книжки) вас будут сортировать одному Нео известно. Так‑же имел личный опыт, когда я отвечал полностью на все вопросы в течение часа. Получив оценку своим знаниям на 5+, заветную работу (зарплату) мечты я так и не получил.

Привет, на связи Лука.

Мне всегда было интересно узнать больше о чистой архитектуре и о том, как построить систему, которая будет простой, но при этом выполнять всё, что от неё требуется. Естественно, без ухода в крайности, результат — наше всё, в булочную на такси не поедем.

Со временем вырисовываются какие-то паттерны и принципы, к которым лежит душа. У каждого свои: кто-то горит TDD, кто-то ATDD, FDD, BDD и прочими DD. Я же больше всего прикипел к DDD, причём первая D тут варьируется: угораю как по Domain, так и по Data.

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

Сейчас среди Java/Kotlin команд распространено применение Чистой (ака Гексагональной, ака Луковой — Clean, Hexagonal, Onion) архитектуры для разработки бакэндов прикладных приложений (да и Android‑приложений тоже). Однако это семейство архитектур в контексте прикладной разработки зачастую не даёт никаких преимуществ, а только привносит лишние церемонии и тем самым замедляет её.

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

Но перед тем как перейти к Чистой архитектуре, сначала надо разобрать принцип инверсии зависимостей (Dependency Inversion Principle, DIP).

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