完全に真剣な反論をお願いします。あなたの見解では、「データ」と「コード」の違いは何ですか？
「データ」という言葉を聞くと、「状態」と思う。データは、定義上、アプリケーション自体が管理するように設計されたものであり、したがって、アプリケーションはコンパイル時に決して知ることができないものです。それはない可能ではないデータ-すぐにハードコードそれと同じくらい、それが行動になるので、ハードコードデータへ。
データのタイプはアプリケーションによって異なります。商用の請求システムは顧客と注文の情報をSQLデータベースに保存し、ベクトルグラフィックプログラムはジオメトリデータとメタデータをバイナリファイルに保存します。これらのケースとその間のすべてにおいて、コードとデータの間には明確で壊れない分離があります。データはプログラマではなくユーザーのものであるため、ハードコーディングすることはできません。
あなたが話しているように見えるのは、私の現在の語彙で利用可能な最も技術的に正確な説明を使用することです。アプリケーションの大部分を開発するために使用される主要プログラミング言語で書かれていないプログラムの動作を管理する情報です。
「データ」という言葉よりもかなり曖昧ではないこの定義でさえ、いくつかの問題があります。たとえば、プログラムの重要な部分がそれぞれ異なる言語で書かれている場合はどうなりますか？私は個人的に、約50％のC＃と50％のJavaScriptであるいくつかのプロジェクトに取り組んできました。JavaScriptコードは「データ」ですか？ほとんどの人はノーと言うでしょう。HTMLはどうですか、その「データ」ですか？ほとんどの人はまだノーと言うでしょう。
CSSはどうですか？そのデータまたはコードですか？コードをプログラムの動作を制御するものと考えると、CSSは実際にはコードではありません。動作にではなく、外観にのみ影響を与えるからです。しかし、実際にはデータでもありません。ユーザーはそれを所有しておらず、アプリケーションも実際には所有していません。UIデザイナーのコードに相当します。それはコードのようなものですが、完全なコードではありません。
私はCSSを一種の構成と呼ぶかもしれませんが、より実用的な定義は、ドメイン固有の言語の単なるコードであるということです。XML、YAML、およびその他の「フォーマットされたファイル」がよく表すものです。ドメイン固有の言語を使用する理由は、一般的に言えば、CやC＃、Javaなどの汎用プログラミング言語で同じ情報をコーディングするよりも、特定のドメインで同時に簡潔で表現力が高いためです。
次の形式を認識していますか？
{
name: 'Jane Doe',
age: 27,
interests: ['cats', 'shoes']
}
ほとんどの人がそうしていると確信しています。それはだJSON。JSONの興味深い点は次のとおりです。JavaScriptでは、明らかにコードであり、他のすべての言語では、明確にフォーマットされたデータです。ほとんどすべてのメインストリームプログラミング言語には、JSONを「解析」するためのライブラリが少なくとも1つあります。
JavaScriptファイルの関数内でまったく同じ構文を使用する場合、コード以外のものは使用できません。それでも、そのJSONを.jsonファイルに入れ、Javaアプリケーションで解析すると、突然「データ」になります。それは本当に理にかなっていますか？
私は、「データ性」または「構成性」または「コード性」は、それがどのように記述されているかではなく、記述されているものに固有であると主張します。
たとえば、ランダムパスフレーズを生成するために、プログラムに100万語の辞書が必要な場合、次のようにコーディングしますか。
var words = new List<string>();
words.Add("aa");
words.Add("aah");
words.Add("ahhed");
// snip 172836 more lines
words.Add("zyzzyva");
words.Add("zyzzyvas");
または、これらのすべての単語を行区切りのテキストファイルに押し込み、プログラムからそのファイルから読み取るように指示しますか？単語リストが変更されないかどうかは問題ではなく、ハードコーディングまたはソフトコーディング（不適切に適用された場合にアンチパターンであると多くの人が正しく考えている）かどうかの問題ではなく、単に最も効率的な形式であり、「スタッフ」が何であれ、「スタッフ」を最も簡単に記述することができます。コードまたはデータと呼ぶかどうかは、かなり無関係です。それはプログラムが実行するために必要な情報であり、フラットファイル形式はそれを管理し維持するための最も便利な方法です。
あなたが適切な慣行に従うと仮定すると、このようなものはすべてソース管理に入るので、それをコードと呼んでもよいでしょう。または、構成と呼ぶこともできますが、コードを構成と真に区別する唯一のことは、文書化してエンドユーザーに変更方法を伝えるかどうかです。おそらく、コンパイル時ではなく、起動時または実行時に解釈される構成に関する偽の引数を発明できますが、その後、いくつかの動的に型付けされた言語、およびほぼ確実にスクリプトエンジンが埋め込まれたものについて記述し始めますほとんどのゲーム）。コードと構成は、それらにラベルを付けることを決定したものであり、それ以上でもそれ以下でもありません。
今、そこにあるの危険外在実際に変更することは安全ではない情報は、（上記の「ソフトコーディング」のリンクを参照してください）。母音配列を構成ファイルで外部化し、それを構成ファイルとしてエンドユーザーに文書化する場合、たとえば「q」を母音として入力するなど、アプリを即座に中断するほぼ確実な方法を提供します。しかし、それは「コードとデータの分離」の根本的な問題ではなく、単に悪い設計センスです。
私がジュニア開発者に伝えることは、彼らが環境ごとに変更すると予想される設定を常に外部化する必要があるということです。これには、接続文字列、ユーザー名、APIキー、ディレクトリパスなどが含まれます。彼らは可能性があなたのdevのボックスに、生産で同じで、おそらくない、とシステム管理者は、彼らはそれがない開発者、生産で見てみたい方法を決定します。そのため、一部のマシンに1つの設定グループを適用し、他のマシンに他の設定を適用する方法が必要です-エルゴ、外部構成ファイル（またはデータベース内の設定など）
しかし、単に「データ」を「ファイル」に入れることは、それを構成として外部化することと同じではないことを強調します。単語の辞書をテキストファイルに入れることは、ユーザー（またはIT）がそれを変更することを意味するのではなく、開発者が地獄が何をしているのかを理解し、必要に応じて、時折の変更。同様に、テーブルが読み取り専用である場合、および/またはDBAに絶対に干渉しないように指示されている場合、データベーステーブルに同じ情報を入れても、必ずしも行動の外部化としてカウントされません。構成とは、データが変更可能であることを意味しますが、実際には、形式の選択ではなくプロセスと責任によって決定されます。
要約すると、
「コード」は厳密に定義された用語ではありません。定義を拡張して、ドメイン固有の言語や、動作に影響を与える他のものを含めると、この明らかな摩擦の多くは単純に消え、すべて意味があります。フラットファイルには、コンパイルされていないDSL「コード」を含めることができます。
「データ」とは、ユーザーまたは少なくとも開発者以外の誰かが所有し、設計時には一般に入手できない情報を意味します。あなたがそうしたい場合でも、ハードコーディングすることはできません。自己修正コードの例外を除き、コードとデータの分離は定義の問題であり、個人の好みではありません。
「ソフトコーディング」は過剰に適用されるとひどい習慣になる可能性がありますが、外部化のすべてのインスタンスが必ずしもソフトコーディングを構成するとは限りません。
構成は、アプリケーションが異なる環境で実行する必要があるかもしれないという知識があるために必要な特別なタイプのソフトコーディングです。アプリケーションとともに別個の構成ファイルをデプロイすることは、異なるバージョンのコードをすべての環境にデプロイするよりもはるかに少ない作業（およびはるかに少ない危険）です。したがって、実際にはいくつかのタイプのソフトコーディングが便利です。