Поколение JSON. Хроники Client-Side Testing
Қосымшада ыңғайлырақҚосымшаны жүктеуге арналған QRRuStore · Samsung Galaxy Store
Huawei AppGallery · Xiaomi GetApps

автордың кітабын онлайн тегін оқу  Поколение JSON. Хроники Client-Side Testing

Данил Емельянов

Поколение JSON

Хроники Client-Side Testing





Если отключить StackOverflow и ChatGPT, останетесь ли вы инженером, или превратитесь в беспомощного пользователя?

Мы вырастили «Поколение JSON» — разработчиков, которые клеят API, но не понимают физику процесса. Мы забыли базу ради хайпа.

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

Перестаньте молиться на фреймворки. Начните изучать Computer Science.


12+

Оглавление

Об авторе

В 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 мегабайт памяти, чтобы просто запуститься. Мы увеличили мощности в миллионы раз, но наш софт стал медленнее, прожорливее и ненадежнее. Почему?

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

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

...

Ұқсас кітаптар