解決策は可能な限り一般的であるか、可能な限り具体的である必要がありますか？

「タイプ」属性を持つエンティティがあるとします。可能なタイプは20以上あります。

ここで、タイプをA-> Bから変更できるものを実装するように求められます。これは唯一のユースケースです。

したがって、有効なタイプである限り、タイプの任意の変更を許可するものを実装する必要がありますか？または、要件ごとにA-> Bからの変更のみを許可し、B-> AまたはA-> Cなどの他のタイプの変更を拒否する必要がありますか？

両方の長所と短所を見ることができます。一般的な解決策は、将来同様の要件が発生した場合の作業が少なくなることを意味しますが、間違っている可能性が高くなります（ただし、これで発信者を100％制御しますがポイント）。
特定のソリューションではエラーが発生しにくくなりますが、同様の要件が発生した場合、今後さらに作業が必要になります。

優れた開発者は、将来の拡張が容易になるように、変更を予測してシステムを設計する必要があると聞き続けていますが、これは一般的な解決策のように思えますか？

編集：

それほど具体的ではない例に詳細を追加する：この場合の「汎用」ソリューションは、「特定」ソリューションよりも作業が少なくて済みます。特定のソリューションでは、古いタイプと新しいタイプの検証が必要です。新しいタイプのみを検証する必要があります。

私の経験則：

1. 最初に問題が発生したときは、特定の問題のみを解決します（これがYAGNIの原則です）
2. 同じ問題に二度目に遭遇したとき、それが多くの仕事ではない場合、最初のケースを一般化することを検討
3. 一般化バージョンを使用できる3つの特定のケースがある場合、一般化バージョンの実際の計画を開始する必要があります。今では、実際に一般化できるように問題を十分に理解する必要があります。

もちろん、これはガイドラインであり、厳格なルールではありません。本当の答えは、ケースバイケースで最善の判断を下すことです。

同様の要件が必要な場合、特定のソリューション[...]は今後さらに多くの作業を必要とします

私はこの議論を数十回聞いたことがありますが、私の経験からすると、これは間違いであることが定期的に判明しています。今または後で一般化した場合、2番目の同様の要件が発生すると、作業はほぼ同じになります。そのため、一般化に追加の労力を費やす意味はまったくありません。この努力が報われることがわからない場合です。

（明らかに、これは、より一般的な解決策が特定の解決策よりも複雑でなく、労力も少ない場合には当てはまりませんが、私の経験では、これらはまれなケースです。私の答えは約です）。

「2番目の類似ケース」が表示されたら、一般化について考え始めるときです。この2番目の要件は、正しいことを汎用化したかどうかを検証できるシナリオを提供するため、正しく一般化するのははるかに簡単になります。1つのケースだけを一般化しようとすると、暗闇で撮影していることになります。一般化する必要のない特定の事柄を一般化しすぎて、そうすべき他の部分を見逃す可能性が高くなります。そして、2番目のケースが発生し、間違った事柄を一般化したことに気付いた場合、これを修正するためにより多くの作業が必要になります。

ですから、「万が一に備えて」物事を行う誘惑を遅らせることをお勧めします。このアプローチは、3回、4回、またはそれ以上を一般化する機会を逃し、維持するために似たような（重複した）コードの山を持っている場合にのみ、より多くの作業とメンテナンスの努力につながります。

TL; DR：解決しようとしているものによって異なります。

私はこれについてGrampsと同様の会話をしましたが、C＃のFuncとActionがいかに素晴らしいかについて話していました。My Grampsは非常に古いタイマープログラマーであり、ソフトウェアが部屋全体を占有するコンピューターで実行されて以来、ソースコードを使用しています。

彼は人生で何度か技術を変えました。彼はC、COBOL、Pascal、BASIC、Fortran、Smalltalk、Javaでコードを書き、最終的に趣味としてC＃を始めました。IBMのSideKickの青いエディターでコードの最初の行を削りながら、彼と一緒にプログラミングする方法を学びました。20歳になるまでに、外で遊ぶよりもコーディングに多くの時間を費やしていました。

それらは私の記憶のほんの一部ですので、それらを語っているときに正確に実用的でない場合は、すみません。私はそれらの瞬間がいくらか好きです。

それは彼が私に言ったことです：

「問題を一般化するのか、それとも特定の範囲で解決するのか、尋ねますか？それは...質問です。」

グランプスは、一時的にメガネの位置を顔に固定しながら、少し考えて考えました。彼はコンピューターでマッチ3ゲームをプレイし、古いサウンドシステムでDeep PurpleのLPを聴いていました。

