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

Оптимизация кода. Что быстрее: циклы vs стрелочные функции. Простая задача с собеседования. Разбор простых итераций с примерами кода

Когда я был разработчиком я задавался вопросами: как разделить код на классы? какие модули выделить?

Когда я стал архитектором я задавался вопросами: зачем же мы наплодили 200 микросервисов? стоит ли выделять новый или пора объединять?

Когда я стал руководителем я задавался вопросами: как разделить людей на команды разработки? стоит ли создавать новый отдел или расширить ответственность старого?

И всё это хотелось сделать оптимальным эффективным образом.

И я понял, что все эти вопросы сводятся к ряду единых принципов о том как делить, которые можно применять на любом уровне. И этим важным для себя осознанием, после 20 лет в разработке, я хочу поделиться.

Пятничное, навеяно статьёй «Почему 2026-й станет годом десктопного Linux + интересные дистрибутивы внутри»

Вы знаете, мне некоторые программы изначально написанные для  Linux иногда напоминают... Как бы это объяснить? Попробую на примере. И попробую с юмором.

В статье рассмотрим SDD фреймворки (Spek-Kit, OpenSpec, Kiro, BMAD) и решения не являющиеся полностью SDD, но решающие вопросы упорядочивания разработки с ИИ (Cursor Memory Bank, TaskMaster, Tessl, Supercode, Claude-flow).

Слово "вайбкодинг" в современном мире прижилось плотно, но у большинства разработчиков с опытом вызывает безусловный рвотный рефлекс. С одной стороны ИИ пишет код очень хорошо. Современные модели в алгоритмике уже почти всегда лучше разработчиков.

Но если дело касается большого проекта и Production, всплывают многочисленные проблемы:

В Google я устроился где-то 14 лет назад и тогда думал, что моей работой будет написание хорошего кода. Отчасти так и оказалось. Но чем дольше я там трудился, тем больше понимал, что преуспевающие разработчики — это не обязательно лучшие программисты. Обычно это те люди, которые научились лавировать среди всего, что окружает код — среди людей, внутренней политики и условий неопределённости.

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

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

Крылатый гений сидит среди инструментов. Циркуль, весы, молоток, рубанок. Всё под рукой. Но он бездействует, подперев голову. Не от лени. Он видит проблему и понимает: имеющиеся инструменты не дают ответа.

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

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

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

Привет! Меня зовут Алексей Сидоров, я Python-разработчик в команде краткосрочной аренды в Домклик. В этой статье разберём, как и зачем проверять код миграций схемы БД и как написать свой линтер.

Мы, кажется, пробили новое дно.
И что особенно удивительно, Карл! — аккуратно, без паники, с хорошей формулировкой и абзацами.

Я сначала не понял, что стало происходить. Было ощущение странного дежавю: читаю change request или баг‑репорт, киваю, вроде всё логично... но что‑то не так, как будто где это уже читал. Слова правильные. Причинно‑следственные связи на месте. Термины употреблены верно. Пытаюсь понять в чём проблема — ноль. Как будто читаешь инструкцию к микроволновке, а не описание реальной проблемы. Пытаюсь прочитать ещё раз и ещё раз — с трудом продираюсь через текст с каким‑то смутным понимаем того, что написано.

И тут до меня доходит - как обухом по голове.
Мои дорогие гении из техподдержки и продакт менеджер нашли «идеальный» способ сэкономить на обсуждении технической стороны проблемы со мной. И действительно, зачем? Клиент что‑то спросил. Они прогнали это через ИИ. И ИИ вник. Глубоко. Старательно. Затем сгенерировал текст, старательно объясняя мне что нужно добавить, починить и даже каким образом это сделать (не имея даже понятия о нашей кодовой базе).

И вот тут я реально взбесился. И не тихо так, а очень даже громко.

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

