特定のケースを解決するよりも一般化されたソリューションを好む場合
プログラミングでは、選択肢に直面することがよくあります。考えられる各ユースケースを個別にカバーするか、一般的な問題を解決します。
当面の問題を解決する方が速いことは明らかですが、一般化されたソリューションを作成すると、将来的に時間を節約できます。
ケースの有限リストを試してカバーするのが最適な場合、またはすべての可能性をカバーする汎用システムを作成するのが最適な場合はどうすればわかりますか？
まず、塩を渡します。次に、コショウを渡します。次にすりおろしたパルメザンチーズを渡します。この時点で、一般的な調味料通過システムの開発を開始するのに十分な経験があります。
これはソフトウェアプロジェクトでも同じように機能します。一般化されたシステムへの学習ステップとして開発した特殊用途システムを使用するので、汎用システムを開始するときは、何を構築しているかに自信が持てます。あなたのベルトの下にいくつかの特別な目的のシステムがあります。
ケースの有限リストを試してカバーするのが最適な場合、またはすべての可能性をカバーする汎用システムを作成するのが最適な場合はどうすればわかりますか？
経験。
知る唯一の方法は、以前に1つのパスを試したことがあり、それがどのようにしてお尻に噛まれたか（または、たくさんの時間を無駄にしたか）を見たことです。お尻に噛み付くまで繰り返します。
それでも、あなたは実際には知っていません;あなたはより良い推測をしています。
dasblinkenlight および Paddy3118 からの回答に基づいて、実装する複数のケースがない場合は、一般化する必要はありません！ XKCDの漫画がおかしいのは、大騒ぎが早すぎる一般化であるためです。ソルトを渡すように求められると、目に見えないキャラクターはすぐに「任意の調味料を渡すシステムを開発する」ためにジャンプします。これは開発者にとっては良い冗談です。私たちはみな、時期尚早な汎化の事例を見てきました。
時期尚早な一般化に反対する原則は [〜＃〜] yagni [〜＃〜] （あなたはそれを必要としないでしょう）です。これについてはWebで入手できる資料がたくさんありますが、YAGNIは基本的に、複数のユースケースが実際に表示されない可能性を含め、実際のユースケースの利点なしに一般化する際の多くのリスクを指摘しています。あるいは、もっと微妙に言えば、実際のユースケースが不足しているため、将来何が必要かについて想定する必要があります。これらの仮定は正しくない場合があり、多くの場合、正しくありません。
小さい方が一般的である方が簡単なようです。つまり、任意の型のペアを処理するreasonable辞書クラスを作成できる場合は、整数を文字列にマップするルックアップテーブルを処理するクラスを作成しないでください（ここで、最初のタイプは、いくつかのタイプの比較をサポートしています）。
以前の人生では、連続した材料のウェブを処理する機械のために、多くの産業オートメーションプロジェクトを行っていました。鋼、アルミニウム、紙、プラスチック、...一端で展開し、途中で何か有用なことを行った後、もう一方の端で再度展開します。ある業界では、「アンワインダー」ではなく「ペイオフリール」から始めます。間違った用語を使用すると、クライアントの何百万ドルという目線でばかになります。あるプロジェクトから次のプロジェクトへの再利用のためにabstractedがどれほど少ないかに驚くことでしょう。 OTOH、多くの場合、出発点としてフレームワークまたはテンプレートを作成できます。目前の仕事に合わせてカスタマイズされますが、少なくとも以前のプロジェクトから学ぶという利点がありました。そして、チームの誰もが私たちがどこから始まっているのかを知っていました。
1回、2回、3回、一般化します。
一、二、たくさん！
2番目のケースでは、一般化について考える必要があります。 3番目を要求されたら、それを一般化されたコードから提供し、以前個別に解決された最初と2番目のケースをテストケースとして使用する必要があります。