советы от инженера программного обеспечения Twitter

1656634939 sovety ot inzhenera programmnogo obespecheniya twitter

Чжиа Хва Чонг

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

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

Обновление (24.03.2019): Если вы хотите присоединиться к группе студентов, чтобы узнать больше о дизайне системы, я организую небольшой класс вместе! Вы можете перейти по этой ссылке, чтобы узнать больше, или посетите мой веб-сайт: zhiachong.com для получения дополнительной информации.

SM68D2mI9L-wqSbYcQdRA6Ho5GmhEICbcpmD
Как проектировать систему: советы инженера программного обеспечения Twitter

Эта статья разделена на четыре раздела:

  • Задавайте уточняющие вопросы
  • Используйте свой фон
  • Решайте проблему систематически
  • Ведите свои записи

Задавайте уточняющие вопросы

Основная цель собеседования по проектированию систем состоит в том, чтобы дать возможность кандидату продемонстрировать свои знания.

Нет правильных или неправильных ответов. Вопрос о правильном проектировании системы обычно звучит очень неоднозначно, и причина тому в том, что он должен дать вам шанс продемонстрировать следующее:

  • Как бы вы думали о проблемном пространстве
  • Как вы думаете об узких местах
  • Что вы можете сделать, чтобы устранить эти узкие места.
LEWXpmsTQuJkgv8FjX8L5coOWo-KX0iN4SSjE
Как создать этот черный ящик

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

Одной из самых полезных стратегий, которую я лично использую, является задавать уточняющие вопросы. Спросите ли вы, что такое «хорошие» уточняющие вопросы?

Хороший уточняющий вопрос поможет вам достичь одного или нескольких из нескольких вещей:

  1. Помогает сузить круг того, что вы должны делать
  2. Помогает узнать ожидания пользователя от системы
  3. Дает вам указания, куда продолжать
  4. Информирует вас о возможных узких местах/проблемных областях

В примере с черным ящиком вы можете спросить: «Ну что в ящике? Сколько предметов содержит? И кто целевой пользователь?

На это я мог бы сказать: давайте построим желтую коробку со смайликом, которая будет вмещать максимум 1 теннисный мяч. Однако это не обычный теннисный мяч. Он имеет не менее 0,5 м в радиусе и весит примерно 1 кг. Он предназначен для того, чтобы его обнимали, а не держали, поэтому я не хочу, чтобы на нем были какие-то ручки.

Вот коробка.

UHd2UsV8aRy4tIppyukpJjVfqBz8PlEOKvjG
Моя идеальная коробка со смайликом

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

К примеру, если бы я попросил вас создать Twitter прямо сейчас, как бы вы это сделали? Уделите несколько минут, чтобы подумать об этом, и возможно даже нарисуйте это на листе бумаги. Зайдите как можно глубже и шире, а затем вернитесь в эту статью. А еще лучше, вы можете оставляйте свои заметки в комментариях ниже и мы можем обсудить дальше.

Если вы этого не осознали, конечный результат упражнения, приведенного выше, даст существенно другие результаты. Учитывая мой собственный опыт, я мог бы глубоко углубиться в дизайн API и серверную инфраструктуру. Пожалуй, я бы также исследовал проблемы, связанные с iPhone благодаря своему опыту. Я расскажу о том, как клиент взаимодействует с конечными точками среднего уровня, как будет работать журнал, как я разработаю серверную часть, чтобы обеспечить время безотказной работы и т.д.

Это довольно интересные дискуссии, которые вы можете провести с коллегой, и это очень мощный сигнал, который ищет интервьюер.

Используйте свой фон в своих интересах

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

На самом деле я настоятельно не рекомендую никому делать это по нескольким причинам:

  1. У каждого есть уникальное происхождение. При собеседовании по проектированию систем это возможность для вас продемонстрировать свои сильные стороны. Не упускайте случая, пытаясь понять, чего кто-то другой может ожидать от вас.
  2. Интервьюер, возможно, кивал в ответ на ваши ответы, но он мог знать, что вы просто блефуете, а на самом деле не думаете о проблеме.

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

Сражайтесь с проблемой систематически

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

Когда я работаю над новой системой, я думаю о таких вещах:

  • Какова цель системы?
  • Кто пользователи системы?
  • С каким масштабом мы работаем?
  • Это новая/старая система? Как мы управляем версиями?

Среди других…

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

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

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

Мой разум начал двигаться в разных направлениях:

  • Что делает этот аппарат для заказа кофе?
  • Если я сделаю его, могу ли я продать его Starbucks, или я отмечу его белым и продам как услугу?
  • Сколько пользователей мне нужно поддерживать, если я продам его Starbucks?
  • Как альтернатива, если я отмечу белым ярлыком, могу ли я продать интерфейс моей службе заказа кофе, а затем помочь клиентам создать серверную часть, чтобы они могли хранить заказы на своих локальных машинах?
e-kBkdnLuGBAp4N3Saj9n-DRjxqtRdFOfo2a
Как подойти к этой проблеме

Когда я получу ответы на эти вопросы, я, наконец, смогу составить полную картину того, что делает моя служба заказа кофе. Вот что моя версия сервиса заказа кофе будет выглядеть так:

