Разбор реализации конкурентов: как лучшие строят конкретную фичу

Ты собираешься строить фичу {{feature}}. Прежде чем принимать архитектурные решения, разбери как её реализуют сильнейшие в этой области.

Важно: этот разбор отвечает на вопрос «КАК строить», а не «ЧТО строить». Промт feature-gap-from-category-leaders находит, каких фич у тебя нет — это другая задача. Этот разбор берёт одну конкретную фичу и извлекает паттерны реализации из наблюдения за продуктами, которые сделали её хорошо. Результат — твой осознанный архитектурный выбор, а не копирование чужого дизайна.

Фича: {{feature}} Продукты для разбора: {{reference_products}}

1. Как выбрать правильные референсы

Не бери первые попавшиеся конкуренты. Критерии хорошего референса:

• ✓ Фича у них явно проработана — она ощущается быстрой и надёжной
• ✓ Продукт публично рассказывал про архитектуру (engineering blog, конференции, открытый код)
• ✓ Продукт в близком контексте: B2B/B2C, схожий масштаб данных, похожий тип пользователей
• ✓ Есть open-source аналог — можно посмотреть исходники
• ✗ Не бери продукт только потому что он большой — Facebook и Twitter решали задачи при миллиарде пользователей, у тебя другой контекст
• ✗ Не бери больше 5 продуктов — глубина важнее широты

Составь список: Продукт / Почему выбрал / Источники для изучения

2. Разбор каждого продукта: UX-поток по шагам

Для каждого из {{reference_products}} пройди фичу вручную и опиши пошагово.

2.1 Все состояния интерфейса

Составь таблицу состояний — не пропускай ни одного:

2.2 Микровзаимодействия

Проверь и запиши каждый из них:

• Клавиатура: какие хоткеи работают? Tab/Enter/Escape? Стрелки?
• Фокус: куда переходит фокус после действия? Возвращается ли при закрытии?
• Latency: как быстро реагирует UI? Есть ли анимация-плейсхолдер?
• Оптимистичные обновления: обновляется UI до ответа сервера? Откатывается ли при ошибке?
• Debounce/throttle: есть ли задержка перед запросом при вводе? Сколько миллисекунд?
• Прокрутка: сохраняется ли позиция? Infinite scroll или пагинация?

2.3 Предполагаемая модель данных

По поведению UI выведи вероятную структуру данных:

// Что хранит один элемент списка?
type Item = {
  id: string;
  // какие поля необходимы для отображения в списке?
  // какие подгружаются только при открытии детали?
};

• Что приходит в первом ответе, что — лениво?
• Видно ли cursor/token пагинации в URL или ответах?
• Есть ли признаки денормализации (дублирование данных для скорости)?

3. Сигналы из DevTools → вероятные паттерны

Открой DevTools Network и Performance на {{reference_products}}. Ищи сигналы:

Таблица: сигнал → вероятный паттерн

Что ещё смотреть

• Payload sizes: сколько весит ответ? Есть ли сжатие (gzip/brotli)?
• TTFB: сколько ждёт браузер до первого байта? Кешируется ли ответ на CDN?
• Request patterns: все запросы последовательны или параллельны?
• Prefetch: грузятся ли данные заранее при hover?

4. Матрица сравнения реализаций

Заполни для всех {{reference_products}}. Оставь «?» там, где нет уверенности.

Лучшие решения по каждому аспекту

Для каждой строки матрицы: какой продукт решил лучше всех и почему?

5. Источники для углубления

Перед тем как делать выводы — изучи доступные первичные источники:

• Engineering blogs: найди посты по запросу «[company name] engineering [feature name]»
• Конференции: поищи на YouTube «[company] [feature] architecture» (инженеры часто докладывают на QCon, Strange Loop, re:Invent)
• Open-source аналоги: если фича есть в OSS (Notion → AFFiNE, Figma → tldraw, Linear → Plane) — смотри исходники напрямую
• Публичные ADR / RFCs: GitHub repo → docs/decisions/ или rfcs/
• Changelog / release notes: иногда описывают как переписали реализацию
• Hacker News / Lobste.rs: поиск по домену компании часто даёт треды с инсайдами от авторов

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

6. Синтез: best-of трейдоффы

Теперь, зная как это делают лучшие, ответь на вопросы:

Где есть явный консенсус? Если 4 из 5 продуктов делают одинаково — вероятно, это проверенный паттерн для данной фичи.

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

Что подходит для твоего контекста? Пример: cursor-пагинация лучше для реалтайм-лент, offset — для репортов с фиксированными страницами. Что у тебя?

Что избыточно для твоего масштаба? Не бери решение рассчитанное на 100M пользователей, если у тебя 10K. Overengineering — тоже ошибка.

Anti-patterns

• ❌ Копировать UI пиксель в пиксель — нарушение IP и пустая трата времени; учи паттерн, не внешний вид
• ❌ Смотреть только на крупных игроков — иногда небольшой продукт в твоей нише решил задачу чище
• ❌ Делать выводы без проверки в DevTools — «они наверно используют WebSocket» без открытия Network tab — домыслы, не данные
• ❌ Изучать реализацию без понимания ограничений продукта — у них другой стек, другой масштаб, другие требования к консистентности
• ❌ Скрейпить, декомпилировать или нарушать ToS ради изучения — это незаконно и неэтично; всего достаточно из публичных источников
• ❌ Тратить неделю на исследование перед MVP — один день разбора ключевых референсов достаточно для большинства фич
• ❌ Выбирать паттерн «потому что так делает Google» без анализа контекста — их задача и твоя задача могут не совпадать

7. Output: твой план реализации

На основе разбора сформулируй:

1. Выбранный подход: протокол, пагинация, кеш-стратегия — с явным обоснованием («выбрали cursor pagination, потому что лента обновляется в реалтайм и offset даст gap при вставке»)
2. Архитектурный набросок: компоненты, слои данных, точки интеграции — в ASCII или тексте
3. Все состояния для реализации: перечисли каждое из раздела 2.1 с описанием что делает твой UI
4. Краевые случаи: минимум 5 сценариев из наблюдения за референсами, о которых нужно помнить
5. Модель данных: TypeScript-типы основных сущностей
6. Библиотеки и инструменты: что используешь, чем обосновываешь
7. Последовательность сборки: в каком порядке реализуешь — какое состояние строишь первым, что откладываешь на потом