Бесплатный фрагмент - Поколение JSON

Об авторе

В IT-индустрии я более 10 лет. Мой путь начался с классической веб-разработки и верстки в 2013 году. За эти годы я успел поработать в совершенно разных ролях. Был рядовым верстальщиком, фронтенд-разработчиком, тимлидом и менеджером проектов. В итоге вырос до руководителя отдела разработки. На позиции менеджера проектов мне даже пришлось самому писать бэкенд на Node. js — да, жизнь меня помотала.

Право на ворчание

В моем портфолио — работа как в драйвовых digital-агентствах, так и в крупных системных интеграторах. Я руководил отделами в 20+ человек, строил процессы и спасал дедлайны. Но эта книга родилась не из успешных успехов. Она родилась из шрамов.

Хроника одного провала: как я стал «фронтендером на бэкенде»

Когда я начинал карьеру менеджера проектов, на одном из этапов я не смог вовремя найти бэкенд-разработчика. Сроки горели, риски росли. И тогда во мне проснулась самоуверенность:

«У меня больше 5 лет опыта во фронтенде! Я знаю JS! Что может случиться?»

Я решил написать бэкенд сам. Выбрал Strapi (Node. js) — модно, молодежно, из коробки.

Я гордился собой. Я построил не просто API, я сделал конструктор. В админке были настроены компоненты: маркетолог мог сам собрать страницу из блоков, выбрать картинку, поменять текст. Фронтенд (на Nuxt. js) подхватывал эти компоненты на лету. Удобно? Безумно.

Локально всё летало. Но вот настал день релиза. Сайт (обычный сайт застройщика, никакой высокой нагрузки!) наполнили контентом.

Я открываю страницу… и жду. Секунда. Две. Пять.

Страницы грузились более 5 секунд.

Это был холодный душ. Я чувствовал всю тяжесть провала. Мой «гениальный конструктор» породил монстра: MongoDB захлебывалась, пытаясь вытащить связанные сущности и отдать гигантский JSON.

В панике я прикрутил Redis (даже отправил пул-реквест в плагин для Strapi в процессе). Это была «синяя изолента», которая спасла ситуацию — скорость стала приемлемой.

Но урок я усвоил навсегда: фронтенд-мышление на бэкенде — это катастрофа.

Я пытался перенести компонентную логику (как во Vue/React) в базу данных. Я не думал о связях, индексах и нормализации. Я думал «блоками». Мой код работал, но архитектура была мертва. Тот фронтендер во мне не мог этого знать — у него просто не было базы.

Триггер: «Ну, это не нужно в работе…»

Почему я сел писать эту книгу? Последней каплей стали собеседования. Я искал системного аналитика. Не сеньора-помидора, а простого, крепкого джуна с базой. Это превратилось в день сурка. Кандидаты шли бесконечным потоком, как под копирку. Все они хотели 100–150 тысяч рублей. И при этом ни один — ни один! (ну ладно, парочка была) — не мог ответить на вопросы о фундаментальных типах данных.

— «Ну, это не нужно в работе…»

Было даже собеседование с PHP-разработчиком с 5-летним опытом. Я думал: «Ну этот-то знает!». Нет. Та же пустота в глазах при вопросах чуть глубже общих вопросов.

То же самое с менеджерами проектов. Я требовал от них понимания того, как работает IT, а не только как двигать таски в трекере. Я понимаю, что во многих компаниях это считается «чересчур» и таких специалистов на рынке объективно мало. Таких людей оказались единицы.

А потом я шел на дейлики. Где менеджеры превращали 15-минутную летучку в часовое совещание, обсуждая цвет кнопок и мешая разработчикам работать.

Я понял: проблема не в людях. Проблема в том, что индустрия перестала требовать базу.

Инженер 24/7 (даже когда спит)

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

