Разработчики FFmpeg устроили жёсткий разбор патчей AMD, посчитав их примером того, как не должно выглядеть внесение изменений в крупный опенсорс‑проект. Поводом стала серия патчей, добавляющих поддержку AMD HIP SDK (Heterogeneous‑compute Interface for Portability) под Windows для ускорения обработки видео на видеокартах AMD. Формально цель была полезной: обеспечить аппаратное ускорение и улучшить производительность кодирования и декодирования. Но реализация вызвала шквал критики.
Основная претензия команды FFmpeg — патчи выглядели так, будто они были сгенерированы ИИ и практически не проходили ручного рецензирования. В коде и сопровождающих его материалах обнаружили бессмысленные конструкции, сомнительные решения и явно лишнюю документацию, не имеющую отношения к конкретным изменениям.
Один из самых показательных примеров — константа с названием `"8"` и значением `8`, использовавшаяся в описании параметра `mb_size` (размер блока). С точки зрения здравого смысла и элементарной культуры программирования такая «константа» не только не добавляет ясности, но и превращает код в абсурд: она ничем не отличается от обычного литерала 8, но при этом раздражает читающего своей бессодержательной формой. Разработчики FFmpeg отметили, что подобные конструкции выглядят хуже, чем типичный «сырой» код, и даже ИИ обычно генерирует что‑то более осмысленное.
Не меньше недоумения вызвало и содержание документации в патче. Вместо того чтобы кратко и по существу описать, какие именно изменения вносятся и как их использовать, в текст были включены подробные инструкции по установке gcc и make через пакетный менеджер pacman. По сути, внутрь коммита затесался мини‑гайд по настройке окружения, написанный несколько лет назад и просто перенесённый автором в текущее изменение.
Разработчики FFmpeg справедливо указали: сообщение, прикреплённое к коммиту, должно чётко и лаконично объяснять, что именно меняется и зачем, а не превращаться в замену документации или wiki‑страниц. Никто не будет выискивать инструкции по сборке и настройке системы в комментариях к патчу, тем более в таком специфическом и техническом проекте, как FFmpeg.
Автор патча со стороны AMD в ответ пояснил, что сознательно добавил старую инструкцию по использованию pacman, посчитав её полезной для установки зависимостей. При этом он подчеркнул, что готов удалить её, если рецензенты считают это лишним. Команда FFmpeg извинилась за недопонимание, но одновременно отметила, что удивлена самим фактом: разработчик не провёл грань между задачей коммита и задачей вспомогательной документации. С их точки зрения, такие вещи должны быть строго разделены: есть код изменения, есть его краткое описание и есть отдельные материалы по настройке окружения.
На этом фоне зашёл разговор о том, как вообще должен выглядеть «здоровый» код и какие практики становятся симуляцией инженерии. Отдельно прошлись по привычке некоторых разработчиков заменять магические числа на «говорящие» константы… которые при этом ничего не объясняют. Пример из той же серии — константы вида `EIGHT = 8`, `THIRTY = 30` или даже `EMPTY = ""`. Формально правило соблюдено: магическое значение вынесено в константу. Но по смыслу это та же «магия», только с более шумным оформлением.
Разработчики FFmpeg и многие опытные инженеры подчёркивают: у бессмысленных имён констант нет никакой инженерной ценности. Константа вроде `DEFAULT_CONN_TIMEOUT_SEC = 30` моментально объясняет, что это за число 30 — таймаут соединения в секундах, и позволяет менять его централизованно. А вот `THIRTY = 30` или `EIGHT = 8` ровно ничем не лучше прямого использования числа в коде: читатель всё равно не понимает, *что* за величина скрывается за этим значением. Такая «обязательная константизация» превращается в карго‑культ: правило услышали, а смысл не уловили.
Критика задела и стиль кода: в обсуждении прозвучали примеры циклов и индексации, которые в современном контексте выглядят устаревшими или намеренно усложнёнными. Что‑то вроде:
```c
Pixel *pix = data, *pix_max = data + size;
for (; pix < pix_max; pix++) { ... }
```
часть разработчиков назвала «нечитабельным уродством», особенно на фоне более высокоуровневых подходов в языках вроде C++ или Rust, где есть удобные идиомы для обхода коллекций:
```c++
/// C++
for (const auto& pixel : pixels) {
...
}
```
```rust
// Rust
for pixel in &pixels {
...
}
```
Сторонники классического C в ответ напоминают: достаточно один раз заглянуть в ассемблерный вывод, чтобы понять, что во многих случаях компилятору абсолютно без разницы, используете вы именованную константу или литерал — он всё равно подставит одно и то же значение. Более того, избыточное количество псевдосемантики способно только запутать, если имена не несут реального смысла. С точки зрения низкоуровневой оптимизации такие трюки «ничего не экономят»: компилятор при косвенной адресации не станет зря занимать регистры, если это не требуется.
Важную роль в обсуждении сыграл и вопрос о логике мышления разработчика. На уровне тональности было сказано довольно жёстко: если лучшее, что программист может придумать для объяснения «магического» значения — это константа вида `EIGHT = 8`, то, возможно, он просто не понимает, зачем вообще нужны именованные сущности в коде. Именно такие решения и рождают впечатление, что код ближе к машинному «мусору», чем к результату обдуманной инженерной работы. Ирония в том, что в этот раз подозреваемым оказался не ИИ, а живой человек.
Инцидент затронул и более широкий пласт: использование ИИ при написании кода. Команда FFmpeg фактически сформулировала негласное правило: если вы пользуетесь генераторами кода, это ваша личная ответственность, но присланный патч обязан выглядеть как продукт человеческого рецензирования, а не «сырое» предложение модели. Масштабные опенсорс‑проекты не могут и не должны становиться полем для экспериментов с автогенерацией без последующей доработки. Отсюда — прямой призыв к AMD: прежде чем отправлять патчи вверх по цепочке, нужно:
- внимательно просматривать сгенерированный код;
- вычищать бессмысленные фрагменты;
- удалять случайно перенесённые текстовые блоки;
- следить за соответствием стиля принятым в проекте нормам;
- обеспечивать осмысленные имена констант, переменных и функций.
Особенно болезненно подобные промахи воспринимаются на фоне того, что речь идёт о работе крупной технологической компании. От лидеров рынка ожидают не просто рабочего кода, но и примера инженерной культуры. Когда от имени корпорации прилетает патч с константой `"8" = 8` и вкраплённым старым мануалом по pacman, это воспринимается как признак небрежности ко всему процессу интеграции.
Отчасти история с патчами AMD подсветила и вечный конфликт между «эстетикой» кода и его прагматикой. С одной стороны, есть привычка к предельно коротким именам индексов и переменных — особенно в математических алгоритмах, где `i`, `j`, `k` и небольшие обозначения для параметров выглядят естественными и привычными. Это облегчает сопоставление кода с формулами и упрощает верификацию алгоритмов. С другой стороны, чрезмерное увлечение лаконичностью без учёта читаемости может привести к тому, что код становится не лучше печально известного «1С‑стиля», где переменные и структуры со временем превращаются в нечитаемый монолит.
Вывод, к которому в итоге склоняются опытные участники подобных споров: важна не слепая верность формальным правилам, а умение чувствовать меру. Именовать стоит то, что действительно требует пояснения. Выносить в константы нужно те значения, которые:
- используются в нескольких местах,
- имеют бизнес‑смысл (таймаут, лимит, размер буфера, код статуса),
- могут измениться в будущем и должны правиться централизованно.
А бессмысленный перенос магических чисел в «говорящие» константы без содержания в стиле `TEN = 10` — пример той самой имитации инженерной практики, которая только засоряет кодовую базу.
История с FFmpeg и AMD — типичный знак времени. С одной стороны, всё активнее используются ИИ‑инструменты, генераторы кода и автокомплит, которые реально могут ускорять разработку. С другой — именно сейчас особенно ясно видно, насколько критично человеческое участие на стадии ревью. Без твёрдой руки инженера ИИ‑подсказчик легко превращается в источник «раздутых патчей» с сомнительной логикой, мёртвым кодом и бессмысленными именами.
Для крупных инфраструктурных проектов вроде FFmpeg ценность не только в том, что код «работает», но и в том, что его можно поддерживать, развивать и безопасно изменять годами. Это невозможно без строгих требований к качеству патчей, прозрачности коммитов и адекватной инженерной культуры. Именно поэтому подобные конфликты так болезненно обнажают все слабые места: они не про одну конкретную константу `"8"`, а про отношение к разработке в целом.