「まあ、それはあなたが解決しようとしている問題に依存するだろう」と彼は私に言った。「すべての設計選択に対する単一の神聖なソリューションが存在すると信じがちですが、それはありません。ソフトウェアアーキテクチャはチーズのようなものです。」

「...チーズ、おじいちゃん？」

「お気に入りについて何を考えても構いません。常に臭いがあると思う人がいます」。

しばらく混乱してまばたきしましたが、何か言う前にGrampsが続きました。

「車を作るとき、部品の材料をどのように選ぶのですか？」

「私は...コストと、部品が何をすべきかによると思います。」

「部品が解決しようとしている問題に依存します。スチール製のタイヤや、革製のフロントガラスを製造することはありません。手元にある問題を最もよく解決する材料を選択します。一般的な解決策？それとも特定の解決策？どのような問題に、どのようなユースケースに？一回だけ使用されるコードに最大限の柔軟性を与えるために、完全に機能的なアプローチを採用すべきか？非常に専門的で脆弱なコードを書くべきか？システムの多くの用途と多くの変更、そしておそらく多くの変更を見ることができますか？それらのようなデザインの選択は、車の部品に選ぶ材料や、小さな家を建てるために選ぶレゴのレンガのようなものですどんなレゴブロックが最高のものですか？」

高齢のプログラマーは、続行する前に自分のテーブルにある小さなレゴの列車モデルに手を伸ばしました。

「あなたはそのレンガが必要なものを知っている場合にのみ答えることができます。特定の解決策が一般的な解決策よりも優れているかどうか、どのような問題かわからない場合はどうでしょうか解決しようとしていますか？理解できない選択を過去に見ることはできません。」

「.. マトリックスを引用しただけですか？」

"何？"

「何もしないで。」

「まあ、National Invoice Systemに何かを構築しようとしているとしましょう。その地獄のAPIとその3万行のXMLファイルが内部からどのように見えるか知っています。そのファイルを作成するための「汎用」ソリューションはファイルにはオプションのパラメーターがいっぱいで、特定の事業部門だけが使用すべきケースがいっぱいです。ほとんどの場合、それらを無視しても問題ありません。唯一の場合は、一般的な請求書システムを作成する必要はありません。靴を販売するシステムを作成するだけで、靴を販売するシステムを作成して、最高の靴売りの請求書システムにすることができます。独立した一般的な販売システムとして再販されるたとえば、今では、ガス、食物、またはアルコールにのみ使用されるオプションを実装することは興味深いです。今、それらは可能なユースケースです。彼らはただ、いくつかの仮説的だった前に使用しないでください例を、あなたは実装しない使用しないでください例を。使用しないでくださいは、必要ありませんの弟です。」

Grampsはレゴトレインを元の場所に戻し、マッチ3ゲームに戻りました。

「そのため、特定の問題の一般的な解決策または特定の解決策を選択するには、まずその問題が何であるかを理解する必要があります。それ以外の場合は推測であり、推測はマネージャーではなくプログラマーの仕事です。 ITのすべて、それは異なります。」

だから、あなたはそれを持っています。"場合によります"。これはおそらく、ソフトウェア設計について考えるときに最も強力な2語の表現です。

主に、そのような変更が発生する可能性が高いかどうかを予測しようとする必要があります。

そうでない場合は、通常、今すぐ簡単なソリューションに進み、後で拡張することをお勧めします。必要なものをより明確に把握できる可能性は十分にあります。

あなたが新しいドメインで作業している場合は、ダニエル・プライデンが間違いなく言及した3つの規則を適用する必要があります。結局のところ、あなたがその分野の初心者なら、どのように有用な抽象化を構築することになっていますか？多くの場合、人々は抽象化をキャッチする能力に自信を持っていますが、それはめったにありません。私の経験では、時期尚早な抽象化は、コードの複製と同じくらい悪いことです。間違った抽象化は理解するのが本当に苦痛です。リファクタリングがさらに苦しいこともあります。

開発者が取り組んでいる未知の領域に関する私の論点を扱った本があります。それは、抽出された有用な抽象化を持つ特定のドメインで構成されています。

あなたの質問の本文の性質を考えると、私がそれを正しく理解したと仮定すると、実際には、これは一般的なソリューションと特定のソリューションに関する質問ではなく、中央システム機能の設計上​​の質問と見なされます。