Моя настоящая «песочница» — это домашняя лаборатория. Личный сервер, где я обкатываю новые инструменты, тестирую архитектурные решения и запускаю сервисы, которые облегчают (или усложняют, тут как посмотреть) нам жизнь. Умный дом на Home Assistant — один из таких проектов.

Конечно, иногда приходится брать в руки паяльник — например, чтобы превратить обычные «тупые» кондиционеры в умные и подружить их с Алисой. Но суть не в пайке, а в подходе. Технический бэкграунд заставляет меня не просто «собирать конструктор», а задавать неудобные вопросы:

— «А что, если пропадет интернет? Алиса перестанет отвечать. Как я включу свет?» (Поэтому вся критическая логика работает локально).

— «А что, если откажет диск сервера? Где мои бэкапы?»

— «Я открываю доступ наружу для управления с телефона. Как защититься, чтобы мой дом не стал частью ботнета?»

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

Эта книга — попытка вернуть инженерное мышление в мир, захваченный конструкторами.

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

Предисловие: взгляд изнутри

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

Эта книга — о другом.

Она о реальности. О той реальности, которую мы видим каждый день в наших мониторах, но о которой редко говорят на конференциях.

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

4KB против 4GB

В 1988 году советский «Буран» в автоматическом режиме совершил посадку при штормовом ветре, управляемый бортовым компьютером с производительностью меньше, чем у современных умных часов. Инженеры той эпохи создавали чудеса надежности, сражаясь за каждый байт памяти.

Сегодня, в 2026-м, простому приложению для списка задач («Todo List») требуется 400 мегабайт памяти, чтобы просто запуститься. Мы увеличили мощности в миллионы раз, но наш софт стал медленнее, прожорливее и ненадежнее. Почему?

Потому что мы вырастили «Поколение JSON».

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

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

— Почему современный софт потребляет так много ресурсов? И почему это не «прогресс», а лень.

— Почему методологии управления часто превращаются в пустые ритуалы? Карго-культ вместо эффективности.

— Почему сейчас это важно? Эпоха дешевых денег, раздутых штатов и бесконечных ресурсов закончилась. Рынок сжимается. Теперь, чтобы выжить и остаться в профессии, уже недостаточно просто уметь вызывать npm install. Нужно снова учиться понимать фундамент.

Маршрут

Мы пройдем этот путь последовательно.

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

Затем спустимся на уровень архитектуры — посмотрим, как микросервисы и распределенные системы стали новыми «серебряными пулями», убивающими производительность, и почему SPA (Single Page Application) не всегда являются лучшим выбором.

И закончим практикой — конкретными примерами того, как писать код, который переживет хайп. Мы поговорим о настоящем KISS (Keep It Simple, Stupid), о вреде преждевременных абстракций и о том, почему скучный код — это хороший код.

Для кого эта книга?

Эту книгу будет больно читать тем, кто верит, что очередной новый фреймворк решит все проблемы.

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

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

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

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

Моя цель — не напугать вас, а вооружить.

В мире хайпа и маркетинга критическое мышление становится главным инструментом инженера.

Если вы готовы посмотреть на индустрию честно и задать неудобные вопросы — добро пожаловать.

Вы наверняка замечали это чувство: когда вы покупаете флагманский смартфон за тысячу долларов, а «Настройки» в нем открываются с заметной задержкой. Или когда простое приложение для заметок выжирает батарею за полдня. Это чувство, что где-то нас обманули. Что прогресс свернул не туда.

Мы построили цифровую Вавилонскую башню, и она начинает шататься.

Разберемся, почему фундамент дал трещину.

А теперь переверните страницу. Нам нужно поговорить о новой нормальности.

Глава 1. Новая нормальность провалов

Почему мы привыкли к браку?

Введение: машина, которая глохнет

Представьте ситуацию. Вы приходите в автосалон, покупаете новенький немецкий (скорее китайский) автомобиль за десять миллионов рублей. Пахнет кожей, пластик блестит. Вы выезжаете за ворота, проезжаете километр, и вдруг — бах! Двигатель глохнет. Мультимедиа гаснет. Машина встает как вкопанная посреди оживленного шоссе.

