feelin

«Clean Claude»

Недавно наткнулся на Хабре на одну интересную штуку - пересказ серии твитов Роберта Мартина. В них он рассказывает о своём первом опыте от AI кодинга.

За несколько месяцев дядя Боб рассказал много всякого интересного. Например, что бесплатный Grok сильно тупил и не очень ему понравился, а вот платный Claude уже создаёт серьёзное ускорение для профессионала.

Самое примечательное — как Мартин встраивает ИИ в свою идеологию «чистого кода». Он утверждает: если вы владеете TDD и принципами SOLID, ИИ действительно ускорит вас и избавит от рутинных задач. При этом, по его мнению, принципы чистого кода не устарели — напротив, стали ещё актуальнее.

Главным выводом остаётся то, что нельзя отдавать процесс мышления на аутсорс ИИ. Человек всё ещё решает, что именно агенту нужно делать.

Для усиления контроля над ИИ можно использовать всё те же традиционные инструменты, хорошо подсвечивающие регресс или другие проблемы. Например, тесты или статические анализаторы. О том, как контролировать агентов, кстати, мы говорили с S0ER'ом в выпуске "Разбаговки" про ИИ. Вот ссылка, если не видели.

А сам перевод твитов дяди Боба можно найти здесь. Определённо рекомендасьон!

🎤 feelin #ai #cleanCode

🎧 Разбаговка #7

В новом выпуске общаемся с Vudi Kingyru, блогером и криптоинфлюенсером, про блокчейны и Web3. Интересно взглянуть на индустрию спустя время после хайпа и понять судьбу лопнувших пузырей. Особенно актуально сейчас, в эпоху ИИ-бума.

🎧 Яндекс Музыка
🎬 YouTube

🎤 feelin #podcast

Не делай так: гигантский тернарный оператор

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

Представьте, что вы встретили в коде вот такой фрагмент:

const renderButtonLabel = (
  user: User | null,
  cart: Cart,
  isMobile: boolean,
  hasUnreadNotifications: boolean,
  currentRoute: string
): string =>
  (user != null && cart.items.length > 0 && !cart.hasBackorderedItems && user.balance >= cart.total && !isMobile && !hasUnreadNotifications && currentRoute !== '/checkout')
    ? 'Перейти к оплате'
    : (user != null && cart.items.length > 0 && cart.hasBackorderedItems)
      ? 'Часть товаров временно недоступна'
      : (user != null && cart.items.length === 0)
        ? 'Корзина пуста'
        : (user == null)
          ? 'Войдите, чтобы оформить заказ'
          : (isMobile || hasUnreadNotifications || currentRoute === '/checkout')
            ? 'Продолжить'
            : 'Готово';

Чтобы понять его, приходится мысленно строить дерево как компилятор. А зачем? Ради экономии строк? Так теперь код выглядит ещё страшнее.

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

А вот как тот же функционал может выглядеть с if:

const renderButtonLabel = (
  user: User | null,
  cart: Cart,
  isMobile: boolean,
  hasUnreadNotifications: boolean,
  currentRoute: string
): string => {
  if (user == null) {
    return 'Войдите, чтобы оформить заказ';
  }

  if (cart.items.length === 0) {
    return 'Корзина пуста';
  }

  if (cart.hasBackorderedItems) {
    return 'Часть товаров временно недоступна';
  }

  if (
    cart.items.length > 0 &&
    user.balance >= cart.total &&
    !isMobile &&
    !hasUnreadNotifications &&
    currentRoute !== '/checkout'
  ) {
    return 'Перейти к оплате';
  }

  return 'Продолжить';
};

Здесь всё последовательно и без раздувания когнитивной сложности. Да и ещё для расширения списка условий не придётся ломать голову.

#неДелайТак - не усложняй.

🎤 feelin #cleanCode

Помогите DevOps'ам найти релиз!

Сегодня на вебинаре упомянули DORA-метрики. Решил кратко рассказать о них здесь.

Эти метрики появились в результате исследований группы DevOps Research and Assessment (DORA) в Google и нужны они для оценки зрелости DevOps процессов в компаниях. Так что Башмачок тут ни при чём :)

1. Deployment Frequency - чем чаще релизы, тем лучше.
Как обеспечить частоту деплоев? Обеспечить код таким количеством автоматических тестов, чтобы мы были уверены в его работоспособности. То есть, мы готовы выпустить релиз каждый раз, когда тесты проходят успешно.

2. Lead Time for Changes - чем меньше путь от коммита в origin до прода, тем лучше.
Разработчики в поте лица пилят новые фичи на протяжение примерно бесконечного времени. Но насколько быстро то, что сделал разработчик, попадёт в продакшен?