そして、中央システムの機能と能力に関して、最も信頼できるのはそこにないものです。システムでの作業が非常に困難になったため、多くの依存関係を持つ問題のある機能を長い間望まずに削除するよりも、一般的に機能を中央で簡単に追加することは長い間望まれていることを考えると、特にミニマリズムの側に誤りがあります新しい機能ごとに無限の設計質問を提起しながら必要なことよりも。

実際、将来これが頻繁に必要になるかどうかについての強い期待が欠けているので、可能であればこれをAからBへの型置換と見なすのを避け、代わりにAの状態を変換する方法としてそれを求めます。たとえば、Aにいくつかのフィールドを設定して、実際に別の「タイプ」に変更することなくモーフィングしてBのように見えるようにします-Aの状態のときにBでコンポジションを使用して関数を呼び出し、Bを潜在的に格納できます可能な場合、実装を簡素化するためにBを模倣する必要があることを示すように設定されます。それは非常にシンプルで低侵襲のソリューションでなければなりません。

とにかく、他の多くの人と同じように、この場合は一般的な解決策を回避する側に間違いを犯すことをお勧めしますが、これは中央システムに非常に大胆な機能を追加することを考慮しているためだと思います特に今のところ、それを除外する側で過ちを提案します。

この特定の問題に一般的な答えを出すのは難しいです;-)

それが一般的であればあるほど、将来の変更のためにより多くの時間を得ることができます。たとえば、この理由で、多くのゲームプログラムは、ゲーム内のキャラクターとオブジェクトの非常に精巧でありながら厳格なタイプシステムを構築する代わりに、エンティティコンポーネントパターンを使用します。

一方、ジェネリックなものを作成するには、事前に時間と労力を費やして設計する必要がありますが、これは非常に具体的なものよりもはるかに高くなります。これには過剰なエンジニアリングのリスクがあり、潜在的な将来の要件で迷子になることさえあります。

突破口となる自然な一般化があるかどうかを確認する価値は常にあります。ただし、最終的には、現在費やすことができる労力と将来必要になる可能性がある労力のバランスの問題になります。

1. ハイブリッド。これは、どちらかまたは両方の質問である必要はありません。現在必要な特定の変換のみを実装しながら、一般的な型変換用のAPIを設計できます。（サポートされていない変換で一般的なAPIを呼び出すと、「サポートされていない」エラーステータスで失敗することを確認してください。）

2. テスト。A-> B変換の場合、1つ（または少数）のテストを作成する必要があります。一般的なx-> y変換の場合、テストのマトリックス全体を記述する必要があります。すべての変換が単一の一般的な実装を共有している場合でも、それはかなり多くの作業です。

   一方、すべての可能な変換をテストする一般的な方法があることが判明した場合、それ以上の作業はなく、私はより早く一般的なソリューションに行く傾向があるかもしれません。

3. カップリング。AからBへのコンバーターは、必ずAとBの実装の詳細を知る必要があるかもしれません（密結合）。AとBがまだ進化している場合、これはコンバーター（およびそのテスト）を再検討し続ける必要があるかもしれないことを意味しますが、少なくともAとBに限定されます。

   私はすべてのタイプの詳細へのアクセスを必要とする一般的な溶液で行ったい場合は、その後、でもCさんとDの進化として、私は私を遅くすることができ、汎用コンバータ（およびテストの束）、微調整維持する必要があるかもしれませんさえをただし、誰もまだCまたはDに変換する必要はありません。

   ジェネリック変換と特定の変換の両方を、型の詳細に疎結合する方法でのみ実装できる場合、これについて心配することはありません。それらの1つが疎結合の方法で実行でき、もう1つが密結合を必要とする場合、それはゲートからすぐに疎結合アプローチを行うための強力な議論です。

解決策は可能な限り一般的であるか、可能な限り具体的である必要がありますか？

それは答えられる質問ではありません。

合理的に得ることができる最善の方法は、特定のソリューションを作成するための一般的または具体的な方法を決定するためのヒューリスティックです。以下のプロセスのような作業を行うと、通常、1次近似は正しい（または十分な）ものになります。そうでない場合、その理由はドメイン固有であるため、ここで詳しく説明することはできません。

1. 一次近似：ダニエル・プライデン、ドック・ブラウンらによって記述された3つの通常のYAGNIルール。

   これはおそらく、ドメインや他の変数に依存せずにできる最善の方法であるため、一般的に有用なヒューリスティックです。

   したがって、最初の前提は次のとおりです。最も具体的なことを行います。