Ваши действия? Паника? Звонок эвакуатору? Скандал в салоне? Вы звоните дилеру дрожащими руками. А менеджер на том конце провода отвечает спокойным, скучающим голосом:

— А, это нормально. Не волнуйтесь. Просто выйдите из машины, закройте все двери (это важно!), постойте минуту, потом сядьте и заведите снова. Это у них прошивка такая, бывает. У всех так.

Вы делаете эту нелепую процедуру. Машина и правда заводится. Вы едете дальше. Но через 10 километров ситуация повторяется. И снова. И снова.

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

В мире программного обеспечения (ПО) — это наша ежедневная, рутинная реальность.

Конечно, есть исключения. Программное обеспечение для АЭС, кардиостимуляторов или автопилотов самолетов пишется иначе. Там цена ошибки — жизнь, поэтому там царит паранойя, верификация кода и запрет на «быстрые обновления». Это мир долгосрочного ПО (long-term software).

Но в мире потребительского ПО (consumer software), которым мы пользуемся 99% времени, царит хаос. Мы живем в этой реальности и даже не замечаем её абсурдности.

Ваши умные часы сегодня мощнее, чем серверная стойка банка в 90-х. Ваш iPhone или Android-флагман имеет 8-ядерный процессор, нейромодуль, 16 гигабайт оперативной памяти и SSD-диск со скоростью чтения 3 ГБ/сек. Этой мощности хватило бы, чтобы управлять экономикой небольшой страны или моделировать ядерные взрывы в реальном времени.

Да, теоретически на нём можно майнить криптовалюту или искать лекарство от рака, но мы используем эту мощь, чтобы смотреть котиков в 4K и скроллить ленту без лагов (и то не всегда выходит).

Но почему-то, чтобы просто открыть список контактов в WhatsApp или в корпоративном мессенджере, этому «карманному суперкомпьютеру» требуется полторы секунды. А банковское приложение — гордость отечественного финтеха, в которое вложены миллиарды — может «прилечь» отдохнуть в самый неподходящий момент: в день зарплаты, перед Новым годом или во время распродажи на маркетплейсе.

Историческая справка: эпоха дефицита и героев

В 1981 году Биллу Гейтсу приписывают фразу: «640 КБ памяти должно хватить каждому». Сегодня над ней принято смеяться. Ха-ха, какие глупые были люди! Ведь сейчас одна иконка на экране вашего смартфона (в разрешении Retina/4K) может весить больше 640 КБ.

Но давайте посмотрим на это с другой стороны. В 90-х годах программисты были настоящей элитой инженерной мысли. Чтобы написать культовую игру Doom, Джон Кармак использовал хитрейшие математические трюки (знаменитый «быстрый обратный квадратный корень»), чтобы выжать из слабого процессора 386/486 возможность рисовать 3D-графику. Каждый такт процессора был на счету. Каждый байт памяти был на вес золота.

Цена элитарности: у той эпохи была и темная сторона. Ручное управление памятью означало, что любая ошибка программиста приводила к мгновенному краху всей системы («Синий экран смерти», BSOD). Переполнение буфера (buffer overflow) было повсеместным, открывая хакерам двери в любые системы. Если программа зависала, вы теряли документ, который писали 4 часа. Сегодня, если приложение «фризит», оно чаще всего восстанавливается, и данные сохраняются в облаке. Мы обменяли «стальную» эффективность на безопасность и комфорт.

Сегодня ответственность размыта до полной неузнаваемости. «Ничего страшного, мы поправим это в патче 1.0.2 завтра. Или через неделю». Мы называем это «Agile», «Iterative approach», но на самом деле это просто халатность.

Диагноз: поколение JSON

Именно здесь кроется корень всех зол.

За последние 10 лет индустрия породила новый класс специалистов — «поколение JSON».

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