3. Change Failure Rate - чем меньше проблемных деплоев, тем лучше.
Ошибки случаются у всех. Эта метрика и учитывает эти ошибки. Если мы ломаем прод своим деплоем, необходимо сделать выводы, чтобы в будущем подобное не повторялось.

4. Time to Restore Service - чем быстрее встали, тем лучше.
Раз уж есть ошибки, то могут быть и падения. Без них никуда. Собственно, наши процессы должны быть выстроены настолько хорошо, чтобы мы могли поднять прод максимально быстро. Туда же относятся и различные ЧП, например, физическая поломка сервера.

Статический анализ, внедрённый в DevOps, кстати, помогает как раз в первой метрике. Анализатор - один из инструментов, который поможет нам быть уверенными в каждой сборке, а следовательно и в каждом релизе.

🎤 feelin

Смерть автора

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

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

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

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

Можно провести простой эксперимент: пролистайте первые 10–15 публикаций в своей ленте. С высокой вероятностью больше половины окажутся нейросетевым слопом.

На обе проблемы Хабр пока реагирует слабо. Борьба с низкокачественным AI-контентом не объявлена официально, а изменения в метриках выглядят скорее как пыль в глаза.

Хочется верить, что это не конец некогда легендарной площадки для инженеров. Но пока эта надежда остаётся без подтверждений.

🎤 feelin

📕 Крис Андерсон — «TED Talks. Слова меняют мир»

Сегодня расскажу про книгу, которая влияет на то, как я строю публичные выступления. Она стоит внимания даже если вы «и так всё знаете».

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

Формат TED-выступлений, конечно, отличается от технических докладов: там меньше кода, больше историй. Но большинство принципов универсальны — особенно если вы хотите не просто что-то рассказать, а донести свою идею слушателям.

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

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

🎤 feelin

Долина звёздной росы

В последнем выпуске подкаста я вскользь упомянул историю создания игры Stardew Valley — и она заслуживает отдельного рассказа.

Игру разработал один человек — Эрик Барон. Он был большим фанатом японской серии Harvest Moon, где игрок управляет фермой, и однажды решил создать что-то похожее.

Разработка шла параллельно с поиском постоянной работы: Эрик планировал завершить проект до того, как получит оффер. Но со временем игра настолько его увлекла, что он полностью посвятил ей себя — и от поиска работы отказался.

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

Спустя четыре года и десятки тысяч часов работы Stardew Valley вышла в Steam. На сегодняшний день она принесла своему создателю более 21 миллиона долларов.

Эта история — яркое подтверждение тому, о чём мы говорили в подкасте: усердие и искренний интерес способны преодолеть любые трудности.

Полную версию истории можно найти в книге Джейсона Шрайера «Кровь, пот и пиксели. Обратная сторона индустрии видеоигр», а свежий выпуск подкаста «Разбаговка» — здесь.

🎤 feelin

🎧 Разбаговка #6

Новый выпуск подкаста! В этот раз говорим со Славой Грисом, инди-разработчиком и ютубером, про игры и их разработку, а именно:

- Что движет автором андерграундных игр и как рождаются проекты вроде игр Славы?
- Реально ли начать делать игры без опыта? И как вообще начать?
- Как выжить как инди-разработчику в мире, где ежедневно появляются тысячи новых игр?
- Почему свобода вне мейнстрима — не недостаток, а преимущество, и зачем делать игры, которые могут увидеть лишь немногие?

🎧 Яндекс Музыка
🎬 YouTube

🎤 feelin #podcast

Не забудь!

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

Чтобы решить эту проблему, я начал вести ежедневные заметки, в которых записываю все появляющиеся планы. Иногда я даже оставляю себе «капсулу времени», создавая заметку на будущую дату. А ещё такие заметки помогают агрегировать информацию из разных сервисов — потому что рабочих инструментов иногда слишком много.

Это простой способ снизить когнитивную нагрузку, когда задачи перестают помещаться в оперативную память.

Я пользуюсь Obsidian и его Daily Notes. Он немного автоматизирует всё это дело. Но на самом деле инструмент не важен — можно делать подобное хоть в блокноте.

🎤 feelin #lifehacks

Топ 10 уязвимостей

Вышел новый OWASP Top 10 2025 — обновлённый список самых критичных уязвимостей в веб-приложениях.

За годы своего существования Top 10 стал не просто каталогом рисков, а зеркалом эволюции всей индустрии, отражая изменения в угрозах. Примеры из изменений этого года:

