特定のケースの解決よりも一般化されたソリューションを好む場合

プログラミングでは、考えられる各ユースケースを個別にカバーするか、一般的な問題を解決するという選択肢に直面することがよくあります。

差し迫った問題を解決する方が速いことは明らかですが、一般化されたソリューションを作成すると、将来の時間を節約できます。

有限のケースのリストをカバーしてカバーするのが最善であるか、またはすべての可能性をカバーする汎用システムを作成するのが最善であるかをどのようにして知ることができますか？

まず、塩を渡します。その後、あなたはコショウを渡します。次に、すりおろしたパルメザンチーズを渡します。この時点で、一般的な調味料受け渡しシステムの開発を開始するのに十分な経験があります。

ソフトウェアプロジェクトでも同じように機能します。一般化されたシステムへの学習ステップとして開発した特殊な目的のシステムを使用します。そのため、汎用システムを開始するとき、構築しているものにより自信が持てます。ベルトの下にいくつかの特別な目的のシステムがあります。

有限のケースのリストをカバーしてカバーするのが最善であるか、またはすべての可能性をカバーする汎用システムを作成するのが最善であるかをどのようにして知ることができますか？

経験。

知っている唯一の方法は、以前に1つのパスを試してみて、それがどのようにロバに噛まれたのかを見たことです（または、多くの時間を無駄にしました）。あなたがお尻に少し入るまで繰り返します。

それでも、あなたは本当に知りません。あなたはより良い推測を持っています。

dasblinkenlightとPaddy3118からの回答に基づいて構築するために、実装する複数のケースがない場合、一般化する必要はありません！XKCD漫画がおかしいのは、それが時期尚早の一般化を暴行するからです。塩を渡すように頼まれると、目に見えないキャラクターはすぐに「任意の調味料を渡すためのシステムの開発」に跳ね上がります。これは開発者にとっては良い冗談です。なぜなら、私たちはみな時期尚早の一般化の事例を見たことがあると思うからです。

時期尚早の一般化に反対する原則は、YAGNI（You Ai n't Gonna Need It）です。これに関する多くの資料がウェブ上で入手可能ですが、基本的にYAGNIは、複数のユースケースが実際に現れない可能性を含む、いくつかの実際のユースケースの利益なしに一般化する際の多くのリスクを指摘しています。または、より微妙に、実際のユースケースの欠如は、将来必要なものについて推測することを必要とします。これらの仮定は正しくない場合があり、多くの場合は正しくありません。

小さなものでジェネリックになりやすいようです。つまり、任意のタイプのペアを処理する妥当な辞書クラスを作成できる場合（最初のタイプがいくつかのタイプをサポートする場合、比較）。

前世では、材料の連続ウェブを処理する機械の産業オートメーションプロジェクトを数多く行いました。スチール、アルミニウム、紙、プラスチック、... 一端で展開し、途中で何か有用なことを行った後、もう一端で再びロールアップします。ある業界では、「巻き戻し機」ではなく「ペイオフリール」から始めます。間違った用語を使用する場合、あなたはクライアントの数百万ドルの目でばかです。あるプロジェクトから次のプロジェクトに再利用するために抽象化できるものがほとんどないことに驚くでしょう。OTOH、多くの場合、出発点としてフレームワークまたはテンプレートを作成できます。手元の仕事に合わせてカスタマイズすることもできますが、少なくとも以前のプロジェクトから学ぶという利点がありました。そして、チームの全員が私たちの出発点を知っていました。

1回、2回、3回、一般化してください。

1、2、多く！

2番目のケースでは、一般化について考える必要があります。3番目を要求されたら、それを一般化コードから提供し、以前に個別に解決した最初と2番目のケースをテストケースとして使用する必要があります。