Рамка проектирования
Повторяемая мыслительная рамка для любой задачи проектирования: прояснить требования, оценить масштаб, набросать высокоуровневый дизайн, углубиться в трудные части, найти узкое место и проговорить каждый компромисс вслух. Это леса для рассуждения под давлением, а не скрипт.
Поставь двух инженеров перед одной и той же пустой доской и скажи «спроектируй ленту новостей». Один цепенеет, затем начинает рисовать коробки — сервер сюда, базу туда — и через двадцать минут получает клубок, который что-то делает, ни для кого конкретно, ни на каком конкретном масштабе. Второй говорит: «Дай убедиться, что я понимаю, что мы строим, потом я это просчитаю, потом наброшу, а потом мы копнём в ту часть, которая реально сложна». Второй не умнее. У него есть рамка — фиксированная последовательность, которую он прогоняет каждый раз, — так что пустую доску никогда не приходится встречать с нуля. Рамка — это разница между «отыграть» и «барахтаться». К концу урока у тебя будет та же самая последовательность — шесть стадий, которые можно пройти под давлением, на любой системе, не застревая.
Зачем вообще рамка
Прошлый урок задал рассуждение — от требований к узким местам и к компромиссам. Рамка — это то же рассуждение, превращённое в упорядоченную, повторяемую процедуру, чтобы ты мог исполнить его под давлением, на незнакомой задаче, не забыв ни шага. Опытные проектировщики не импровизируют порядок; они интернализировали один и идут по нему осознанно. Ценность не в коробках, которые ты рисуешь, — а в том, что ты никогда не застреваешь, никогда не оптимизируешь до того, как просчитал размер, и никогда не заканчиваешь, не назвав, чем пожертвовал.
В рамке шесть стадий. Они в основном последовательны, но ты постоянно возвращаешься: число, оценённое на стадии 2, может отправить тебя назад переуточнять требование на стадии 1.
Шесть стадий
-
Прояснить требования — функциональные и нефункциональные. Функциональные: что система делает? («запостить твит», «загрузить ленту», «поиск»). Нефункциональные (NFR): насколько хорошо? — цели по задержке, доступность, ожидания по консистентности, надёжность хранения, соотношение чтений/записей. NFR — где живёт бо́льшая часть давления на дизайн; «лента должна загружаться менее чем за 200 мс на p99 (99-й перцентиль — самые медленные 1% запросов)» формирует архитектуру куда сильнее, чем «показать твиты». Явно зафиксируй границы: что входит, и не менее важно — что не входит.
-
Оценить масштаб (на салфетке). Преврати требования в числа: активных пользователей в день, запросов в секунду (пик, не среднее — пики часто в 2–5× выше среднего), рост хранилища за год, полосу. Ты ищешь не точность; ты ищешь порядок величины, который скажет, влезает ли это в один сервер или нужен флот. 100 RPS и 1 000 000 RPS — это разные системы, и компоненты не выбрать, пока не знаешь, в какой из них ты.
-
Высокоуровневый дизайн. Теперь набросай крупные компоненты и поток данных между ними — клиенты, балансировщик, серверы приложений, хранилища, кэши, очереди. Держи это грубо. Цель — диаграмма, которая очевидно удовлетворяет функциональным требованиям и на которую можно показывать, рассуждая о нефункциональных.
-
Углубиться в трудные части. В любом дизайне есть одна-две по-настоящему сложные части; остальное — обвязка. Трать время там. Для ленты это fan-out (веерная рассылка записи всем подписчикам; push — сразу при записи, pull — при чтении). Для ограничителя частоты — алгоритм подсчёта и где живёт счётчик. Идти вглубь в трудную часть — а не в лёгкую — самый чёткий сигнал сеньорности.
-
Определить узкое место. При заявленном масштабе какой ресурс сдаст первым — горячая партиция БД, единственный координатор, ёмкость кэша, исходящий сетевой трафик? Назвать его явно — то, что позволяет масштабировать нужное, а не удобное, и это прямо вытекает из чисел стадии 2.
-
Проговорить компромиссы вслух. Для каждого значимого выбора скажи, что купил и чем заплатил: «push-fan-out ради мгновенных чтений, платой — дорогие записи и проблема знаменитостей». Дизайн, перечисляющий свои компромиссы, защитим; тот, что притворяется, будто состоит из одних побед, — нет.
Вместе эти шесть стадий гарантируют: ты никогда не оптимизируешь до того, как понял задачу; никогда не рисуешь до того, как просчитал масштаб; и никогда не заканчиваешь, не назвав, чем пожертвовал. Пропустишь стадию 2 — диаграмма на стадии 3 строится на вымысле; пропустишь стадию 6 — всё упражнение сводится к схеме без обоснования.
Рамка — это леса, а не скрипт
Опасность — относиться к шести стадиям как к чек-листу для зачитывания. Рамка — это леса для рассуждения, а не его замена. Зачитывать «теперь я оценю масштаб», выдавая числа, которые никогда не используешь, — театр. Стадии существуют, чтобы твоё мышление покрыло нужную почву в нужном порядке — проясни до того, как строить, просчитай до того, как выбирать, иди вглубь там, где трудно, и никогда не прячь компромисс. Интернализируй последовательность, пока не перестанешь её замечать, как беглый говорящий перестаёт замечать грамматику.
▸Частая ошибка
Самый частый провал — прыжок сразу на стадию 3: рисовать коробки до прояснения требований или оценки масштаба. Это кажется продуктивным, потому что на доске появляется что-то конкретное, но ты уже закоммитился на архитектуру под масштаб, который не установил, решая задачу, границы которой не задал. Второй по частоте провал — обратный: так долго полировать высокоуровневую диаграмму, что ни разу не углубиться в единственную реально трудную часть, оставив интервью (или реальный дизайн-док) с красивой картинкой и без доказательств, что ты справишься со сложностью. Проясняй первым; иди вглубь в трудную часть; оба провала — от неверного порядка.
▸Почему это работает
Почему оценивать масштаб до высокоуровневого дизайна, а не после? Потому что масштаб определяет, какие компоненты вообще допустимы. При 100 RPS и нескольких ГБ данных один инстанс Postgres и сервер приложений — не просто приемлемо, это правильный, простейший ответ, а тянуться за шардированием или очередью сообщений было бы оверинжинирингом. При 1 000 000 RPS та же диаграмма — нестартёр, и нужны партиционирование, ярусы кэша и асинхронная обработка с первого наброска. Нарисуешь архитектуру до того, как узнал порядок величины, — ты гадаешь, и либо переусложнишь под трафик, которого нет, либо недостроишь под трафик, который есть. Число идёт первым, потому что это ограничение, которому всё остальное обязано удовлетворить.
Кандидата просят спроектировать чат-систему, и он сразу начинает рисовать серверы, базы и очередь сообщений. Какую стадию он пропустил и почему это важно?
Почему рамка ставит «оценить масштаб» перед «высокоуровневым дизайном», а не после?
Шесть стадий — не чек-лист для зачитывания; выдавать числа, которые не используешь, — театр. Рамку лучше понимать как _______ для рассуждения — она следит, чтобы твоё мышление покрыло нужную почву в нужном порядке, но никогда не заменяет само мышление.
- 01Перечисли шесть стадий рамки проектирования по порядку.
- 02Почему «оценить масштаб» обязано идти перед «высокоуровневым дизайном»?
- 03Что значит «рамка — это леса, а не скрипт», и как чаще всего её используют неверно?
Рамка проектирования превращает рассуждение «требования → узкие места → компромиссы» в фиксированную, повторяемую последовательность из шести стадий, которую ты прогоняешь каждый раз, чтобы никогда не встречать пустую доску с нуля: (1) прояснить функциональные и нефункциональные требования — NFR несут бо́льшую часть давления на дизайн; (2) оценить масштаб до нужного порядка величины, ведь 100 RPS и 1 000 000 RPS — разные системы, и число есть ограничение, которому всё остальное обязано удовлетворить; (3) набросать грубый высокоуровневый дизайн; (4) углубиться в трудные части — идти вглубь там, где реально трудно, а не в обвязку, — самый чёткий сигнал сеньорности; (5) определить узкое место, которое подразумевает масштаб; (6) проговорить каждый компромисс вслух, ведь дизайн, прячущий свои цены, не защитим. Стрелки — путь по умолчанию, а не улица с односторонним движением: ты возвращаешься, когда новые числа переоткрывают границы. Относись к рамке как к лесам для рассуждения, а не скрипту для зачитывания; самый частый провал — прыжок на стадию 3 до того, как появились требования и масштаб. Юнит 09 расширяет это в полный фреймворк интервью с таймингом и тактиками коммуникации. Теперь, когда увидишь — или почувствуешь у себя — желание нарисовать первую коробку, не задав ни одного вопроса о масштабе, ты будешь знать: пропущена стадия 1 (а то и 2), и весь дальнейший дизайн висит в воздухе без реального ограничения.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.