A03:2025 — Software Supply Chain Failures
Уязвимости теперь возникают задолго до первой строчки кода: зависимости, CI/CD-пайплайны, сторонние библиотеки. Сегодня нужно уделять ещё большее внимание тому, что попадает в сборку.

A10:2025 — Mishandling of Exceptional Conditions
Впервые в истории OWASP отдельная категория посвящена игнорированию ошибок. Подобные темы, кстати, появлялись и в недавних отечественных документах.

Полный разбор нового перечня с примерами кода в моей новой статье: OWASP Top 10 2025 — от кода к цепочке поставок: расширение границ безопасности.

Если вы пишете или проектируете API или принимаете решения о безопасности — этой теме точно стоит уделить внимание.

🎤 feelin #security

Не делай так: and в названии метода.

Если в названии метода есть and между глаголами - это признак того, что метод берёт на себя слишком много.

Простейший пример:

def validate_and_save_user(user: User):
  ...

На самом деле это два метода, которые, как гномы из "Гравити Фолз", притворяются одним. Здесь нужна декомпозиция:

def validate_user(user: User):
  ...
  
def save_user(user: User):
  ...

Помимо длинного названия подобные методы создадут много проблем:

- их сложно тестировать. Нужно покрывать все действия, происходящие внутри, поэтому тесты становятся огромными, а процесс их написания превращается в практику по комбинаторике;

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

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

Казалось бы - мелочь. Но я собственными руками рефакторил такой код. А как-то даже писал на него тесты, потому что зарефакторить спустя годы его существования уже являлось трудной задачей.

#неДелайТак - декомпозируй!

🎤 feelin #cleanCode

🔥 Реактивный компилятор

Фронтенд часто является предметом шуток на тему инструментов, которые появляются чаще, чем используются. Но несмотря на то, сколько инструментов существует, серьёзная разработка всё ещё отдаёт предпочтение большим игрокам.

Одним из самых популярных фронтенд фреймворков является React. Что же поддерживает его статус "царя горы"? Как минимум, крутые возможности, упрощающие разработку. Одно из таких - React Compiler.

Это новый инструмент сборки, который оптимизирует ваше React-приложение с помощью автоматической мемоизации. Что же здесь революционного?

Посмотрим на вот такой фрагмент кода:

import { useMemo, useCallback, memo } from 'react';  

const ExpensiveComponent = memo(
  function ExpensiveComponent({ data, onClick }) {  
    const processedData = useMemo(() => {  
      return expensiveProcessing(data);  
    }, [data]);  

    const handleClick = useCallback((item) => {  
      onClick(item.id);  
    }, [onClick]);  

    return (  
      <div>  
        {processedData.map(item => (  
              <Item 
                  key={item.id} 
                  onClick={() => handleClick(item)} 
              />  
            )
        )}  
        </div>  
    );  
  }
);

Этот React-компонент использует:
- useMemo - хук, позволяющий мемоизировать вычисления в компонентах. Если входные зависимости не менялись, то ранее сохранённое значение вернётся без вычислений;
- useCallback - хук, позволяющий мемоизировать функцию между вызовами компонента. Если зависимости не менялись, то между рендерами возвращаемая функция не поменяется;
- memo - функция, позволяющая избежать повторного рендеринга компонента, если его зависимости не поменялись.

Все эти возможности оптимизации при использовании React Compiler просто не нужны! Тот же фрагмент кода при использовании React Compiler выглядит так:

function ExpensiveComponent({ data, onClick }) {  
  const processedData = expensiveProcessing(data);  
  const handleClick = (item) => {  
    onClick(item.id);  
  };  
  
  return (  
    <div>  
      {processedData.map(item => (  
        <Item 
            key={item.id} 
            onClick={() => handleClick(item)} 
        />  
    ))}
    </div>  
  );  
}

React Compiler автоматически оптимизирует всё для избежания лишних перерендеров. useCallback, useMemo или memo всё ещё можно использовать, но уже в тех случаях, где необходима ручная мемоизация.

С октября 2025 года React Compiler является стабильным и его уже можно использовать в реальных проектах.

В теории всё звучит круто, но лично мне только предстоит React Compiler попробовать. С момента релиза так и не добрался до того, чтобы попытаться перенести какой-нибудь пет-проект на новомодный инструмент.

🎤 feelin

🤪 Слоп не пройдёт

29 января The Verge опубликовал новость: YouTube удалил несколько каналов, занимавшихся публикацией низкокачественного AI-контента. Изменения коснулись 18 каналов, самые большие — CuentosFacianantes и Imperio de Jesus.

