Загальна думка для запитань інтерв'ю "Як ви створили цей веб-сайт / додаток" [закрито]

Я зібрав купу запитань щодо інтерв'ю на кшталт "Опишіть, як би ви створили додаток для фотоальбому", "Опишіть, як би ви створили цю особливість цього конкретного веб-сайту" (наприклад, подобається у Facebook, рекомендація щодо Amazon, кошик для покупок, гра чорного джека). Тоді, що робити, якщо цієї речі є мільйони? Що б ти змінив?

Схоже, це або очікування схеми бази даних, або купа визначень класу (або обох?). Я дізнався про бази даних у школі, але я ніколи раніше не розробляв програму і раніше не стикався з тим, з чого почати, чи "дизайн", який я придумав, "хороший" і що я можу змінити, щоб зробити його масштабованим.

Чи існує загальний підхід або процес думки при проектуванні цих систем? І загальних питань / проблем, які, здається, виникають у дизайні, чого я повинен намагатися уникати? Може хтось, можливо, провів мене через один (або, бажано, всі), порівнюючи потреби кожного) та пояснив:

1) Як ви придумаєте, які сутності потрібні? 2) Як ти вирішуєш, які стосунки матиме все? 3) Як ви включите оптимізацію продуктивності у свій дизайн? 4) Чи роблю це за допомогою класів чи баз даних? Чи має це значення (тобто, чи маю я клас, який насправді не можна перекласти в таблицю бази даних, наприклад?)

Основна причина, про яку я запитую, - це те, що я переживав "Інтерв'ю з розбиттям кодування", і мої відповіді були абсолютно різними від авторських - у мене були дуже різні уявлення про те, які класи важливі.

МОЕ ЗАРАЗ: За допомогою програми для обміну фотографіями я б точно розмістив класи / таблиці: Фото та Користувач.

Тоді я думаю, що якщо ми намагаємося створити схему, то буде таблиця, що поєднує фотографію та користувача, якщо ми припускаємо, що кожна людина на фотографії пов’язана з фотографією (чи потрібна ця таблиця? Якщо ні, чи це все-таки звичайна практика мати окрему таблицю для стосунків багато-багато чи ні?).

Але якщо ми намагаємося застосувати об'єктно-орієнтований підхід, можливо, замість цього у нас був би клас, який називається альбомом, який виконує всю роботу і містить всю інформацію з двох інших таблиць / класів. Це одне, що я помітив у книзі - є купа класів, а потім один клас, який в основному має всю інформацію та з'єднує інші класи - це загальне явище? Наприклад, у моїх вище прикладах, здається, це застосовується?

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

Сенс таких питань полягає в оцінці того, чи володієте ви реальними навичками написання програмного забезпечення. Ви засвоїли деяку теорію, але теоретичні знання можуть зайти лише далеко. Єдиний спосіб по-справжньому зрозуміти розробку програмного забезпечення - це зробити.

Немає ярлика до цього, оскільки немає запасних відповідей на питання типу "які суб'єкти потрібні?" Натомість ви повинні застосувати свій досвід різних інструментів та парадигм, а також те, як вони працюють разом, щоб придумати практичне вирішення проблеми.

Питання типу "Чи роблю це за допомогою класів чи баз даних?" говорить про те, що вам не вистачає базових знань про те, що є і як вони працюють. Заняття - парадигма організації вашого коду; бази даних - це метод зберігання даних. Вони є двома спорідненими між собою поняттями (хоча вони можуть працювати разом). Це не те / або питання.

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

Схоже, це або очікування схеми бази даних, або купа визначень класу (або обох?)

Я думаю, що ти занадто зосереджений на деталях тут. З цим питанням рекрутер не очікує повного опису всіх класів, які ви написали (інакше вони попросять вас його кодувати, а не говорити про це).

Ваша відповідь спочатку повинна бути про велику картину - архітектуру, яруси, шари, навіть життєвий цикл проекту та процес розробки, який ви б створили. Не соромтеся ставити запитання щодо вимог та оточення, на яке має працювати програма, щоб змінити вашу відповідь. Як зазначав dan1111, загального рецепту правильної конструкції програми немає. Усі дизайни залежать від контексту.

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

Крім того, якщо у вас мало досвіду, нормально сказати "Я покажу вам рішення, використовуючи тип дизайну додатків, якого я навчав і використовував до цих пір. Я знаю про це та про інші підходи, які я можу описати вам у великій мірі, але ніколи насправді їх не застосовували. Я також відкритий для відкриття та застосування інших ".

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

Я подумав, що я швидко прокоментую ваше перше запитання:

1) Як ви придумаєте, які сутності потрібні?

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

Іменники, як правило, є предметами, дієслова, як правило, вживають відмінки або методи.

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

Складіть зв’язки між іменниками та дієсловами. Користувач додає фотографію. (Ну - є випадок використання!)

Я б також запропонував переглянути UML та шаблони дизайну та те, як їх можна використовувати в загальних OOD. (Зверніть увагу - я ніде не згадував мову або базу даних. Ніколи не вибирайте мову, а потім робіть OOD. Зробіть свій OOD таким чином, щоб дизайн може бути реалізований будь-яким OOL.