Они берут данные с фронтенда, конвертируют их в JSON, отправляют на бэкенд, там снова парсят, кладут в базу.

В их картине мира нет байтов, нет процессора, нет сети. Есть только бесконечный поток текстовых данных в фигурных скобках.

Они не виноваты. Их так научили курсы. Их так заставил работать рынок («фича важнее качества»).

Но именно это «легкое» отношение к данным («ну, добавлю еще одно поле, текст же легкий») и приводит к тому, что наши приложения потребляют гигабайты памяти на ровном месте.

Культ перезагрузки: психология раба

Вспомните, когда вы в последний раз перезагружали свой ноутбук или смартфон не потому, что села батарейка, а потому что он начал «тупить»? Или когда вы принудительно «убивали» вкладку браузера или приложение в диспетчере задач?

Скорее всего — сегодня. Или вчера. Это действие стало нашим безусловным рефлексом.

Что делает современный человек, если Wi-Fi перестал работать? Он идет и выдергивает роутер из розетки. Он не звонит провайдеру, не запускает диагностику. Он просто делает «Hard Reset».

Психологи называют это состояние «выученная беспомощность». Это термин из экспериментов над животными: если собаку долго бить током, когда она пытается выбраться из клетки, она в какой-то момент перестает пытаться. Она ложится и скулит, даже если дверь открыта.

Мы, пользователи XXI века, — это та самая собака. Мы смирились с тем, что мы не контролируем свои устройства. Если телевизор не включается с первого раза — мы не идем менять телевизор. Мы думаем: «Ну, глюк».

Мы перестали ожидать качества. Качество стало роскошью, а не стандартом.

Почему нам плевать? (теория 99% дилетантов)

Не стоит винить пользователей. Правда в том, что мы все — дилетанты в 99% областей.

— Фотография: профессионал видит «заваленный горизонт» и «плохой динамический диапазон». Обычный человек видит — «о, котик!» и ставит лайк.

— Еда: шеф-повар чувствует, что соус передержали. Обычный человек ест и говорит «вкусно».

— Звук: аудиофил слышит компрессию в MP3. Обычный человек слушает музыку в метро через дешевые наушники и счастлив.

То же самое с софтом. Разработчик видит «раздутый Electron» и «тормозную анимацию». Пользователь видит «кнопку, которая делает то, что надо».

Людям не плевать намеренно. У них просто нет компетенции, чтобы оценить насколько всё плохо. И рынок этим пользуется, скармливая нам «цифровой фастфуд».

Когда Apple или Google выпускают новую версию операционной системы (iOS, Android), зайдите на любой технический форум. Что там обсуждают? Новые потрясающие функции? Удобство интерфейса?

Нет. Топ-3 вопроса всегда одинаковые:

— «Как там батарея? Сильно жрет?»

— «Глюков много? Ставить можно или лучше подождать?»

— «Телефон сильно греется?»

Мы боимся обновлений. Потому что наш опыт говорит: новое в современном IT почти всегда означает более медленное, более тяжелое и менее стабильное.

Экономика багов

Как заметил Ричард Гэбриел в своем эссе «Worse is Better» (1989), рынок часто выбирает технологии, которые проще в реализации («худшее»), а не те, которые правильнее («лучшее»). Простота и скорость распространения бьют качество.

Почему так происходит? Неужели программисты разучились писать код?

Нет. Проблема не в руках, а в деньгах. В современной IT-экономике качество стало невыгодным.

Если вы будете вылизывать свой продукт до идеала (как делал Стив Джобс в 2007 году), вы выпустите его через год. А ваш конкурент выпустит кривую, глючную версию («MVP») завтра.

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

Мы сами приучили рынок к тому, что софт — это «жидкая субстанция». Потому что сложность убивает надежность.

Чем больше слоёв абстракции вы накручиваете (React -> Redux -> Saga -> BFF -> Микросервисы -> K8s), тем больше точек отказа.