Моя служба заказа кофе – это программное обеспечение как услуга (SAAS). Он предлагает интерфейс для подключения разных партнеров.

  • Он имеет API, который называется addCoffeeForMerchantкоторый вставляет название кофе, цену кофе и ингредиенты кофе.
  • Он имеет GET API, который называется getCoffeesForMerchantвозвращающий список кофе для определенного идентификатора продавца.
  • Идентификатор продавца – это уникальный идентификатор (UUID), генерируемый с помощью определенного механизма хеширования, который можно дополнительно уточнить с клиентом.
  • Программное обеспечение оптимизировано для операций только для чтения, поскольку большинство моих клиентов создают свое меню один раз и читают его несколько раз в течение дня.
  • В нем есть механизм кэширования, использующий стратегию изгнания наименее используемых (LRU), потому что, если пункт меню не был заказан в течение некоторого времени, моего клиента не волнует, если он немного медленнее появляется в меню.
  • В случае взрыва одного из хранилищ данных моя служба заказа кофе будет копировать данные в разных кластерах на западном и восточном побережье США, поскольку пока я ориентируюсь только на рынок США.

Как альтернатива, любая другая услуга заказа кофе, которую вы можете придумать, также будет очень вероятно. Дело только в том, зачем вы оптимизируетесь. Я думаю, что это очень интересные задачи, и это прекрасное умственное упражнение, чтобы держать свой разум задействованным.

Ведите свои записи

Как инженер-программист, это нескончаемый процесс обучения. Я настоятельно рекомендую вам использовать Evernote или Moleskin для ведения заметок. Лично я ношу небольшой блокнот для быстрых идей, которые мне нужно записывать, и я храню разные другие вещи в Evernote, когда могу.

В моем Evernote есть блокнот под названием Программирование. Каждый раз, когда я сталкиваюсь с чем-нибудь новым или интересным, я нотую это в свой блокнот для дальнейшего использования.

Ежемесячно или ежеквартально я просматриваю и назначаю метки этим новым заметкам, чтобы убедиться, что заметки упорядочены. К примеру, у меня есть метка «Дизайн» для всего, что касается проектирования системы. Это может быть что-то вроде ссылки на видео YouTube, которое мне показалось интересным, или интересный аргумент, выдвинутый моим коллегой, о котором я не подумал.

Это образец того, как выглядит одна из моих заметок:

6i-NhLaPztQuLHNblUqbFPFr24qL-TKZYaYm
Извините за плохую грамматику и опечатки :p

Одна из вещей, которые я недавно узнал от своего коллеги, состоит в том, что NoSQL отлично подходит для создания прототипов, потому что нет необходимости проходить обсуждение схем с другими командами. Если бы я хотел изменить схему, я мог бы сделать это очень быстро с помощью базы данных NoSQL. Это был ключевой опыт работы, который я вставил в блокнот «Программирование».

Я разделяю свои заметки на:

  1. Конструкции систем
  2. Собеседование (опыт + обзор различных собеседований, которые я имел в прошлом, сгруппированы по названию компании)
  3. Случайные мелочи, полезные сведения о CS, например полезные сценарии bash или приемы командной строки
  4. Чтение / Видео на YouTube

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

Как и все, кто знает меня на личном уровне, я не очень организованный человек. Таким образом, я собрал только возможно 10-15% вещей, так что осталось еще многое сделать.

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

Рекомендуемые ресурсы

Intro to: Architecture and Systems Designs – отличный учебник на Youtube от бывшего инженера Facebook о том, как подходить к проблемам проектирования систем.

Разработка приложений с интенсивным использованием данных – еще один хороший ресурс, чтобы научиться проектироваться для масштаба. В нем рассказывается о разных вещах, которые типичный инженер программного обеспечения воспринимает как должное — как работают базы данных (mySQL и noSQL), когда использовать каждую, плюсы и минусы различных методов обработки масштаба и т.п. Я очень рекомендую это?

Имитационные собеседования. Смоделированная среда, имитирующая реальное собеседование, чрезвычайно полезна для подготовки к собеседованиям. Если вы найдете друга, который сделает это за вас, я настоятельно рекомендую. Я также провожу имитационные собеседования, поэтому если вы заинтересованы, не стесняйтесь связаться со мной на zhiachong.com!

Что должен знать каждый разработчик программного обеспечения об объединяющей абстракции данных в реальном времени – очень долгая и техническая дискуссия о журналах, компромиссах. Я еще не кончил его, но коллега очень рекомендует его.

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

Блокнот Moleskin – мне очень нравится. Качество его очень высокое. Цена немного выше, но поскольку я пользуюсь ею каждый день, я считаю это хорошей инвестицией. Держа в руках красивый блокнот каждый день, я испытываю большее желание писать новые заметки.

Pilot G2 (черный) – лучшие ручки, которые я когда-либо использовал и единственные ручки, которыми я буду пользоваться. Я покупаю их оптом на Amazon и держу их всюду. У меня одна в рюкзаке, одна в офисе и одна в домашнем офисе, чтобы у меня всегда была ручка. Он отлично пишет, чернила текут гладко, и мне просто нравится писать им. В сочетании с Moleskin иногда я просто хочу взять G2, чтобы записывать там случайные вещи, потому что эти два идеальны вместе.

Grokking the System Design Interview – Это интервью поступило как рекомендация друзей. Это онлайн-курс, подробно обучающий проектировать распределенную систему. Однако курс стоит 79 долларов. Имеется командная цена. Если есть интерес, я уточню у них, возможно ли сформировать группу для групповой скидки.

Следите за мной в Twitter, Facebook и LinkedIn. Подпишитесь на мой список рассылки, куда я регулярно посылаю советы, подсказки и знания отрасли.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *