ハードコードされた値と防御的な設計対YAGNIの削除
最初に少し背景を説明します。Age-> Rateからルックアップをコーディングしています。年齢層は7つあるため、ルックアップテーブルは3列（From | To | Rate）で7行になります。値はめったに変化しません-それらは3年間同じままであった法定レート（最初と3列目）です。このテーブルをハードコーディングせずに保存する最も簡単な方法は、CSVを含む単一のテキスト値として、グローバル構成テーブルのデータベースにあると考えました（「65,69,0.05,70,74,0.06」は、 65-69および70-74の階層が格納されます）。比較的簡単に解析して使用できます。 次に、これを実装するには、新しいテーブル、それをラップするリポジトリ、リポジトリのデータレイヤーテスト、CSVをテーブルに展開するコードの単体テスト、ルックアップ自体のテストを作成する必要があることに気付きました。このすべての作業の唯一の利点は、ルックアップテーブルのハードコーディングを回避することです。 ユーザー（現在、ルックアップテーブルを直接使用している-ハードコピーを見る）と話すとき、「レートは決して変わらない」という意見がほとんどです。明らかにそれは実際には正しくありません-レートは3年前に作成されただけであり、過去に「決して変化しない」という変化の傾向があったため、これを防御的にプログラミングするには、ルックアップテーブルを絶対に保存しないでくださいアプリケーション。 YAGNIだと思う時を除いて。私が実装している機能は、レートが変更されることを指定していません。レートが変更されても、レートが変更されることはめったにないため、メンテナンスが考慮されることすらありません。また、レートの変更と更新されたアプリケーションとの間に遅延があった場合に影響が及ぶほどの重要な機能ではありません。 ルックアップをハードコーディングしても値が失われることはほとんどないと判断し、この特定の機能への私のアプローチについてあまり心配していません。私の質問は、専門家としてその決定を適切に正当化したかどうかです。値をハードコーディングすることは悪い設計ですが、アプリケーションから値を削除するという面倒を見ると、YAGNIの原則に違反するようです。 編集質問を明確にするために、私は実際の実装について心配していません。私は、素早く悪いことをして、YAGNIと言って正当化できるか、または最も防御力のある、努力の行き届いたアプローチをとることができるか心配しています。プロのプログラマーとして、欠陥があるとわかっている設計を実装するという私の決定は、単にコスト/利益分析に帰着しますか？ 編集個人のデザインの選択に帰着すると思うので、すべての回答は非常に興味深いものでしたが、@ Corbinと@EZ Hartが私が質問で考慮していなかったことを提示するので、最良の回答があったと思います。 データベースに移動することによる「ハードコードされた値の正しい削除」と、ハードコーディングを使用した「YAGNIの効率的な適用」の誤った二分法。ルックアップテーブルをアプリの構成に追加する3番目のオプションがありましたが、これは正しい方法のオーバーヘッドを発生させず、YAGNIの効率がありません。私たちは通常、どちらか一方または両方の決定に限定されず、コスト/利益の決定に帰着します。 コード生成により、ハードコードされた値をデータベースに移動するオーバーヘッドを削減できます。また、CSVをテーブルに処理するという過度に設計された決定も削除されます。これにより、ルックアップメソッドの基本的な要件が変更された場合、生成されたコードに長期的なメンテナンスの問題が追加される可能性があります。これはすべて費用対効果分析に影響を与えるだけであり、その自動化が利用可能だったとしたら、このようなものをハードコーディングすることさえ考えていなかっただろう。 @Corbinの答えを正しいとマークしています。これは、開発コストの想定を変更するためです。近い将来、いくつかのコード生成ツールを武器に追加する予定です。