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

私が開発者として働いてきたこの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/";
    }
})();

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

上記の実践の長所と短所を誰かに説明できますか？

あなたのために働き、保守が容易なコードは、定義により「良い」です。誰かがあなたのコードの問題を指摘できない場合、その人が「グッドプラクティス」という考えに従うためだけに物事を変えるべきではありません。

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

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

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

これは悪い習慣だと考えるのは間違いありません。私はこれを製品コードで見てきましたが、常にあなたに噛み付くようになります。

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

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

1つは、（他の人が述べたように）実装の詳細をコードに関連付けているため、これは悪い考えです。これにより、物事を変えることが難しくなります。

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

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

悪い知らせは耐える。

最高のやる事は（以前にリンクの答えのように、十二・ファクターのAppは、トピックに関する素晴らしいアドバイスを持っている）環境からあなたの設定を設定することです。言語に応じてこれを行う方法がいくつかあります。最も簡単な（通常）方法の1つは、環境変数を設定することです。次に、実行している場所に応じて変数を変更します-ローカルのdevボックス、qa、またはproductionです。別のオプションは、値を.iniファイルまたはJSONに保存することです。さらに別の選択肢は、設定値を実際のコードとして保存することです。使用している言語または環境に応じて、これは良い考えかもしれませんし、そうでないかもしれません。

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

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

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

それは悪い練習です。

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

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

誰かがテストを別のサーバーに移動できます。誰かが、ユーザートレーニング環境、または販売デモ用の環境も必要と判断する場合があります。管理設定のためにプログラマに行く必要はありません。

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

さらに、ソフトウェアは単純に記述すべきではありませんが、現時点ではあなたにとって最も簡単に思えます。ソフトウェア開発のコストは、そのライフタイム全体にわたるソフトウェアメンテナンスのコストに比べて小さいです。そして、今から一年後、あなたはそのコードに取り組んでいる人ではないかもしれません。あなたは、おそらくより環境に優しい牧草地に行ってから何年か後に、あなたが残したかもしれない混乱を拾わなければならない次の貧しい愚か者のために何を残しているのかを考える必要があります。または、あなたがコードを拾い上げたのはあなたかもしれませんが、そのとき何をしたかを信じていません。

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