「このウェブサイト/アプリをどのように構築しますか」インタビューの質問に対する一般的な思考プロセス[終了]

「フォトアルバムアプリケーションの設計方法を説明する」、「この特定のWebサイトのこの特定の機能を設計する方法を説明する」などのインタビューの質問を収集しましたブラックジャックの）。次に、このものが何百万ある場合はどうなりますか？何を変えますか？

これは、データベーススキーマまたはクラス定義の束（またはその両方）を想定しているようです。私は学校でデータベースについて学んだことがありますが、実際にアプリケーションを設計したことがなく、どこから始めればよいか、思いついた設計が「良い」かどうか、スケーラブルにするために何を変更できるかがわかりません。

これらのシステムを設計するとき、一般的なアプローチまたは思考プロセスはありますか？そして、私が回避しようとする必要がある設計で多くのように思われる一般的な問題/問題？誰かが私にこれらの1つ（または好ましくはすべて、それぞれのニーズを比較しながら）を見て、説明することができますか？

1）どのエンティティが必要かをどのように思い付きますか？2）すべての関係をどのように決定しますか？3）パフォーマンスの最適化を設計にどのように組み込みますか？4）クラスまたはデータベースを使用してこれを行いますか？違いがありますか（つまり、実際にデータベーステーブルに変換できないクラスがあるでしょうか？）

私が質問している主な理由は、「コーディングインタビューをクラックする」ことを行っていたためであり、私の答えは著者のものとは完全に異なっていたためです。

私の試み： 写真共有アプリを使えば、クラスとテーブルが必ずあります：写真とユーザー。

次に、スキーマを作成しようとしている場合、写真の各人が写真にリンクされていると仮定すると、写真とユーザーをリンクするテーブルがあると思います（このテーブルは必要ですか？そうでない場合でも、それはまだ一般的な習慣ですか？多対多のリレーションシップ用に別のテーブルを作成するかどうか）。

しかし、オブジェクト指向のアプローチをとろうとしている場合は、代わりに、すべての作業を実行し、他の2つのテーブル/クラスからのすべての情報を保持するalbumというクラスを用意します。これは私が本で気づいた1つのことです-クラスの束があり、基本的にすべての情報を持ち、他のクラスを接続する1つのクラス-これは一般的ですか？たとえば、上記の私の例では、これは適用されるように見えますか？

現時点では、大規模システムの優れたアーキテクチャがどのように見えるかを知る方法がわからないため、いくつかの一般的なルール/ガイドラインに従うことを望んでいます。

このような質問のポイントは、ソフトウェアアプリケーションを作成する実際のスキルがあるかどうかを評価することです。いくつかの理論を学びましたが、理論的な知識はこれまでにしか得られません。ソフトウェア開発を真に理解する唯一の方法は、それを実行することです。

「どのエンティティが必要ですか？」などの質問に対する一般的な回答がないため、これへの近道はありません。代わりに、さまざまなツールとパラダイムの経験とそれらがどのように連携するかを適用して、目前の問題に対する実用的な解決策を考え出す必要があります。

「クラスやデータベースを使用してこれを行いますか？」などの質問 物事とは何か、そしてそれらがどのように機能するかについての基本的な知識が不足していることを示唆しています。 クラスは、コードを整理するためのパラダイムです。データベースはデータストレージの方法です。これらは本質的に無関係な2つの概念です（ただし、連携することはできます）。これはどちらかまたは両方の質問ではありません。

私は厳しいと言うつもりはありませんが、そのような就職の面接で成功するためには、あなたのコーディング経験を開発する必要があると思います。確かに可能性があります。写真共有アプリについての議論には正しいアイデアがあり、正しい方向に向かっています。しかし、これが実際にどのように機能するかを学ぶ必要があります。インタビューの準備をする最良の方法は、最初から最後まで実際にアプリケーションを作成することです。写真共有アプリは適切なサイズのプロジェクトになりますが、別のアプリを選択することもできます。すべての部分がどのように連携して動作するアプリケーションを作成できるかを見ると、知識は本当に広がります。

これは、データベーススキーマまたはクラス定義の束（あるいはその両方）を期待しているようです。

ここでは詳細に集中しすぎていると思います。その質問で、リクルーターはあなたが書くすべてのクラスの完全な説明を期待していません（そうでなければ、彼らはあなたにそれについて話すのではなく、それをコーディングするように頼むでしょう）。

あなたの最初の答えは、全体像-アーキテクチャ、階層、レイヤー、さらにはプロジェクトのライフサイクルや開発プロセスなどです。答えを調整するために、アプリケーションが実行されるはずの要件と環境について質問することをheしないでください。dan1111が指摘したように、正しいアプリケーション設計のための一般的なレシピはありません。すべてのデザインはコンテキストに依存しています。

リクルーターが本当に具体的な質問をし始めた場合にのみ、内部で使用するクラス、エンティティ、またはデータベーステーブルの詳細を確認する必要があります。

また、経験が少ない場合は、「これまでに教えて使用したタイプのアプリケーション設計を使用してソリューションを紹介します。これと他のアプローチを知っています。大規模ではありますが、実際にそれらを適用したことはありません。他の人を発見して適用することもできます。」

ツールボックスには非常に多くのツールしかないため、経験を積むことができることを認めることには何の問題もありません。実際、実際にどのように機能するのかわからないリハーサルされた答えを吐き出すよりはましです。

私はあなたの最初の質問について簡単にコメントしたいと思いました。

1）どのエンティティが必要かをどのように思い付きますか？

新しいプロジェクトのために私が最初に行うことは、ホワイトボードまたは大きな空白の紙の上で、私と私のチームが考えることができるその特定のプロジェクトに関するすべての物理的および概念的なことを書き留めることです。それはブレインストーミングセッションです。

名詞はオブジェクトになる傾向があり、動詞はユースケースまたはメソッドになる傾向があります。

物理：写真（明らかです！）、表示タイプ、システム、写真ファイル、ファイル形式、ユーザー、日付....
概念：追加、削除、保存/保存、取得、並べ替え、変更、表示/表示...

名詞と動詞を結び付けます。ユーザーが写真を追加します。（まあ-ユースケースがあります！）

また、UMLとデザインパターン、およびそれらを汎用OODでどのように使用できるかを検討することをお勧めします。（注意-上記の言語やデータベースについては言及していません。言語を選択してからOODを実行しないでください。OOLで設計を実装できるようにOODを実行してください。