Комментарии 21
Спасибо, интересно было почитать.
Позволю высказать свое мнение по данной теме.
Я бы начал с более детального рассмотрения предоставленного юзкейса. И в первую очередь следовало бы ограничить зону ответственности сервиса. Когда границы определены, можно найти уже и стейкхолдеров (в данном случае другие сервисы).
В статье немного размыты границы между функциональными и не функциональными требованиями к системе. Однако на базе юзкейса будет намного легче определить функциональные требования к сервису (кто и что от него хотят, и какие функции он, сервис, должен предоставить, что бы удовлетворить требования).
Нефункциональные же требования, скорее всего на интервью мало чем помогут (разве что для рассуждений на тему выбора технологий и реализации), но уточнять всегда полезно.
Опять же, когда проработали системные функции сервиса, встает вопрос о данных, не о конкретной реализации API, а именно о данных, чем и как обмениваются между собой сервис со стейкхолдерами (другими сервисами, пользователем и тд.).
Ну и далее по списку, на базе функциональной архитекруты, можно подумать о логической архитекруте, что можно в некоторых случаях один к одному перенести на физический уровень (уровень реализации непосредственно софта) и тд.
Читаю статю я задался вопросом, а отчего такой уровень детализации, вроде жизненного цикла данных и расчета количество требуемых процессоров, если речь идет о системной архитектуре. Очень часто смешивание архитектурных уровней ведет к дальнейшему хаосу, и к тому что никто систумную архитектуру больше не учитывает, и тот же Вася берет и просто что то там реализовавает. :)
Хорошо было бы научиться правильно задавать вопросы, чтобы они содержали половину ответа (с контекстом). Например, вопрос "Какие ещё сервисы есть?" задан неправильно. За это всегда минус сознательно или подсознательно. Этот вопрос должен звучать примерно так "Для того, чтобы мне правильно спроектировать взаимосвязи и не дублировать функции, мне необходимо знать существующий состав сервисов с их кратким описанием. Или давайте действовать в режиме предположений об их наличии или отсутствии, а вы меня поправите". То есть не проявлять пассивную агрессию, заставляя работать коллег с неопределенным конечным результатом, а брать руководство процессом в свои руки. Всегда складывается негативное впечатление о тех, кто не начинает сразу работать, а ждёт на вход всё новую и новую информацию, отсутствие которой ему по неизвестным причинам постоянно мешает.
Я понимаю, что эти вопросы для чек-листа и реально они звучать будут в зависимости от навыка красноречия, но ваши компетенции на собесе показывает именно правильная их формулировка: знание - дело наживное, подход к работе и мотивация - гораздо важнее.
Вот из-за того, что статья вышла сегодня, а не вчера, я вчера завалил собес, так как неожиданно на нем всплыл систем дизайн, про который я ни в зуб ногой. ))
Статья ещё и хороша для тех, кому не приходилось заниматься System Design. Позволяет понять, что это.
А вот я не понял... Выходит, что System Designer должен ещё разбираться в различных бизнес-схемах? Так их тысячи... Почему такие статьи всегда привязываются к конкретному примеру, и этот пример практически всегда представляет собой торговую точку в Интернете?
Увы, статья не про System Design, а про прохождение плохих собеседований.
В каком плане плохих? Такое собеседование не проверит квалификацию специалиста?
Угу. Не позволяет определить навыки или компетенции, связанные с реальной выполняемой работой.
Собеседование по SysDesign (в большинстве видов, исключения бывают, но крайне редкие) показывает только умение кандидата читать сомнительные книжки и не слишком задумываться - и больше ничего. Впрочем, может в некоторых компаниях это и является важным критерием отбора...
Есть очень хорошая книга в двух частях. "System Design Interview" Алекса Сью.
В ней автор рассматривает какие вопросы нужно задавать на собеседовании для проектирования highload-сервисов, таких как YouTube, Twitter и т.д.Читать лучше в оригинале, перевод на русский так себе.
Мне она очень помогла на собеседовании - не про конкретный сервис (в книги того, что меня просили задизайнить не было), а то, какие именно вопросы нужно задать и как вообще правильно рассуждать и отвечать на вопросы интервьювера.
Это очень плохая книга. Она подменяет проектирование прохождением собеседований. Если на собеседовании помогает книжка Сью, то это говорит о больших проблемах и у нанимателя и у нанимаемого. Скорее всего, оба уровнем где-то middle, не выше.
И да, проектирование любой реальной системы и близко не похоже на книжку Сью.
А что посоветуете?
Посоветовать для чего?
Что хочется изучить/освоить/понять?
Какие вопросы нужно задавать и как принимать решения по архитектуре.
Если про архитектуру, то стоит читать Фаулера. Про выборы неплохо написано в 'Software Architecture: The Hard Parts' Нила Форда и других.
При этом надо помнить, что в любой книжке процентов 30% - 70% или устарело или просто фигня и смысл книг - в узнавании нового и возможности поспорить с кем-то опытным, но никогда - не готовые советы.
Перед любыми книжками по архитектуре неплохо освоить базу, ту же теорию систем (Акофф, Левенчук, Смирнов - подбирай по вкусу), распределенные системы от Клеппмана и прочие базовые вещи типа сети. Но, освоение базовых умений в проектировании требует минимум лет 8-10 опыта в разных компаниях, довольно много разных книжек, много разных общих знаний - и только потом уже от проектирования будет польза.
Ну и в качестве развлечения можно смотреть доклады на основных конференциях. Верить им нельзя (даже моим), но как увеличение широты и начитанности - полезны.
Ситуация с интеграцией конечно совсем выдуманная. Если ты работаешь в компании, то уже будут неявно известны требования по количеству датацентров, политикам восстановления, протоколам передачи данных, требуемому запасу ресурсов. Более того, в нормальной компании какие-то требования изначально должны быть прописаны.
А с точки зрения бизнеса лучше сначала реализовать MVP, нарисовать макеты и кнопочки, протестировать нагрузку, тогда уже более понятны будут требования по ресурсам железа, прогнозы потребления, дополнительные требования и так далее.
Дисклеймер - я сам тоже довольно много (2 раза в месяц где-то) собеседую народ на system design. Вам фидбэк на статью
1) Зачем там вообще сервис картинок? Это отдельная задача, как картинки отдавать и она уже, очевидно, решена, текущие изображения в маркетплейсе же как-то отдаются.
Я бы сказал это частный анти-паттерн на интервью, когда кандидат начинает уходить в неосновную функциональность и там теряет кучу времени вместо решения основной задачи.
2) Я полностью согласен насчет частой ошибки, когда кандидат начинает сразу рисовать вместо понимания задачи, но у вас он как-то очень долго не рисует. Он к этому времени уже наговорит словами так много, что мне, как интервьюэру, записать это и потом понять будет сложно. Все таки надо переходить сразу к high-level диаграмме после требований, чтобы понять может ли человек хотя бы компоненты идентифицировать. Вы не находите, что у вас получается такая смесь из high-level дизайна с low-level? Не проще нарисовать 2 схемы, а во второй уже отобразить конкретные технологии, API, entities?
3) Сам пример задачи очень простой, все таки на интервью хочется понять уровень, а на простой задаче это не продемонстрировать, нужна задача, как лук, чтобы добавлять разные слои сложности. Вы, кстати, калибрацию вопроса не написали - какой у вас порог прохождения?
Ваш Василий архитектор, да?
Вот замечаю, что крупные компании и на собеседование на системного аналитика одним из этапом проводят System Design Interview. Если взглянуть как один из банков предлагает готовиться https://opensource.tbank.ru/general/career/-/blob/main/interview/sections/system-design-backend.md?ref_type=heads, то становится страшно, а это даже не на архитектора. Вот пара критериев оттуда
Как кандидат понял и прочертил границы системы — а именно что входит и не входит в границы задачи. Характерной чертой хорошо выстроенных границ является понимание основных сценариев работы системы и четко формализованного API.
Как кандидат проработал концептуальную схему. Концептуальная схема состоит из — классов кубиков, из которых состоит система (или Architecture Building Blocks (ABB) из TOGAF) — моделей данных, которые хранятся в этих кубиках и/или путешествуют между ними.
Как кандидат проработал реальную схему. По факту, это выбор для каждого кубика конкретного представителя (или Solution Building Block (SBB) из TOGAF).
А в статье кажется, что как будто и ничего особенного - "Очень красиво делать не надо" "никто не ждёт, что он отобразит весь контекст верно" - как-то не очень верится
Собеседование по System Design: как запроектировать и не потеряться