開発中に不確実な将来の要件を考慮する必要がありますか？
複数の顧客ID（カンマ区切り）を入力するために使用される複数のページにまたがる1つのテキストボックスがあります。ただし、現在のページでは、その後の実装上の問題により、ユーザーが複数の顧客IDをカンマ区切りで入力するのではなく、1つの顧客のみを入力できるように顧客IDとして作成しています。
ただし、将来、複数の顧客IDを入力できると想定しているため、すべてのページのコーディングスタイルと変数の名前は同じです。
以下に示すように、customeridを格納するために文字列の代わりに配列を使用しています。
customerIds.Push(tbxval);
一方、customerids配列には、その特定のページの現在のところ、常に1つの要素しかありません。
将来の要件が製品の所有者から求められていない場合、このコードは問題を引き起こす可能性があります。少なくともその要件が満たされるまでは。
しかし、それがどのようなマイナスまたはプラスの影響を与える可能性があるのかはわかりません。
この質問を最も一般的な意味で解釈すると、提案された重複した質問には、おそらくこれまでに得られる最良の答えがあります。
将来に向けて設計しようとすると、将来のニーズに関する予測が間違っていることがよくあります。通常、最初にシステムを過剰設計するよりも、ニーズがどのように変化したかを実際に知っているときにリファクタリングする方が適切です。同時に、足を撃たないでください。確かに妥協点があり、それがどこにあるかを知ることは科学よりも芸術です。
経験則に要約すると、少ないほど多くなります。
しかし、これについては少し拡張できます。未来を予測しようとすることと、実際に未来を知ることとの間には大きな違いがあります。
開発者が製品の長期ビジョンを認識することは重要です。なぜなら、時々、あなたは本当に確かに知っています将来のある時点でXを実行する必要があるからです。たとえば、アプリケーションはいつかカラーテーマをサポートする必要があることを知っているので、現在のデフォルトのカラー値にできるだけ依存しないようにしています。しかし、デフォルトの色を変更するコードは、非常に長い間必要ないため、作成していません。また、どの程度正確に機能させるかはわかりません。また、アプリケーションには国際化が必要であることも当初からわかっていたため、ユーザーを翻訳するシステムがない場合でも、（ほとんどの場合）ユーザー向けの文字列と「コードのみ」の文字列を初日から明確に分離しました。まだ直面しているもの。
あなたの例では、単一の数値の代わりに配列を処理すると、まだ必要のない追加コードを書くのか、それともわずかに異なるコードを書くのかが明確ではありません。 。また、あなたがknow将来これが必要になるのか、それとも推測しているだけなのかは明らかではありません。あなたとあなたの製品マネージャーだけがそれに答えることができます。配列が必要になる可能性が高く、配列を使用してもコードが今のところそれほど複雑にならない場合は、早めに配列の使用を開始することをお勧めします。
将来を予測し、必要以上に一般的にする価値があるのは、下位互換性が必要であるAPI、スキーマ、またはファイル形式を設計しているときだけです。たとえば、メソッドgetPublicUserStats（）を持つWebサービスAPIがある場合、配列ではなく単一のユーザーIDのみを受け入れるようにすることは、現時点で一度に1つしか必要としない場合でも、不必要に制限されます。ただし、実際にパフォーマンスの問題が発生するまでは、1,000のユーザーIDを持つリクエストを最適化するために邪魔にならないようにする必要があります。