Интересно, что за неделю до этого Нил Мохан, CEO YouTube, опубликовал письмо с планами платформы на 2026 год. Cреди них содержался пункт Managing AI Slop о скором начале удаления низкокачественного AI-контента. Также YouTube теперь требует от авторов маркировать сгенерированный контент, который можно принять за реальность.

Новость снова напоминает нам о времени, в котором мы живём. AI меняет многие сферы, в том числе производство и потребление контента. Помните ли вы ещё случаи, когда YouTube вводил специальную модерацию для вполне легальных материалов, не касающихся политики?

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

Ради интереса сверните Telegram и посмотрите, сколько времени работы аккумулятора вашего смартфона уходит на подобное? Я думаю — немало.

🎤 feelin

🫡 Компилятор говорит, анализатор слушает

Если обратить внимание на количество постов в уже наступившем 2026 году, можно понять, что трудовой год начался достаточно интересно :). Сегодня закрою свой долг с прошлого года и расскажу про одну интересность, которая вышла в конце 2025-го.

C++ - довольно интересный язык. И интересность его заключается не только непосредственно в языковых возможностях, а ещё и в инфраструктуре вокруг кода, на нём написанного.

Если попросить C++ разработчика назвать известные ему компиляторы, то в принципе, можно уже заваривать чай, это, скорее всего, надолго. И вполне себе частая история, когда в том или ином проекте на C++ появляется целый "зоопарк" из различных инструментов, используемых для сборки программного обеспечения.

Собственно, такая ситуация создаёт проблемы, как минимум, для "свежих" разработчиков, которые не погружены во все подробности сборочной инфраструктуры - скорее всего случится так, что придётся погружаться во всё это многообразие скриптов сборки. А ещё часто бывает, что человек, затянувший в продакшн какой-то инструмент, уже "давно тут не работает" или что-то подобное, из-за чего разобраться будет ещё сложнее.

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

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

Собственно, о том, как этот самый мониторинг компиляции в PVS-Studio работает я и написал в своей статье. Там же есть, кстати, и описание новой фичи - использования мониторинга компиляции на Windows из плагина для IDE Visual Studio Code.

🎤 feelin

Вчера записали кое-что интересное 🙃

🎤 feelin

С новым оборотом, земляне! 🎉

🤓 Типа важный

Ребята из OpenIDE тут взяли у меня интервью обо всяком разном. Немного поспрашивали про меня, а больше про наш плагин для их среды разработки. Всякого разного там наговорил, можно почитать вот тут :)

🎤 feelin

🎧 Разбаговка #4

Перед новым годом припасли для вас новый выпуск подкаста. В этот раз говорим про AI в разработке с Евгением Сергеевым (a.k.a. S0ER):

- как LLM справляются с реальным кодом проектов?
- в чём разница между агентами и ассистентами?
- насколько дорого использовать AI для написания кода?
- как бороться с иллюзией компетентности ИИ?
- действительно ли вайбкодинг станет будущим разработки?
- изменит ли ИИ саму культуру программирования?
- заменит ли искусственный интеллект обычных разработчиков?

🎧 Яндекс.Музыка
🎬 YouTube

🎤 feelin #podcast

🤩 Statische Analyse in allen Sprachen der Welt

Новая статейка от меня! В этот раз посмотрели проект Language Tool с помощью статического анализатора и снова нашли в коде много всякого интересного :)

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

Кстати, за кулисами производства каждого такого материала мы находим и возможности для улучшения нашего инструмента. В этот раз такое улучшение даже попало в текст. Оказалось, что Java анализатор неправильно обрабатывает строки на арабском (напоминаю, что в этом языке читают справа налево).

В общем, снова рекомендую свою статью к прочтению :)

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

Читать:
- на русском
- на английском

🎤 feelin

🥰 20 лет Django

16 ноября одному из самых популярных веб-фреймворков для Python исполнилось 20 лет. Версия Django 0.90 вышла в 2005 году.

Интересно, что другие фреймворки, которые были в топе, успели множество раз смениться. Например, для легковесных приложений раньше часто использовался Flask, а сегодня его место занял FastAPI. Во времена, когда в Python не было асинхронности как таковой, популярен был фреймворк Tornado, а сегодня его использование не так широко распространено.

Я полюбил Django за наличие мощнейшего функционала из коробки. Когда нужно создать достаточно большое веб-приложение, Django хороший вариант, потому что тут и админку развернуть за пару минут можно и базовый CRUD делается довольно быстро и просто. Не нужно возиться с миллионом конфигов - Django сам запустит базу данных на SQLite, а если захочется масштабироваться, то поменять СУБД - простейшая задача. Разработчику можно сфокусироваться на более интересных и творческих задачах, когда фреймворк берёт всю рутину на себя.

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

🎤 feelin про #Python