Вводное руководство по проектированию систем для разработчиков интерфейсов 👩‍💻

31 марта 2023 г.

Позвольте мне начать с признания - я очень долго боялся собеседований по системному дизайну! Я не дал много из них, но пара, которую я испытал, была нервной. Я также помню, как заканчивал собеседование, чувствуя себя подавленным и неуверенным в себе :disappointed:

После откладывания обучения я, наконец, решил побороть свой страх и серьезно отнестись к этому.

Отсюда и началось мое путешествие по поиску онлайн-материалов — оказалось, что их МНОГО (что меня снова смутило 😵‍💫). Поэтому я обратился к Youtube, чтобы посмотреть несколько вводных видеороликов, прежде чем читать блоги по этой теме.

В конце этой статьи я прикрепил несколько интересных материалов.

Давайте начнем с понимания того, зачем нам нужно знать о проектировании системы.

Почему дизайн системы?

Давайте начнем с того, почему мы, разработчики внешнего интерфейса, вообще должны знать о системном дизайне. Я имею в виду, что система больше похожа на тему бэкенда, а дизайн — это то, о чем должен подумать дизайнер, не так ли? :woman_пожимая плечами:

Нет, к счастью или к сожалению, нет :upside_down_face:

Граница между этими ролями время от времени стирается, и поэтому Frontend-разработчику необходимо знать о разработке масштабируемой и поддерживаемой системы с нуля. Для Frontend-разработчика также было бы очень полезно понимать архитектуру системы, чтобы выявлять в ней проблемы или ошибки до того, как их исправление станет слишком дорогостоящим и трудоемким. Это, в свою очередь, повысит уверенность в производительности и правильности строящейся системы.

<цитата>

Если вы знаете, что происходит внутри, вы с большей вероятностью создадите решения, которые лучше подходят для нужд и ограничений вашей системы.

Следовательно, независимо от вашего опыта, знание системного проектирования сделает вас более всесторонним инженером.

Что такое системный дизайн?

Technopedia описывает это следующим образом:

<цитата>

Проектирование системы — это процесс определения элементов системы, таких как архитектура, модули и компоненты, различные интерфейсы этих компонентов и данные, которые проходят через эту систему.

Раунд системного проектирования может быть описан по-разному в зависимости от профиля работы (бизнес, продукт, дизайн, внешний интерфейс, серверная часть, полный стек), на который вы подали заявку -

• Дизайн системы
• Чувство продукта
• Архитектура пользовательского интерфейса
• Машинное кодирование или проектирование компонентов

Несмотря на то, что их соглашение об именах отличается, их основа одинакова, и они отличаются только областью фокуса.

В целом мы можем разделить дизайн системы на 2 части —

* Высокоуровневое проектирование (HLD) — проектирование полной системы * Низкоуровневое проектирование (LLD) — проектирование конкретного компонента из системы

Цель собеседования по системному дизайну в основном состоит в том, чтобы понять, можете ли вы, как кандидат, визуализировать систему/компонент с нуля. Предполагается, что вы думаете о требованиях, функциях и ограничениях системы.

Я бы рекомендовал следовать приведенному ниже плану, чтобы охватить все необходимые темы -

* Требования (ДВУ) * Объем (ДВУ) * Выбор технологий (HLD) * Компонентная архитектура (LLD) * Детали реализации (LLD)

1) Требования 📝

Это требования вашей системы. Здесь вам следует сосредоточиться на определении возможностей и недостатков вашей системы.

Эту тему можно разделить на 2 части:

* Функциональность. Эти требования в основном соответствуют тому, что явно ожидается от вашей системы. Это будет включать функции и возможности, которые должны быть включены в вашу систему.

Например: веб-сайт электронной коммерции должен иметь авторизацию и аутентификацию для пользователей, добавление товаров в корзину, настроенный платежный шлюз и т. д.