2. 二次近似：ソリューションドメインの専門知識に基づいて、あなたは言う

   この場合の「汎用」ソリューションは、「特定」ソリューションよりも少ない作業で済みます

   したがって、不必要な一般性を回避するのではなく、不必要な作業を回避することを推奨しているとYAGNIを再解釈することがあります。したがって、最初の推定を変更し、代わりに最も簡単なことを行うことができます。

   ただし、ソリューションドメインの知識から、最も簡単なソリューションが多くのバグを引き起こしたり、適切にテストしたり、他の問題を引き起こしたりする可能性が高いと示されている場合、コードを簡単にすることは、必ずしも変更を加える十分な理由ではありません元の選択。

3. 3次近似：問題領域の知識は、最も簡単な解決策が実際に正しいことを示唆していますか、それともあなたが知っている多くの遷移が無意味または間違っていることを許可していますか？

   簡単だが一般的な解決策に問題があるように見える場合、またはこれらのリスクを判断する能力に自信がない場合は、余分な作業を行って最初の推測にとどまる方がおそらく良いでしょう。

4. 4次近似：顧客の行動に関する知識、この機能が他の機能とどのように関連するか、プロジェクト管理の優先事項、または...その他の厳密でない技術的考慮事項が現在の作業上の決定を変更しますか？

これは簡単な答えで答えるのは簡単な質問ではありません。多くの答えから、3のルールまたは類似のルールに基づいて構築されたヒューリスティックが提供されています。このような経験則を超えることは困難です。

本当にあなたの質問に本当に答えるためには、あなたの仕事がA-> Bを変える何かを実装しない可能性が最も高いことを考慮しなければなりません。あなたが請負業者であれば、それが要件かもしれませんが、あなたが従業員であれば、あなたは会社のために多くの小さな仕事をするために雇われました。A-> Bの変更は、これらのタスクの1つにすぎません。あなたの会社は、たとえそれがリクエストに明記されていなくても、将来の変更がどれだけうまくできるかを気にします。「TheBestImplementation（tm）」を見つけるには、実際に求められていることの全体像を見て、それを使用して、A-> Bを変更するために与えられた小さな要求を解釈する必要があります。

あなたが大学を出たばかりの低レベルのエントリープログラマーである場合、あなたがするように言われたことを正確に行うことはしばしば賢明です。15年の経験を持つソフトウェアアーキテクトとして採用された場合、一般的には全体像について考えることをお勧めします。すべての実際の仕事は、「狭いタスクが何であるかを正確に実行する」と「全体像について考える」間のどこかに分類されます。十分に人々と話をして、彼らのために十分な仕事をすれば、あなたの仕事がそのスペクトルのどこに収まるかを感じるでしょう。

あなたの質問が文脈に基づいて決定的な答えを持っているいくつかの具体例を挙げることができます。安全性が重要なソフトウェアを作成している場合を考えてください。これは、製品が約束どおりに機能することを確認するためにテストチームが立ち上がったことを意味します。これらのテストチームの一部は、コードを通るすべての可能なパスをテストする必要があります。彼らと話をすると、行動を一般化すると、それらの余分なパスをすべてテストする必要があるため、テストコストに30,000ドルを追加することに気付くかもしれません。その場合、作業を7回または8回複製する必要がある場合でも、一般化された機能を追加しないでください。会社のお金を節約し、要求が述べたとおりに実行してください。

一方、顧客が会社が作成したデータベースプログラムのデータにアクセスできるようにするAPIを作成していることを考慮してください。顧客が変更A-> Bを許可するように要求します。通常、APIには黄金の手錠の側面があります。APIに機能を追加すると、通常、その機能を削除することはできません（次のメジャーバージョン番号まで）。顧客の多くは、次のメジャーバージョン番号へのアップグレードの費用を支払う意思がないため、長期にわたって選択したソリューションにとどまる可能性があります。この場合、最初から汎用ソリューションを作成することを強くお勧めします。一度限りの振る舞いに満ちた悪いAPIを開発したくはありません。

うーん...答えに進むべき文脈はあまりありません...以前の答えをエコーし​​ます、「それは依存します」。

ある意味では、あなたの経験に頼らなければなりません。そうでない場合は、ドメイン内のより上級の誰か。あなたは、受け入れ基準が何を述べているかについて口論することができます。「ユーザーがタイプを「A」から「B」に変更できるはず」と「ユーザーがタイプを現在の値から許可された任意の代替値に変更できるはず」の行に沿ったものである場合。

頻繁に受け入れられる基準は解釈の対象となりますが、優れたQAスタッフは、必要な解釈を最小限に抑えて、目の前のタスクに適した基準を作成できます。

「A」から「C」またはその他のオプションへの変更を許可せず、「A」から「B」への変更のみを許可するドメイン制限がありますか？または、これは「前方思考」ではない、狭い仕様の要件ですか？