Всем привет! Меня зовут Артём Вичужанин. В разработке я больше пяти лет: начинал с десктопных приложений на Delphi и микропрограмм для контроллеров на C++, позже ушел в мобильную разработку. Сейчас в Naumen я отвечаю за разработку мобильных продуктов, и в рамках проектов регулярно сталкиваюсь с вопросами качества кода и автоматизации.

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

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

Началось с простого: сделать универсальное ядро для Telegram-ботов на Python и YAML-конфигах. Сейчас Coreness — это мультитенантная платформа, где боты и AI-агенты создаются декларативно, работают с RAG, а весь код написан через вайб-кодинг с помощью LLM.

Это рассказ о том, как в одиночку за пару месяцев удалось пройти путь от Clean Architecture (которая не зашла) до гибридного микса архитектур, от SQLite до production-инфраструктуры с PostgreSQL и десятками ботов в бою, и почему AI-ассистенты — это не магия, а инструмент, требующий совершенно новых навыков.

Представьте: вы строите сервис выдачи дипломов на Solana. Всё отлично, пока дело не доходит до тестов.

Внезапно оказывается, что для проверки бизнес-логики нужно поднимать валидатор, искать тестовые токены и молиться на стабильность сети. Знакомая боль?

В этой статье я покажу, как мы решили проблему, используя async-trait и dyn Trait. Мы превратили интеграционные тесты длиной в минуты в юнит-тесты, которые проходят за миллисекунды.

Дисклеймер. Хотя в статье представлены некоторые наработки, она не претендует на готовое решение. Её цель — описать идею и подход к созданию открытой библиотеки, а также привлечь внимание к проблемам, с которыми сталкиваются разработчики игр. Автор является профессиональным программистом, однако разработка игр остаётся для него областью хобби.

Продумывая программную архитектуру различных прототипов игр на Unity 3D, решил поделится рядом соображений и заодно структурировать, и описать свой подход к реализации архитектуры. Конечно, очень редко можно договорится о соблюдении некоторой архитектуры при разработке. Тут как правило две проблемы в описании архитектуры как законченной сущности, и её понимании другими.

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

Я как-то писала про Claude Code. По ощущениям, многие вайбкодеры сейчас выбирают его как основную CLI-среду для агентского кодинга. Между Codex, Gemini и Claude Code часто выбирают последний- за быстрые итерации и удобство. Собрала в одном месте полезные ресурсы про Claude Code. 

Универсальный автогенератор тестов API на базе Schemathesis

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

Есть числа, которые полезно знать программистам на Python. Насколько быстро добавляется элемент в список? Как насчет открытия файла? Это занимает меньше миллисекунды? Если ваш алгоритм зависит от производительности, какую структуру данных вы должны использовать? Сколько памяти занимает число с плавающей запятой, один символ или пустая строка? Насколько быстр FastAPI по сравнению с Django?

Это перевод недавней работы Michael Kennedy с подробными пояснениями для начинающих питонистов, которых нет у автора.

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

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

Группа авторов (к которым я не отношусь) провела опрос постоянных пользователей ии-инструментов с акцентом на практические вопросы. Что получается и что - нет, как получается и как - нет, для чего, для кого и т.п. На момент обзора ответы дали 139 опрошенных, среди которых самые разные специальности и опыт в профессии ойти.

Формат показался актуальным и информативным, но трудновоспринимаемым, поскольку ответы собраны в экселе (который прилагается). Поэтому сделано текстовое обобщение в notebookLM, которое под катом. Бонусом - майнд мэп по опросу.

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

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

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

Реальность, как это часто бывает, оказалась куда более прозаичной и, что греха таить, гротескной. Вместо киберпанка мы получили "кибер-сюр". Вместо торжества разума — торжество бюрократии, помноженное на галлюцинации нейросетей. Рынок IT к 2025 году превратился в странный гибрид восточного базара, где каждый пытается продать воздух, и неприступной бюрократической крепости, где вход и выход охраняются стражами, задающими вопросы о цвете вашей ауры.

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

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