* Нефункциональные. Они состоят из функций, которые явно не запрашиваются, но неявно предполагаются, что ваша система должна быть в состоянии это сделать. Например: совместимость с мобильными/настольными компьютерами, доступность, производительность, отзывчивость/адаптивность, дизайн-система и т. д.

2) Область применения 🔍

Было бы практически невозможно полностью разработать систему за ограниченную продолжительность интервью. Следовательно, эта часть посвящена приоритизации требований и функций, перечисленных в предыдущем разделе. Здесь вы должны сосредоточиться на некоторых из наиболее важных функциональных требований уровня модуля (системный уровень) или уровня функций (уровень компонента). Кроме того, сосредоточьтесь на обязательных нефункциональных требованиях. В дальнейшем это будут требования вашей системы.

3) Выбор технологий ⚒️

Здесь основное внимание следует уделить окончательной доработке инструментов и технологий, с помощью которых будет разрабатываться система. Например: библиотека/фреймворк, управление состоянием, сторонние пакеты, инструменты сборки и т. д.

4) Компонентная архитектура 🗂️

Поскольку этот шаг является частью компонентного или низкоуровневого проектирования, мы должны учитывать иерархию компонентов, структуру папок, совместное использование данных, маршрутизацию и т. д. для нашего конкретного компонента.

5) Детали реализации 🚀

Этот шаг снова фокусируется на уровне компонента и его реализации. Есть определенные темы, о которых вам следует подумать и которые очень специфичны для того типа компонента, который вам предложили разработать.

Например: если вас попросили разработать компонент поиска, вы должны подумать о нумерации страниц/бесконечной прокрутке, денонсировании/регулировании, объекте результатов поиска, хотите ли вы, чтобы ваши данные возвращались через REST или GraphQL, а также о структуре ваших запросов и ответы и т. д.

Здесь следует помнить и о возможности повторного использования вашего компонента (состояние и реквизиты), обработке событий, моделировании данных и структуре API.

Примеры

Для дизайна системы/модуля вас могут попросить сделать дизайн -

• Веб-сайт электронной коммерции, например Amazon
.
• Платформа потокового видео, такая как Netflix
• доска Pinterest

Для разработки компонента/функции вас могут попросить разработать -

• Компонент поиска с вводом текста или автозаполнением
• Платежный шлюз
• Таблица данных

О чем следует помнить

• Обсуждая детали реализации, вы можете использовать фреймворк или Vanilla JS.

* В раунде собеседования по системному проектированию ожидается очень мало или «вообще никакого» кодирования, поскольку цель состоит в том, чтобы выяснить, как вы думаете, и рассматриваете ли вы несколько возможностей, когда думаете о проблеме.

* Чрезвычайно важно думать вслух, делая какие-либо предположения или решения о вашей системе/компоненте

* Не переходите сразу к проектированию системы. Сначала подумайте об этом пару минут, а затем задайте все соответствующие вопросы, прежде чем начинать процесс.

* В случае проектирования высокого уровня основное внимание уделяется системе или модулю. Тем не менее, вы должны упомянуть компоненты или функции, которые вы хотели бы иметь в системе. Но в низкоуровневом дизайне основное внимание следует уделять только компоненту.

* Наконец, всегда относитесь к интервьюеру как к заинтересованной стороне и задавайте вопросы при разработке вашей системы/компонента в случае каких-либо сомнений или путаницы. Всегда лучше спросить, чем предполагать 😉

Я надеюсь, что смог внести некоторую ясность в интервью по системному дизайну и побудить некоторых из вас прочитать об этом больше 💪

Спасибо за прочтение. Удачного взлома и обучения! 🤓

---

Ресурсы для дальнейшего обучения

• Что такое внешний вид системы? Узнайте, как пройти собеседование на стороне клиента
• Интервью о разработке системы внешнего интерфейса | Внешний дизайн системы | 💪Дизайн системы Чакде
• Руководство по проектированию системы для разработчиков интерфейсов

---

Оригинал