В 2010 году, чтобы показать «Hello World», нужно было создать index.html. В наши дни нужно скачать 200 МБ зависимостей, настроить Webpack, Babel, Docker и CI/CD.

Мы построили машину Руба Голдберга.

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

Раньше, если вы покупали диск с игрой за 1000 рублей и она не работала, это был позор. Разработчик мог обанкротиться. Сегодня, если приложение падает, мы просто пожимаем плечами: «Ну, это баг. Ждем патч».

Мы превратили баги из «чрезвычайного происшествия» в «обыденный инцидент». Мы создали целую индустрию управления багами (Jira), вместо того чтобы создать индустрию отсутствия багов.

Здесь и рождается феномен Client-Side Testing.

Раньше тестирование проходило внутри компании (Alpha, Beta, QA). Сегодня, в погоне за скоростью (Time to Market), мы переложили эту работу на пользователей.

Client-Side Testing — это не когда код выполняется на клиенте. Это когда Пользователь тестирует наш код своими деньгами, нервами и временем. Мы выкатываем сырой продукт в продакшн, а потом смотрим логи: «Ой, у 5% юзеров упала транзакция. Ну ничего, откатим».

Бизнес часто исходит из гипотезы: пользователь потерпит. Он поноет, но не уйдет. Потому что уходить некуда — у конкурента так же глючит.

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

Инцидент «Черная пятница»

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

Дано: 11 ноября. День холостяка. Всемирный день шоппинга. Главная распродажа года. Маркетинговый отдел готовился к этому полгода. В рекламу по ТВ, в интернете и у блогеров вложено 500 миллионов рублей.

Ожидается рекордный трафик: 10 000 заказов в секунду на пике.

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

10:00 утра. Старт распродажи. Таймер на главной странице обнуляется.

Трафик взлетает вертикально, как ракета. Графики нагрузки на CPU (процессоры) и RAM (память) зеленые. Система держит удар! Идут продажи на сотни миллионов рублей в минуту.

10:15. Внезапно, как по команде рубильника, графики обрываются.

Время ответа API (latency) взлетает с нормальных 50 мс до катастрофических 30 секунд, а потом запросы просто начинают отпадать по таймауту.

Миллионы пользователей видят на экранах белого динозаврика или ошибку 500 «Internal Server Error».

Корзины не открываются. Оплата не проходит. В чат поддержки летят тысячи сообщений с проклятиями. Бизнес теряет примерно 10 миллионов рублей выручки каждую минуту простоя.

10:30. В офисе компании паника. Объявлен «красный код». Собирается комната инцидентов.

Сидит вся команда: админы, разработчики, менеджеры, CTO. Лица у всех бледные.

— Это DDoS-атака конкурентов?

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

— База данных легла под нагрузкой?

— Нет, CPU на базе данных — 10%. Она отдыхает.

— Сеть? Балансировщики?

— Всё в норме.

— Тогда что?! Почему приложение мертвое?!

10:45 (Убыток превысил 300 млн руб).

Один из системных администраторов замечает странность в мониторинге дисковой подсистемы серверов приложений. Диски загружены на 100% (IO Wait). Сервера что-то пишут на диск с бешеной скоростью.

Начинают копать логи. И находят причину.

Один Middle-разработчик (хороший парень, не вредитель) за день до релиза вносил небольшие правки в модуль оформления заказа. Он хотел отладить какую-то редкую ошибку. И, чтобы видеть данные, он добавил одну безобидную строчку кода:

