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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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