Общий процесс обсуждения вопросов «Как бы вы построили этот сайт / приложение» [закрыто]

Я собрал кучу вопросов для интервью, таких как «Опишите, как вы будете разрабатывать приложение для фотоальбома», «Опишите, как бы вы разработали эту особенность данного веб-сайта» (например, лайки в Facebook, рекомендации по Amazon, корзина покупок, игра Блэк Джек). Тогда, что, если есть миллионы этой вещи? Что бы вы изменили?

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

Есть ли общий подход или мыслительный процесс при проектировании этих систем? И общие проблемы / проблемы, которые, кажется, часто возникают в дизайне, которых я должен стараться избегать? Может, кто-нибудь проведет меня через один (или, предпочтительно, все, сравнивая потребности каждого) из них и объяснит:

1) Как вы придумываете, какие сущности нужны? 2) Как вы решаете, какие отношения у вас будут? 3) Как вы включаете оптимизацию производительности в свой дизайн? 4) Я делаю это, используя классы или базы данных? Имеет ли это значение (например, есть ли у меня класс, который не может быть переведен, например, в таблицу базы данных?)

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

МОЯ ПОПЫТКА: С приложением для обмена фотографиями у меня были бы классы / таблицы: Фото и Пользователь точно.

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

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

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

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

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

Вопрос типа «Делаю ли я это с помощью классов или баз данных?» предполагает, что вам не хватает базовых знаний о том, что есть вещи и как они работают. Классы - это парадигма организации вашего кода; Базы данных являются методом хранения данных. Это две принципиально не связанные концепции (хотя они могут работать вместе). Это не вопрос и / или вопрос.

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

Похоже, что это либо ожидание схемы базы данных, либо набор определений классов (или оба?)

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

Прежде всего, ваш ответ должен касаться общей картины - архитектуры, уровней, уровней, даже жизненного цикла проекта и процесса разработки, который вы бы реализовали. Не стесняйтесь задавать вопросы о требованиях и среде, в которой должно работать приложение, чтобы скорректировать свой ответ. Как указывал dan1111, нет общего рецепта для правильного дизайна приложения. Все проекты зависят от контекста.

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

Кроме того, если у вас мало опыта, нормально говорить: «Я покажу вам решение, используя тот тип разработки приложений, которому меня учили и использовали до сих пор. Я знаю об этом и других подходах, которые я могу описать вам». в целом, но никогда не применял их. Я также открыт для обнаружения и применения других ".

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

Я подумал, что я бы быстро прокомментировал ваш первый вопрос:

1) Как вы придумываете, какие сущности нужны?

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

Существительные, как правило, являются объектами, глаголы, как правило, падежами или методами.

Физическое: фотография (очевидно!), Тип отображения, система, файл фотографии, формат файла, пользователь, дата ....
Концептуальное: добавить, удалить, сохранить / сохранить, получить, отсортировать, изменить, просмотреть / отобразить фотографию ....

Сделайте связь между существительными и глаголами. Пользователь добавляет фото. (Ну, есть вариант использования!)

Я также предложил бы взглянуть на UML и шаблоны проектирования и на то, как их можно использовать в общем OOD. (Обратите внимание: я не упомянул ни язык, ни базу данных выше. Не выбирайте язык, а затем выполняйте OOD. Выполните OOD таким образом, чтобы дизайн мог быть реализован любым OOL.