logger.info («Processing order: " + JSON.stringify (orderObject));

Он хотел видеть в логах детали заказа. «Ну, запишу пару килобайт в лог, что такого?».

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

Размер одного такого объекта в виде текста достигал 2 мегабайт.

Когда пошел реальный трафик (10 000 заказов в секунду), система попыталась записывать 20 гигабайт текста в секунду на жесткий диск сервера логов.

Никакой стандартный серверный диск не способен выдержать такую скорость записи.

Дисковая подсистема «захлебнулась». Операционная система, пытаясь спасти ситуацию, заблокировала все процессы, ожидая завершения записи на диск.

Всё встало. Из-за одной строчки лога.

Финал: строчку нашли. Удалили. Выпустили экстренное обновление. В 11:00 система поднялась.

Цена этой ошибки: сотни миллионов рублей упущенной выручки, штрафы от партнеров и огромный репутационный удар.

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

Примечание автора:

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

Анатомия тормозов

Почему такие глупые ошибки вообще возможны? Давайте заглянем «под капот» современных технологий. В 90% случаев, когда ваш телефон греется, а приложение лагает, виновата работа с памятью.

Как это работало раньше

Представьте, что вы (ваша программа) пришли в библиотеку (оперативная память) поработать. Вы подходите к библиотекарю (операционная система) и говорите: «Мне нужен стол для работы».

Библиотекарь выдает вам стол №5. Вы работаете, раскладываете книги, пишете конспекты. Когда вы закончили, вы обязаны подойти к библиотекарю и сказать: «Я закончил, стол №5 свободен». И только после этого уйти.

Если вы забыли это сделать — стол остается занятым. Навсегда (пока библиотеку не закроют/не перезагрузят компьютер). Приходят новые читатели, а свободных столов нет. Библиотекарь говорит «Мест нет» (Out of Memory), и библиотека закрывается (Crash).

Это называлось «ручное управление памятью» (языки C, C++). Это сложно, требует жесточайшей дисциплины, но это невероятно эффективно. Программа берет ровно столько, сколько нужно, и отдает сразу же. Никаких простоев.

Как это работает сейчас

В какой-то момент приоритеты сместились. Скорость разработки стала важнее оптимизации.

И индустрия придумала сборщик мусора (garbage collector, GC).

Это великое изобретение. Без иронии. Переход на языки с GC (Java, C#, Go, Python) спас индустрию от 70% уязвимостей (Use-After-Free, Memory Leaks). Разработка ускорилась в разы: программисту больше не нужно думать, как очистить память сложнейшего графа объектов социальной сети.

Но это работает так: вы приходите, берете стол, мусорите на нем, комкаете бумагу, кидаете стаканчики на пол. И просто уходите.

За вами бегает специальный человек (уборщик). Он смотрит: «Ага, этот стаканчик вроде никому не нужен, выкину его».

Языки Java, Python, JavaScript, Go, C# — все они используют GC.

В чем проблема?

Уборщик (GC) — это тоже программа. И она тоже требует ресурсов процессора и памяти.

Но самое страшное: иногда мусора становится так много (как в истории с Черной пятницей), что уборщик не справляется в фоновом режиме.

Тогда он достает свисток и орет на весь зал:

«ВСЕМ СТОЯТЬ! НИКОМУ НЕ ДВИГАТЬСЯ!».

Все процессы останавливаются. Программа замирает. Уборщик судорожно выгребает горы мусора.

В этот момент на вашем телефоне «фризится» скролл ленты. Игра зависает на секунду. Видео заикается. Процессор бросает все полезные дела и начинает работать мусорщиком.

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

Однако лень программистов и особенности инструментов — это только половина беды. Вторая половина уравнений тормозов — это непомерные аппетиты бизнеса.

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

Почему российские приложения становятся «супераппами»?

Россия уникальна своим путем развития мобильного веба. Наш финтех (Сбер, Т-Банк, Альфа) объективно один из лучших в мире. Попробуйте найти в Европе банк, где можно открыть счет за 2 минуты через приложение и сразу получить карту. Но у этой цифровой медали есть обратная, тяжелая сторона.

Посмотрите на приложение вашего банка. Пять лет назад оно весило 50–70 МБ. Оно умело показывать баланс и делать переводы. Оно «летало».

Сегодня оно весит 500–600 МБ. Что внутри?

— Банк (собственно, переводы).

— Инвестиции.

— Страхование.

— Маркетплейс (купи кроссовки в приложении банка).

— Бронирование ресторанов.

— Сторис (как в популярной соцсети с картинками, только про кредит).

— Голосовой помощник (который пытается шутить невпопад).

Приложение из удобного инструмента («молоток») превратилось в «швейцарский нож весом в 10 килограмм». Им можно делать всё, но неудобно делать главное — забивать гвозди.

Банку невыгодно, чтобы вы быстро перевели деньги и закрыли приложение. Бизнес-метрики требуют вовлечения и удержания. Им нужно, чтобы вы «залипли». Чтобы вы посмотрели сторис, сыграли в игру, получили «монетки».

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

Однако эта экспансия не ограничивается экраном смартфона. Эта «новая нормальность» уже давно перебралась на наши рабочие столы, замаскировавшись под современные и «легкие» приложения. И у этой десктопной эпидемии есть своё, вполне конкретное имя.

Глава 2. Эпидемия раздутого софта: Chrome в овечьей шкуре

Закон Вирта

«Программное обеспечение замедляется быстрее, чем аппаратное обеспечение (железо) становится быстрее».

Тогда, в эпоху процессоров Pentium 100 МГц и царства Windows 95, это воспринималось как ворчание перфекциониста. «Ну подумаешь, Word открывается 3 секунды, зато там есть проверка орфографии!».

Вирт (который, к слову, написал всю операционную систему для компьютера Lilith, имея всего 8 МГц частоты) смотрел на индустрию с ужасом. Сегодня мы понимаем: старик был чертовски прав.

Мы покупаем ноутбуки с процессорами M4/M5 или Intel i9, которые мощнее, чем весь дата-центр Google времен его основания. 10 ядер, нейронный сопроцессор, SSD со скоростью чтения 5 ГБ/сек.

А используем мы эту мощь для того, чтобы приложение для заметок (Notion/Obsidian) не дергалось при прокрутке списка из 50 строк.

Мы обменяли производительность на ленивое удобство разработки.

Знакомьтесь, Electron: главный паразит современного ПК

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

Slack, Discord, Skype, Notion, Trello, Postman, WhatsApp Desktop и многие другие. Все эти приложения построены на фреймворке Electron.

В чем суть идеи?

Раньше (в «темные века» нулевых), чтобы написать программу для Windows, нужно было нанять C++ разработчика, знающего WinAPI или MFC. Для Mac нужен был человек, знающий Objective-C и Cocoa. Это было:

а) Долго.

б) Дорого (таких спецов мало).

