私は独学で初心者っぽいコーダーなので、プログラマーの専門用語を釘付けにしないとお詫びします。
私は、データのクエリからレポートを生成するツールを基本的に作成する開発者に、継続的に更新されるデータを提供するプロジェクトに取り組んでいます。
関係者全員が考えているようです。データ値（スキーマではなく、ドメイン/値自体）をレポート生成プログラムにハードコーディングする必要があること。
たとえば、担当者についてレポートしているとすると、レポートは分割されます。カテゴリに分類され、各部門の見出しがあり、各部門の見出しの下に役職の小見出しがあり、各小見出しの下に従業員のリストがあります。開発者は、部門と役職をハードコーディングしたいと考えています。一方、実行時にそれらをクエリし、レコードを並べ替え、値に基づいて動的にレポートヘッダーを生成できる/だろうと思います。
潜在的な値のリストは時間の経過とともに変化するため（たとえば、部門が作成/名前変更され、新しい役職が追加されます）、コードを継続的に更新する必要があります。コードのメンテナンス手順をスキップして、レポートを動的に整理できるように思えます。
私は開発者ではないので、何が欠けているのか疑問に思っています。このようなツールに値をハードコーディングすることにはどのような利点がありますか？これは通常、プログラムの設計方法ですか？
コメント
- の重複の可能性ハードコードの削除値と防御設計vsYAGNI
- レポートのクロス集計は、行の値を列として表示する必要があることを意味しますか？
- @ Brendan-レポートに値をハードコーディングする場合、'リストを2か所（データソースとレポート）で変更する必要がありますが、レポートが動的である場合は、1か所（レポート）で変更するだけで済みます。 。
- @Brendanなぜ3つの場所になってしまうのですか？おそらく私の理解は正しくありませんが、'データベースからデータをフェッチするSQLクエリを想定している場合、アプリケーションは戻り値を部門などによって集計/グループ化します。 '複数のデータベースクエリのオーバーヘッドを許容する場合は、本当に必要に応じて、個別の部門/役割のタイトルを選択できます。データが複数の場所に存在することは決してありません-レポートはデータによって駆動されています。
- @Brendanまた、データが1つの場所にあるというあなたの定義にも同意しません-あなたがそれを説明する方法'は複数の場所にあり、ソースコード全体に散在しています。
回答
ウィキペディア：
ハードコーディング（ハードコーディングまたはハードコーディングも）とは、おそらく振り返ってみると、入力データまたは構成データと見なされるものを、プログラムまたは他の実行可能オブジェクトのソースコードに直接埋め込む、または固定フォーマットのソフトウェア開発慣行を指します。データを外部ソースから取得したり、データを生成したり、指定された入力を使用してプログラム自体でフォーマットしたりする代わりに、データ。
ハードコーディングはアンチパターンと見なされます。
考慮されたnアンチパターン、ハードコーディングでは、入力データまたは目的の形式が変更されるたびにプログラムのソースコードを変更する必要があります。これは、エンドユーザーがプログラムの外部で何らかの方法で詳細を変更する方が便利な場合です。
回避できない場合もありますが、一時的なものにする必要があります。
ハードコーディングは多くの場合必要です。プログラマーは、エンドユーザー向けの動的なユーザーインターフェイスソリューションを作成していない可能性がありますが、それでも機能を提供するか、プログラムをリリースする必要があります。これは通常一時的なものですが、短期的には、コードを提供するというプレッシャーを解消します。後で、ユーザーが結果または結果を変更する方法をエンドユーザーに提供するパラメーターを渡すことができるようにソフトコーディングが行われます。
- ハードコーディングメッセージが多いと、プログラムを国際化するのが難しくなります。
- パスをハードコーディングすると、別の場所に適応するのが難しくなります。
ハードコーディングの唯一の利点は、コードの迅速な配信にあるようです。
コメント
- OK 、しかし、"唯一の利点"はしばしば非常に重要です。プログラミングにおける設計上の決定は、多くの場合、将来の保証と現在の短納期の間のトレードオフに関するものであり、そのため、ハードコーディングは完全に受け入れられる選択です。ハードコーディングがない場合は、設計上の選択として不適切な場合があります。
- -1私は'これが役立つ答えだとは思いません。基本的に、'値をソースコードに不適切に埋め込むことは不適切であると述べています'。 OPは、物事がソースコードに属しているため、ウィキペディアの定義から外れる場合についてのガイダンスを求めていると思います。
- ハードコーディングはプロセスの重要な部分であり、アンチパターンは時代遅れであると考えています。マイクロサービスの時代。AngularTourofHeroesチュートリアルは、中間ステップとして直接組み込まれている、または義務付けられている巨大なソフトウェアハウスの注目を集める例です。さらに、動的データに移行する場合でも、ハードコードされたデータをフォールバックとして保持する必要があります。これは、おそらく環境変数またはコード自体のブールトグルによって制御されるため、バグやセキュリティの問題を適切に切り分けることができます。行。
回答
本当に？考えられる有効な使用例はありませんか？
ハードコーディングは一般的にアンチパターンまたは少なくとも非常に悪いコードの臭い、それが理にかなっているケースはたくさんあります。いくつかあります。
-
シンプルさ / YAGNI 。
-
実際には決して変化しない実際の定数。
つまり、定数は自然を表します。 >またはビジネス定数、または近似値。 （例：0、PI、…）
-
ハードウェアまたはソフトウェアの環境制約
組み込みソフトウェアでは、メモリと割り当ての制約が頭に浮かびます。
-
安全なソフトウェア
これらの値は利用できないか、デコードやリバースエンジニアリングが容易ではありません。暗号トークンとソルト。 （ハードコードされたままにしておくことには明らかな欠点もあることに注意してください…）
-
生成されたコード
プリプロセッサまたはジェネレータは構成可能ですが、ハードコードされた値でコードを吐き出します。ルールエンジンに依存するコードや、モデル駆動型アーキテクチャを使用している場合は珍しいことではありません。
-
高性能コード
ある意味でこれは"生成された"コードです、さらに専門的ですが。例えば変更の可能性が低い、事前に決定されたルックアップ/計算テーブル。これは、たとえばグラフィックプログラミングではまったく珍しいことではありません。
-
構成とフォールバック
実際のコードと構成ファイルの両方で、構成値があり、いくつかの場合（構成が利用できない場合、コンポーネントが次のように応答しない場合）のフォールバックがある可能性があります。期待されるなど…）。それでも、一般的にはコードの外に置いて調べてみるのが最善ですが、特定のアクション/問題/状況に対して特定の値/反応を絶対に持ちたい場合もあります。
-
そしておそらくもう少し…
それでもアンチパターン？オーバーエンジニアリングもそうです！それはあなたのソフトウェアの平均余命についてです!!
私が言っているのではありませんすべての大きな理由があり、一般的にはハードコードされた値を無視します。しかし、正当な理由で簡単にパスを取得できるものもあります。
そして単純さ/
YAGNI は些細なことだと思っても、狭いユースケースで1つのジョブを実行する単純なスクリプトにクレイジーなパーサーと値チェッカーを実装する理由はおそらくないでしょう。
バルを見つけるのは難しいアンス。ソフトウェアが成長し、最初の単純なスクリプトよりも長持ちすることを予測できない場合があります。ただし、多くの場合、その逆です。私たちは物事を過剰に設計し、プロジェクトはあなたよりも早く棚上げされます。 PragmaticProgrammerを読んでください。初期のプロトタイプでは必要なかったものよりも時間と労力を無駄にしました。
これはアンチパターンの平均的なことです。これらはスペクトルの両極端に存在し、その外観はコードをレビューする人の機密性。
個人的には、何かが変わる可能性があることがわかったらすぐに、または私が「これまで何度もやらなければなりませんでした。しかし、より正確なアプローチは、ハードコーディングのコストと、その特定の状況でのコードの生成または生成のコストを慎重に評価することです。これは、タスクを手動で行うのではなく、自動化する価値があるかどうかを判断することと同じです。時間とコストを考慮してください。
コメント
- それは'面白いです。自分でパイロットしたので、値を動的に処理する方がはるかに簡単で、速く、クリーンでした。 Pythonですが、最終製品はJavaでコーディングされると思いますが、これが違いを生む場合は、値をハードコーディングすると、受信する各列を複数の場所で追跡する必要があるため、過剰に設計されているように感じました。
- @Tom：'ハードコードされた値を使用するよりも、構成ルックアップライブラリを実装（または再利用）する方が簡単で高速だと言っていますか？また、'あなたの最後の文がオーバーエンジニアリングの定義にどのように適合するかわかりません。うなぎは明らかに乱雑であり、明らかに'がハードコーディングされて複製された場合、'さらに悪化します（これはあなたの目的ではありませんでした）質問の質問、私はおそらく誤解しましたが、値が毎回ハードコードされているのではなく、プログラムの1つのポイントにハードコードされていることを意味しているように見えました。
- とにかく、私は' mは、'が有効である場合を指摘しているだけです。 'また、最後の文で'物議を醸していることも指摘しています。 '全員やチームにさまざまなスキルレベルの人がいることを喜ばせることはできません。
- @ Tom、don ' t短すぎます。あなたは'間違いなく何かに取り組んでいます。
Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']をハードコーディングするのではなく、部門と役職のフィールドを確認してデータを整理するための迅速なアルゴリズムを作成する方が簡単で時間もかかりません。また、新しい部門または役職が導入された場合に、ハードコードされた配列を維持することははるかに困難になります。 - ハードコードされたままでも、より複雑なものを使用できます。私が数年前に書いたことを思い浮かぶのは、一連の値のすべての可能な順列でした。ランダムな有効な方向を見つける必要があり、ランダムな順列を選択してから最初の有効な結果を取得することが、これまでで最も効率的な解決策であり、O（N ^ 3）ループ内にあるため効率が重要でした。