web-dev-qa-db-ja.com

悪い習慣-ケースを切り替えて環境を設定する

私が開発者として働いた過去3年間に、switchステートメントを使用してURLのパス(バックエンドとフロントエンドの両方)を設定する多くの例を見てきました。以下はこの例です。

バックエンドの例(C#):

public static string getHost(EnvironmentEnum environment){
    var path = String.Empty;
    switch (environment)
    {
        case EnvironmentEnum.dev:
            path = "http://localhost:55793/";
            break;
        case EnvironmentEnum.uat:
            path = "http://dev.yourpath.com/";
            break;
        case EnvironmentEnum.production:
            path = "http://yourpath.com/";
            break;
    }
    return path;
}

フロントエンドの例(JavaScript):

(function () {
    if (window.location.Host.indexOf("localhost") !== -1) {
        window.serviceUrl = "http://localhost:57939/";
    }
    else if (window.location.Host.indexOf("qa") !== -1) {
        window.serviceUrl = "http://dev.yourpath.com/";
    }
    else {
        window.serviceUrl = "http://yourpath.com/";
    }
})();

これは良い習慣か悪い習慣かについて議論されてきましたが、私はこの種のコードを避けて適切な構成を設定する必要があるため、それは悪い習慣だと思います。しかし、正直なところ、私は正しい答えを本当に知りません。なぜそれが推奨されないのか、そしてこれを実装する正しい方法は何ですか。

誰かが上記のプラクティスの長所と短所を説明できますか?

32
gon250

あなたのために機能し、保守が容易なコードは、定義上「良い」です。コードの問題点を指摘できない人がいる場合は、その人の「良い習慣」の考え方を守るためだけに変更するべきではありません。

この場合、最も明らかな問題は、リソースがアプリケーションにハードコードされていることです。動的に選択されたとしても、リソースはハードコードされたままです。つまり、アプリケーションを再コンパイル/再デプロイしない限り、これらのリソースを変更することはできません。外部設定ファイルを使用すると、そのファイルを変更して、アプリケーションを再起動/再ロードするだけで済みます。

それが問題であるかどうかは、それをどうするかによって異なります。とにかくすべてのリクエストで自動的に再配布されるJavascriptフレームワークでは、まったく問題ありません。変更された値は、次回アプリケーションを使用するときにすべてのユーザーに伝播されます。アクセスできない場所にあるコンパイルされた言語でのオンプレミス展開では、それは実際に非常に大きな問題です。アプリケーションの再インストールには時間がかかるか、多額の費用がかかるか、可用性を維持するために夜間に実行する必要があります。

ハードコードされた値が問題になるかどうかは、状況が最初の例に近いか、2番目の例に近いかによって異なります。

81
Kilian Foth

これは悪い習慣だとあなたは考えています。私はこれを量産コードで見ました、そしてそれはいつもあなたを噛むために戻ってきます。

別の環境を追加したい場合はどうなりますか?または開発サーバーを変更しますか?または、別の場所にフェイルオーバーする必要がありますか?構成がコードに直接関連付けられているため、これはできません。

構成は、コードから環境自体に強制する必要があります。これはTwelve-Factorアプリ( http://12factor.net/config )の原則ですが、あらゆるアプリケーションに適しています。環境変数が状況に適していない場合があります。その場合は、コードと一緒に(ただしチェックインされていない)構成ファイルのデータベースにその構成を保存することを検討することをお勧めします。

14
mgw854

1つは、(他の人が述べたように)実装の詳細をコードに結び付けているため、これは悪い考えです。これは物事を変えるのを難しくします。

この答え で述べたように、新しい環境を追加したい場合は、代わりにコードを更新する必要がありますどこでもプログラムを新しい環境に追加するだけです。

JavaScriptコードでこれを行うことには、もう1つの重大な欠陥があります。つまり、会社の内部を潜在的な攻撃者にさらしています。確かに、ファイアウォールの内側にいる可能性がありますが、不満を持つ従業員やウイルスを侵入させる誰かがまだいる可能性があります。

悪いニュースは弱気。

bestすべきことは、環境から構成を設定することです(以前にリンクされた回答のように、Twelve-Factor Appはこのトピックについて素晴らしいアドバイスをしています) 。あなたの言語に応じてこれを行うにはいくつかの方法があります。最も簡単な(通常は)環境変数を設定するだけです。次に、実行している場所に応じて変数を変更するだけです。それがローカルの開発ボックス、QA、または本番環境であるかどうかです。別のオプションは、.iniファイルまたはJSON。さらに別の方法は、実際のコードとして構成値を保存することです。これを使用している言語または環境によっては、これが適切な場合とそうでない場合があります。

ただし、最終的な目標は、1つのコードベースを取得し、サポートされているアーキテクチャ/接続性を持つ任意のマシンにドロップして実行できるようにすることです。コードを変更することなく。

5
Wayne Werner

自分のマシンでバックエンドを実行したいが、ポート55793では実行しない場合、たとえば、複数のバージョンを同時に実行してそれらを比較している場合はどうなりますか?あるマシンでアプリケーションバックエンドを実行したいが、別のマシンからアクセスしたい場合はどうなりますか? 4番目の環境を追加する場合はどうなりますか?他の人が指摘したように、基本的な構成を変更するためだけに再コンパイルする必要があります。

あなたが説明したアプローチは、これまでのところあなたのチームで実際に機能しているかもしれませんが、それは無意味に制限的です。このパスのようなパラメーターを中央の構成ファイルで任意に設定できる構成システムは、固定オプションのみを提供するものよりもはるかに柔軟性が高く、switchステートメントのアプローチでどのような利点がありますか?無し!

1
PeterAllenWebb

BAD PRACTICEです。

ソフトウェア設計の基本原則:プログラム内に構成値をハードコーディングしないでください。これは、将来変更される可能性が十分にあるすべての場合に特に当てはまります。

開発するプログラムコードは、QAテスト、UAT、本番環境などの任意の環境に入るコードと同じである必要があります。環境が変わったために誰かが後で設定を変更する必要がある場合、または新しい環境でそれを使用する必要がある場合は、問題ありません。ただし、そうするためにプログラムコードを変更する必要はありません。また、環境ごとに異なるバージョンのコードを使用しないでください。テスト後にプログラムが変更された場合、そのバージョンはテストされていません。ソフトウェアエンジニア、ソフトウェア品質保証の専門家、IT担当者にお問い合わせください。プロジェクト管理の専門家、IT監査人。

誰かがテストを別のサーバーに移動する可能性があります。誰かが、ユーザートレーニング環境、またはセールスデモンストレーションの環境も必要とする場合があります。彼らは管理者の設定のためにプログラマーに行く必要はありません。

ソフトウェアは、理由の範囲内で予期しない状況を処理するのに十分な柔軟性と堅牢性を備えている必要があります。

さらに、ソフトウェアは単純に書かれるべきではありませんが、現時点ではあなたにとって最も簡単に思えます。ソフトウェア開発のコストは、そのライフタイムにわたるソフトウェアメンテナンスのコストに比べてわずかです。そして、今から1年後、あなたがそのコードに取り組んでいる人ではないかもしれません。緑豊かな牧草地に行った数年後に、あなたが置き去りにしたあらゆる混乱を拾わなければならない次の貧しい愚か者に何を残しているかを考えるべきです。または、何年も後にコードを取得し、当時何をしていたかを信じない人かもしれません。

できる限り適切にコーディングしてください。後で問題になる可能性は低くなります。

0
WarrenT