в) Сложно (нужно писать код дважды для разных ОС).

Потом пришли «эффективные менеджеры» и сказали:

— У нас же есть веб-сайт! У нас есть куча специалистов, знающих HTML, CSS и JavaScript! Зачем нам нанимать дорогих C++ инженеров? Давайте просто возьмем наш веб-сайт, завернем его в отдельное «хромированное» окошко и отдадим пользователю как «нативное приложение».

Так родился Electron.

По сути, каждое такое приложение — это отдельный, полноценный веб-браузер Google Chrome.

Да, вы не ослышались.

Когда вы запускаете Slack, вы запускаете браузер.

Когда вы запускаете Discord, вы запускаете еще один браузер.

Когда вы запускаете VS Code, вы запускаете третий браузер.

Все они живут изолированно. Они не делят ресурсы. Каждый тянет с собой свой движок рендеринга, свой экземпляр V8 и свою копию Node. js.

Архитектура тормозов (что внутри?)

Почему Electron такой «жирный»? Вскроем этого монстра.

Это не просто «окно». Это монстр Франкенштейна, сшитый из трех огромных частей:

— Chromium: движок рендеринга (Blink). Тот самый, что рисует сайты в Chrome. Это миллионы строк кода на C++. Он умеет рисовать всё: от простого текста до сложнейшей 3D-графики WebGL, и тащит с собой кодеки для видео, драйверы для геймпадов, поддержку PDF… Даже если ваше приложение — это просто текстовый чат, вы всё равно тащите с собой код для воспроизведения 4K видео.

