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

В 1988 году бортовой компьютер с памятью 128 КБ посадил космический корабль в шторм. Сегодня ваш смартфон с многоядерным процессором заикается при скролле списка контактов. Мы привыкли думать, что данные невесомы, а JSON – это «просто текст». В этой статье мы препарируем один обычный fetch-запрос и посчитаем его реальную цену: в байтах, миллисекундах и скрытых архитектурных издержках. Разберемся, почему мы стали «поколением JSON» и как вернуть себе инженерную осознанность в эпоху избыточности.

Разговор будет серьёзный. С 1 марта 2026 вся публичная информация для потребителя должна быть на русском — N 168-ФЗ. Пока что разработку это не касается, но стоит быть готовыми. Предлагаю договориться о словаре разработчиков Российской Федерации.

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

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

Я купил все самые дорогие подписки на AI-инструменты для разработки на 500 долларов. Вот лохи те, кто до сих пор этого не сделал. Я-то подписан на всех владельцев AI-инструментов и читаю их посты. Если кто-то пишет, что их инструмент заменяет мидла, я вижу это первым. Нужно мыслить на шаг впереди рынка.

У нас в компании был один проект, с которым я не справился.

Дело было так: мне сообщили, что знакомый плюсовик написал какой-то скелет проекта на питоне, а теперь мне надо его допилить, подставив в нужные места реализации. Почему тогда делал он, а не я, а сейчас должен делать я, а не он? Да чёрт его знает. Но я подумал, что смогу — унаследуюсь и переопределю методы где нужно, подставлю зависимости во всякие DI, ну что там может быть плохого?

Оказалось, что плохо вообще всё.

Проект был раздут и переусложнён настолько, что буквально не умещался у меня в голове. Я уже начинаю подозревать, что, похоже, я LLM, и у меня контекст в районе 4096 токенов, потому что чем дольше я читаю код, тем меньше помню, что там было в начале. Изучая проект, я прыгал по стеку вызовов, пытаясь понять, что откуда вызывается и в какой последовательности, и просто в какой-то момент терялся. Проект меня победил, и его передали кому-то другому.

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

Короче, вот она — анти-статья, собранная из того проекта. А где мне не хватало примеров, я брал код из Django, потому что он вообще полностью собран на антипаттернах.

Хороший ли я программист? Если коротко — я не знаю, что это значит.

Вот я программирую уже 52 года, с 1973 года, спасибо урокам в государственной средней школе — тогда это было редкостью и не все школы давали подобную возможность. Я работал в 15 разных компаниях в самых разных отраслях. Болше скажу, я основал две небольшие софтверные компании — одну в 1985 году и вторую в 1987-м, и руководил ими до 1994 года. А потом я вышел на пенсию в 2021-м году.

Так что же, я хороший программист потому, что я в целом 52 года в отрасли и всё это время программирую?

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

Долговечность — это преимущество лишь в том смысле, что ты всё это время сумел оставаться ценным и востребованным, но это не обязательно значит, что ты хорош.

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

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

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

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

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

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

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

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

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

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

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

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

Поведаю историю, неизвестную почти никому, но от того не менее занимательную.

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

Когда я в прошлом году услышал, что дядя Боб планирует выпустить вторую редакцию «Чистого кода», то был восхищён, а это для меня редкость. Я считал, что и первый выпуск был хорош, хотя сам читаю редко.

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

Или же меня обнадёжило данное Мартином обещание доработать руководства из предыдущей книги. Знаете, то удовольствие, когда читаешь заметки к долгожданным патчам для рабочего ПО.

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

Несмотря на весь свой цинизм и любовь постебаться, я искренне уважаю тех, кто может признать свои ошибки и взглянуть на вещи по-новому. Я испытываю глубокую радость, когда мой посыл доходит до умов людей и меняет их взгляд на вопросы, в которых они грубо заблуждаются (хотя порой мне кажется, что мой напористый подход может, наоборот, этому мешать).

Так что представьте, каково было моё разочарование, когда я потратил $60 на электронную версию этой книги, в которой Боб не просто не изменил своей позиции по большинству спорных практик, но и продолжил топить за них ещё круче!

Невероятно!

Но я забегаю вперёд…

Несмотря на то, что книга «Чистый код» привнесла в наш лексикон прекрасный термин, она также снискала и дурную славу. Это руководство от 2008 года представляет собой сборник принципов и исследований, которые «дядя Боб» (Uncle Bob, то есть Роберт Мартин) выработал за годы программирования.

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

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

Можно подумать...

Откройте любой пулл‑реквест в проекте с любой «чистой архитектурой» и вы скорее всего увидите не обсуждение бизнес‑логики, а срач. «Это нельзя класть в UseCase, это логика домена!», «Зачем тут еще один DTO, мы же просто поле прокидываем!», «Этот интерфейс не нужен, у нас никогда не будет другой реализации!». Полагаю, очень много людей с таким сталкиваются.

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

Индустрия разработки программного обеспечения переживает фундаментальную трансформацию. Еще два года назад идея доверить AI написание производственного кода казалась фантастикой. Сегодня это реальность для сотен тысяч разработчиков по всему миру.

Согласно данным Anthropic, Claude Code используют более 115 тыс. разработчиков, которые обрабатывают 195 млн строк кода еженедельно. Уровень внедрения среди разработчиков составляет 53% — это лидирующий показатель на рынке. База активных пользователей выросла на 300%, а доход увеличился в 5,5 раза за последние месяцы.

Но что действительно важно, это не статистика внедрения, а фундаментальный сдвиг в подходе к разработке. AI-инструменты больше не просто ускоряют написание кода. Они меняют саму парадигму: от «Как это закодить?» к «Что именно нужно построить?».

В этой статье мы рассмотрим практические паттерны и подходы к R&D и проверке гипотез с использованием современных AI-инструментов, в частности Claude Code — терминального агентного инструмента.

Ночь. Курсор мигает, как маяк в тумане. Логи шепчут о том, что в коде — своя улица, свои правила и кодекс общения. Объекты — не безмолвные элементы системы. У каждого свой характер, привычки и слабости. Один щёлчок и поведение меняется: кто-то отдаёт приказы, кто-то внимательно прислушивается, а кто-то терпеливо ждёт сигнала. Эта статья — карта такого города.

Всем привет! Меня зовут Бромбин Андрей и сегодня разберёмся в поведенческих паттернах ООП. Короткие определения, идеи через ясные метафоры и рабочие примеры на Java. Всё это для того, чтобы система не трещала по швам, а решения были ясными, предсказуемыми и поддерживаемыми.

Мы переживаем величайший кризис качества программного обеспечения в истории вычислительной техники. Калькулятор теряет 32 ГБ оперативной памяти. ИИ-помощники удаляют рабочие базы данных. Компании тратят 364 миллиарда долларов, чтобы избежать решения фундаментальных проблем.

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

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

Всем привет. Меня зовут Аня (SavAnna) я работаю AppSec и как хобби занимаюсь багбаунти. Багбаунти - отличный способ отдохнуть от своих сервисов и сменить фокус с "защиты" на "нападение". Не всегда баги ищутся целенаправленно - иногда это происходит случайно. Хочу показать, что много странных и простых багов может найти каждый.

Хватит спорить — пора запускать и сравнивать.

Тестируем реальные сценарии, измеряем RPS, смотрим на потребление памяти и разбираемся, когда самая разумная стратегия — это просто подождать и обновить Python на free-threading версию. 

Привет, Хабр! Меня зовут Игорь Анохин, я — руководитель платформенной разработки в K2 Cloud и более 8 лет программирую на Python. 

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