В 2010 мы писали гибридные мобильные приложения на PhoneGap. В 2011 запустили первый Node.js-сервис на версии 0.6 - без LTS, без нормального мониторинга, на голом энтузиазме и горстке примеров с GitHub. В 2012 переходили на mobile-first и доказывали клиентам, что мобильный трафик скоро обгонит десктоп. В 2013 поднимали Hadoop-кластеры ради задач, которые Postgres решил бы за секунды. В 2014 портировали Flash на Canvas и считали это прогрессом.
Большинство конкретных инструментов того времени либо мертвы, либо не узнать. Но за каждым решением стояла логика - что именно мы оптимизировали, почему выбрали именно этот подход, где просчитались. Эта логика работает на каждом проекте, который мы сдаём в 2025 году.
1. Pull-архитектура для push-данных - всегда потеря
2011 год. Дашборд, 150 одновременных пользователей, PHP-бэкенд. Клиент с частотой 5 секунд - 1800 MySQL-запросов в минуту, 98% которых возвращали идентичные данные. Сервер грелся вхолостую.
Мы заменили опрос на WebSocket-соединение через Node.js. Сервер отправлял данные только при изменении. Нагрузка на базу упала в 2700 раз.
Конкретный стек - Socket.io 0.9, MySQL с интервальным change detection - давно устарел. Но сам принцип никуда не делся: если данные меняются по событию, модель доставки должна быть событийной, а не временно́й.
В 2025 этот антипаттерн встречается в другом обличье:
- Мобильное приложение опрашивает REST API каждые 30 секунд для изменений, которые происходят раз в час
- Дашборд обновляется по таймеру вместо подписки на pub/sub
- Микросервис мониторит таблицу в базе вместо того, чтобы слушать очередь событий
Инструменты стали лучше - SSE, WebSocket, SQS, Kafka. Рассуждение, которое к ним приводит, не изменилось с 2011 года.
2. Mobile-first - не про экраны, а про порядок принятия решений
В 2012 мы поменяли процесс проектирования: сначала мобильный макет, потом десктоп. Технически это было про 320px. По-настоящему это было про то, чтобы принимать сложные решения до того, как клиент к чему-то привязался.
Десктопный холст прощает откладывание. Можно добавить боковую панель, второй уровень навигации, промо-баннер, виджет соцсетей. К моменту когда доходишь до мобильного - клиент влюблён в дизайн, который в 320px не влезает. Начинаешь отнимать то, к чему люди уже прикипели. Разговор тяжёлый.
Mobile-first задавал вопрос в самом начале: что одно должен сделать пользователь на этом экране? Всё остальное было опциональным.
В 2025 этот же вопрос мы задаём перед каждой фичей:
- Что одно она должна делать?
- Что можно убрать без потери сути?
- Что мы добавляем потому что есть место, а не потому что нужно?
Ограничение мобильного дизайна - мало места, значит нужна ясность - то же самое ограничение, которое делает хорошим продуктовый скоупинг. Этот фреймворк применим к роадмапу так же, как к вайрфрейму.
3. Новый рантайм: первый деплой выбирается по радиусу поражения
Наш Node.js 0.6 в production в 2011 дал один OOM за 60 дней - утечка памяти в объекте кэша, проявилась через 18 дней работы. PM2 автоматически перезапустился за 2 секунды. Никаких алертов, никого не разбудили. Дашборд мигнул и поднялся.
Нам повезло. Но мы также сделали так, чтобы повезло: запустили Node.js за nginx с менеджером процессов, логировали всё с избытком, и выбрали BI-дашборд - не транзакционный флоу - как первую production-нагрузку.
Принцип: при внедрении незнакомой технологии первый production-деплой выбирается по радиусу поражения, а не по уровню энтузиазма команды.
Мы следуем этому правилу до сих пор:
- Первый Lambda-деплой был фоновым генератором отчётов, не API-эндпоинтом
- Первый Rust-сервис - офлайн-батч-процессором, не пользовательским путём
- Первый экран React Native - страницей настроек, не core flow
Новая технология в low-stakes контексте даёт реальные данные о production-поведении, реальные режимы отказов и обоснование (или антиаргумент) для следующих внедрений. Это ценнее любого бенчмарка.
4. Фреймворки стареют быстрее, чем проблемы
2012-2013: войны JavaScript MVC. Backbone против Knockout против Ember против Angular. Горячие дискуссии, сильные мнения, статьи на Хабре с тысячами просмотров.
К 2014 году появился React. К 2016-му он выиграл. К 2020-му хуки заменили классовые компоненты. Каждый фреймворк, о котором мы спорили в 2012-м, либо мёртв, либо не узнать.
Проблемы, которые они решали - синхронизация UI-состояния с данными, структурирование JavaScript-приложений - те же самые проблемы решают React, Vue и Svelte сегодня.
Вывод: инвестируй понимание в проблему, не в фреймворк. Разработчик, понимавший зачем нужен был Backbone - для управления состоянием в масштабе - переходил на React за неделю. Разработчик, выучивший API Backbone наизусть, тратил месяц на переход и ещё полгода на недовольство.
На собеседованиях мы теперь спрашиваем: «Расскажи о технологии, которую ты использовал и которая больше не актуальна. Что именно из этого опыта перенеслось дальше?» Ответ говорит больше, чем любой технический тест.
5. Выпущенное на 80% лучше невыпущенного на 95%
В 2013 году мы запустили OCR-сканер чеков с точностью 68% на уровне символов. После предобработки - 81%. С UI подтверждения пользователем это стало рабочим продуктом. Тысячи авансовых отчётов прошли через него.
Можно было ждать лучшего OCR. Google Cloud Vision дал 95%+ - в 2016 году. Три года без продукта, без данных о реальных чеках, без понимания что именно нужно улучшать.
Продукт при 81% + подтверждение пользователем оказался лучше, чем непродукт при 95%.
В 2025 мы применяем тот же принцип к AI-фичам:
- Сначала рекомендации на простой коллаборативной фильтрации - потом трансформер, если вовлечённость подтвердит гипотезу
- Сначала keyword-поиск - потом семантический, разница в точности часто меньше разницы в сложности системы
- Сначала модерация на правилах - потом LLM, когда есть реальные данные для дообучения
Решение на 80% говорит тебе, каким должно быть решение на 95%. Невыпущенное решение на 95% не говорит ничего.
6. Стоимость операционной сложности всегда занижается
2012-2013: «большие данные» означало «нужен Hadoop». Мы подняли Hadoop-кластер для аналитики контента с ~50 ГБ логов. Hadoop проектировался для петабайт на сотнях узлов. У нас было 4 узла.
Обслуживание кластера, планирование задач, отладка MapReduce-сбоев, проблемы репликации HDFS - постоянный фоновый шум. Те же данные в Postgres с нормальными индексами отвечали бы на каждый наш вопрос и тратили бы в 10 раз меньше времени на запрос.
Мы выбрали инструмент под проблему, которую воображали иметь, а не под ту, что была на самом деле.
В 2025 этот же паттерн появляется с микросервисами, Kubernetes, event sourcing и CQRS. Всё это легитимные инструменты для реальных проблем в реальном масштабе. Все они чрезмерно применяются на уровне стартапа и небольшой команды.
Вопросы перед добавлением инфраструктурной сложности:
- Какой реальный объём данных или запросов делает это необходимым?
- Каковы операционные расходы после запуска - мониторинг, отладка, деплой?
- Какая более простая альтернатива, от которой нам придётся перерасти, прежде чем это понадобится?
«Может понадобиться позже» - не ответ. «При масштабе» = когда масштаб есть, а не когда ты его предвидишь.
7. Ментальная модель пользователя - и есть настоящий продукт
В 2014 мы портировали Flash-конфигуратор продуктов на HTML5 Canvas. Flash-версия создавалась годами: 3D-рендеринг продукта в реальном времени, drag-and-drop выбор компонентов, мгновенный расчёт цены. Технически она была впечатляющей.
Canvas-версия работала на 60fps, открывалась на iPad, не требовала плагина. Во всём лучше оригинала.
Два месяца пользователи ненавидели её.
Не за медлительность или функциональность. За то, что выглядело иначе. Кнопки сдвинулись на несколько пикселей. Тайминг анимации изменился. Курсор менялся в других точках. У людей, работавших с Flash-версией несколько лет, была мышечная память - и мы её сломали.
Мы восстановили интерактивную модель один в один: те же зоны клика, тот же тайминг, те же звуки подтверждения. Принятие вернулось.
Урок: пользователи переживают не твою архитектуру, а свою ментальную модель продукта. Технический редизайн и продуктовый редизайн - два независимых процесса. Можно поменять весь стек и сохранить опыт. Можно не трогать стек и незаметно сломать опыт.
Перед любым серьёзным пересозданием: задокументируй интерактивную модель, которую сохраняешь. Не UI - ментальную модель: где что находится, что что делает, что означает каждая реакция системы. Проверь что сохранил её прежде чем выпускать.
8. Срок жизни «лучших практик» сокращается
В 2010-м лучшая практика для JS - конкатенировать и минифицировать один файл. В 2015-м - Webpack-модули. В 2020-м - code splitting и lazy loading. В 2024-м - RSC со стримингом и edge rendering.
Правильный ответ менялся пять раз за 14 лет. При этом каждый был правильным для своего контекста: условия сети, возможности браузеров, зрелость инструментов, размер приложений.
Что не менялось: базовое рассуждение. Минимизировать байты. Минимизировать блокирующую работу. Парсить только то, что нужно, когда это нужно. Каждый «правильный ответ» с 2010 по 2024 - применение одних и тех же принципов к разным ограничениям.
Мы перестали изучать «текущую лучшую практику» как конечную точку и начали изучать рассуждение, которое её порождает. Конечная точка изменится. Рассуждение переносится.
На вопрос «X - это правильный подход?» мы теперь ищем ответ не «да, X - текущая лучшая практика», а: «вот ограничения, под которые оптимизирован X, и вот применимы ли они к нашему случаю».
9. Измерение меняет то, что ты строишь
До mobile-first в 2012 у нас были мнения о мобильном UX. После того как мы измерили - 18% мобильного трафика, 68% показатель отказов на мобильном, конверсия 0.8% против 4.1% на десктопе - у нас был мандат.
Измерение не говорило нам что строить. Оно говорило о цене того, что мы не строим. Это другой разговор с заказчиком, другое обоснование трёх недель редизайна, другой приоритет в спринте.
Каждое значимое решение, которое сработало, имело измерение в основе. Не всегда точное - иногда направленное, иногда прокси-метрики. Но что-то, что делало компромисс видимым.
Дисциплина с 2012 года: перед реализацией чего-либо существенного - определи как выглядит «работает» в числах. Не «пользователям понравится». Не «станет лучше». Какое число вырастет, насколько, за какое время? Если не можешь определить это до начала, ты не узнаешь успешно ли всё после.
Звучит очевидно. На практике большинство фичевых решений принимаются на интуиции и одобряются ретроспективными метриками. Правильное измерение - определить критерий заранее, измерять против него - всё ещё редкость даже в сильных командах.
10. Скучная инфраструктура даёт сложные проценты
В 2012-2014 мы построили первый полноценный CI/CD-пайплайн: Jenkins, автотесты, staging, деплой одной командой. Настройка заняла четыре недели. Чувствовалось как накладные расходы.
За следующие два года это окупилось в каждой фиче, которую выпустили быстрее. В каждом баге, пойманном до production. В каждом пятничном вечере, который не потратили на ручной деплой и последующий мониторинг.
Конкретные инструменты устарели. Логика инвестиции - нет.
Каждая «скучная» автоматизация ручного процесса накапливается со временем. Каждый ручной процесс, который нормализуется - «это всего 20 минут» - превращается в часы за спринт, дни за квартал, инциденты когда кто-то забывает шаг.
Вопрос при любом ручном процессе, повторяющемся больше двух раз: сколько стоит автоматизация, сколько стоит неавтоматизация за 12 месяцев? Ответ почти всегда один: автоматизировать.
Что на самом деле перенеслось
Мы иногда романтизируем 2010-2014: дикий запад, открытие паттернов, которые стали классикой. Реальность включала также много потраченных усилий на неправильные инструменты, решения с недостаточными данными, пользовательские опыты, страдавшие пока мы учились в production.
Переносимым оказалось не конкретная технология и не конкретный паттерн. Переносимой оказалась привычка понимать почему принято решение - какое ограничение оно решает, какой режим отказа вводит, что нужно изменить, чтобы решение оказалось неправильным.
Node.js решал проблему C10K для I/O-нагруженных сервисов. Это реальное ограничение до сих пор. Event loop - правильный ответ на него до сих пор. Конкретная версия и экосистема изменились полностью.
Mobile-first решал проблему откладывания приоритизации в дизайн-процессе. Это реальное ограничение до сих пор. Начинать проектирование с ограничений - правильный ответ до сих пор. Конкретные ограничения сместились, принцип не изменился.
Каждый урок из 2010-2014, который мы применяем, имеет одну форму: проблема, ограничение и паттерн, который на это ограничение отвечает. Убери специфику - получишь переносимую модель. Оставь только специфику - получишь ностальгию.
Серверы того времени давно выключены. Код удалён. Понимание того, почему он работал - или не работал - работает каждый день.