— Node. js: среда выполнения JavaScript вне браузера. Она дает сайту доступ к вашим файлам на диске (чтобы сохранить документ или картинку).

— V8 Engine: движок JavaScript от Google. Мощнейший JIT-компилятор.

Проблема процессов:

В нормальной программе (WinAPI) есть один процесс и несколько потоков. Они делят память.

В Electron (как и в Chrome) всё разбито на процессы ради безопасности.

— Main Process: координатор.

— Renderer Process: рисует интерфейс.

— GPU Process: работает с видеокартой.

— Network Service: качает данные.

Это значит, что для передачи данных от «диска» (Main) к «экрану» (Renderer) нужно использовать межпроцессное взаимодействие (IPC). Процессы должны «сериализовать» данные в JSON, передать их через память, и «десериализовать» обратно.

Это медленно! Это накладные расходы на ровном месте.

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

Примечание для скептиков (технический нюанс):

Справедливости ради, инженеры Google и команда Electron не сидят сложа руки. Современные версии V8 используют впечатляющие оптимизации: TurboFan JIT-компилятор, ленивую компиляцию (Lazy Compilation), SharedArrayBuffer для разделяемой памяти между процессами. Chromium научился объединять слои (layer squashing) и использовать GPU-ускорение для анимаций.

Однако эти улучшения напоминают попытку осушить океан ложкой. Они оптимизируют движок, но не могут победить груз, который на него навешивают. Когда бизнес-логика приложения (Redux-стор, подписки на WebSocket, аналитика) растет экспоненциально, даже идеально настроенный V8 захлебывается. Оптимизации V8 добавляют 10–20% к производительности. Рост сложности кода приложений отнимает 200–300%. Математика не в нашу пользу.

Сравнение: Hello World

Вариант А: WinAPI (C++)

#include <windows. h>

    int WINAPI WinMain (…) {

    MessageBox (NULL, «Hello!», «App», MB_OK);

    return 0;

}

— Вес EXE: 5 КБ.

— Память: 500 КБ.

— Запуск: Мгновенно.

Вариант Б: Electron

— package. json + main. js + index.html.

— Скачиваем npm install electron (150 МБ).

— Собираем.

— Вес EXE: 120—150 МБ (потому что внутри лежит Chromium).

— Память: 100 МБ (пустое окно).

— Запуск: 2—3 секунды (инициализация V8).

Это абсурд. Мы поставляем 100 мегабайт бинарного кода только для того, чтобы вывести на экран слово «Привет».

Битва блокнотов

Следите за руками.

Задача: написать программу-блокнот. Функции: набрать текст, сохранить, жирный шрифт.

В левом углу ринга: Sublime Text (или Notepad++)

— Написан на C++ (STL, WinAPI).

— Вес дистрибутива: 15—20 МБ.

— Потребление памяти с открытым файлом «Война и мир»: 15 МБ.

— Поиск по тексту: мгновенно.

В правом углу ринга: современный Markdown-редактор на Electron (Obsidian, Notion)

Notion — отличный продукт, но цифры не врут.

— Вес дистрибутива: 200 МБ.

— Потребление памяти (пустой): 400 МБ. (Это 400 миллионов байт! Для пустого экрана!).

— С открытой «Войной и миром»: Может упасть или начать дико тормозить при скролле.

— Почему? Потому что каждая буква в Electron — это DOM-нода <span> b </span>.

Браузер не предназначен для работы с миллионами объектов одновременно.

Кто побеждает в умах пользователей? Парадоксально, но Electron. Почему?

Потому что Notion — это удобно. Это базы данных, связи, канбан-доски и, конечно, красивые обложки с эмодзи. Глупо отрицать: как продукт он великолепен. Но какой ценой?

Sublime Text выглядит как привет из 2000-х. Пользователь выбирает функциональность, но платит за него производительностью своего железа.