Самый лучший код — тот, который не пришлось писать

Принято считать, что работа инженера начинается там, где появляется код. На практике всё наоборот: самая дорогая часть работы происходит до того, как написана первая строчка.

Недавно был ровно такой случай — обычный заказ с фриланса, который чуть не превратился в отдельный продукт.

Задача на словах

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

Если идти классическим путём, решение быстро обрастает деталями. Подключаемся к Telegram через клиентский стек, забираем аудио и видео через VoIP — PyTgCalls или что-то подобное, декодируем Opus и H264, пропускаем поток через ffmpeg для синхронизации и ретрансляции, упаковываем всё в WebRTC или HLS. И под это нужен отдельный сервер, который будет держать всю эту конструкцию.

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

Здесь и начинается развилка.

Путь исполнителя

Можно принять исходное требование как данность: источник — Telegram, значит, работаем с Telegram. Дальше включается инженерная честность: если данные приходят сложным путём, этот путь придётся повторить целиком.

В итоге система выглядит так:

Telegram → клиент → декодирование → ffmpeg → WebRTC/HLS → сайт

Работает? Да. Сложно? Да. Хрупко? Тоже да. И самое неприятное — поддерживать всё это придётся ровно в таком виде, со всеми внутренними протоколами Telegram, которые меняются, когда им вздумается.

Показательно, что сегодня весь этот путь охотно пройдёт любой ИИ-агент. За вечер, аккуратно, по лучшим практикам, местами даже с тестами. PyTgCalls, декодирование, синхронизация — всё будет реализовано грамотно. Только это будет грамотная реализация неправильного решения. Агент не станет спрашивать, та ли это задача: его попросили решить именно эту, и он её решит.

Вопрос, который ломает архитектуру

Но есть другой вопрос, и звучит он почти невежливо: а почему вообще источник — Telegram?

Этот вопрос обычно никому не нравится. Он не про код — он про то, что задачу нужно пересмотреть, а не выполнить как есть.

И тут выясняется простая вещь: Telegram здесь вовсе не источник трансляции. Это просто транспорт.

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

Вся сложная схема сворачивается в:

Источник → сайт

Без промежуточных слоёв. Без декодирования VoIP. Без борьбы с тем, что Telegram в любой момент поменяет внутренний протокол.

Разница в мышлении

Это не история про Telegram. Это история про два разных способа думать.

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

Подход инженера — сначала разобраться, откуда вообще взялась проблема, убрать лишние уровни и, если получится, вообще не писать код.

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

Неприятный вывод

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

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

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

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

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