一般的なケースがより困難な場合は、作業を開始する前に尋ねますが、あなたの場合、他の「タイプ」の変更要求が将来来ると「予測」できれば、私は次のように誘惑されます：一般的な場合に再利用可能なものを書き、b）現時点ではA-> Bのみを許可する条件でラップします。

自動化されたテストで現在のケースを検証するのに十分簡単で、異なるユースケースが発生した場合に/後で別のオプションを開くのに十分簡単です。

私にとって、私が少し前に確立したガイドラインは、「架空の要件については架空のコードのみを記述します」です。つまり、追加の要件が予想される場合は、それらを実装する方法について少し考え、現在のコードがそのようにブロックされないように構成する必要があります。

ただし、これらのコードを実際に記述しないでください。何をするかについて少し考えてください。そうしないと、通常、物事が不必要に複雑になり、後で実際の要件が予期したものと異なる場合に後でイライラするでしょう。

4つの例：あなたのコントロール下でconvertメソッドのすべての使用法がある場合は、今のところconvertAToBと呼ぶことができ、後でより一般的な機能が必要な場合はIDEで「rename method」リファクタリングを使用して名前を変更することを計画できます ただし、変換メソッドがパブリックAPIの一部である場合、これはまったく異なる可能性があります。その場合、名前を変更するのが難しいため、その特定は後で一般化をブロックします。

優れた開発者は、変更を予測し、将来拡張しやすいようにシステムを設計する必要があると聞き続けています。

原則として、はい。しかし、これは必ずしも一般的なソリューションにつながるとは限りません。

ソフトウェア開発には2つのタイプのトピックがありますが、私に関する限り、将来の変更を予測する必要があります。

• サードパーティが使用することを目的としたライブラリ、および
• 全体的なソフトウェアアーキテクチャ。

最初のケースは、凝集/結合、依存性注入などを見ることで解決します。2番目のケースは、より抽象的なレベルです。たとえば、大規模なアプリケーション用の大きなモノロシックコードの代わりに、サービス指向アーキテクチャを選択します。

あなたの場合、あなたは特定の問題に対する特定の解決策を求めていますが、それは将来に予見可能な影響を与えません。この場合、YAGNIとDRYは次の目的で撮影するのに適したモットーです。

• YAGNI（あなたはそれを必要としません）は、あなたが今必要とし、使用する絶対に最小限の、基本的なものを実装するようにあなたに言います。TDD / BDD / FDDスタイルの開発を使用する必要がある場合、現在のテストスイートを赤から緑に変える最小限の実装を意味します。単一行以上ではありません。
• DRY（自分を繰り返さない）あなたは再び同様の問題について来れば、意味そしてあなたは、一般的な解決策が必要かどうかで良いハードを見てみましょう。

これは、他の最新のプラクティス（安全にリファクタリングできるようにするための優れたテストカバレッジなど）と組み合わせると、必要に応じて成長する迅速に記述された無駄のない平均コードになります。

どの方法が一般的な解決策のように聞こえますか？

いいえ、必要なときに簡単かつ楽しくリファクタリングできるプログラミング環境、言語、ツールが必要なようです。一般的なソリューションはそれを提供しません。アプリケーションを実際のドメインから分離します。

Ruby on Railsなどの最新のORMまたはMVCフレームワークをご覧ください。アプリケーションレベルでは、すべてが非汎用作業に焦点を当てています。Railsライブラリ自体は明らかにほぼ100％汎用ですが、ドメインコード（これはあなたの質問です）は、その点で最小限のシェナンガンを行う必要があります。

問題について考える別の方法は、何が理にかなっているかを考慮することです。

たとえば、私が開発していたアプリケーションには、ほとんど同じことをするセクションがありましたが、一貫性のない許可ルールがありました。それらを異なるものにする理由がなかったので、そのセクションをリファクタリングしたときに、すべてのアクセス許可を同じようにしました。これにより、コード全体が小さくなり、シンプルになり、インターフェースの一貫性が高まりました。

管理者が他のユーザーに機能へのアクセスを許可することを決定したとき、フラグを変更するだけでそれを行うことができました。

明らかに、特定の型変換を行うことは理にかなっています。追加の型変換を行うことも意味がありますか？

一般的なソリューションの実装がより高速である場合、具体的なケースも簡単であり、許可されている唯一の型変換であることを確認してください。

アプリケーションが高度に規制された領域（医療または金融アプリケーション）にある場合は、より多くの人が設計に関与するようにしてください。