不良做法-将案例切换到设置环境

32

在我担任开发人员的最近三年中，我看到了许多示例，这些示例中的人们使用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/";
    }
})();

已经讨论过这是一个好习惯还是一个坏习惯，我认为这是一个坏习惯，因为我们必须避免这种代码并设置适当的配置。但老实说，我真的不知道正确的答案，为什么不建议这样做，以及实现此问题的正确方法是什么。

有人可以解释一下上述做法的利弊吗？

— gon250
source

13

仅这条线不是最佳的。path =“ yourpath.com ”; 配置应在代码外部。

— 狗仔队2015年

2

从纯代码审查的角度来看，a Dictionary是使用C＃进行编码的更简洁的方法。参见ideone.com/45g5xO。或者在JS中使用旧的对象，请参阅jsfiddle.net/1ouhovqq。

— 丹尼·贝克特

4

如果您的公司名称更改为包含“ qa”的内容会怎样？

— user253751

请记住，如果您使用配置文件，则需要在源代码控制中对其进行控制。...任何情况下，您在安装新的测试机时可能必须每天多次编辑配置文件。我仍然认为配置文件是最好的，但是在查看detaul配置文件之前，您不妨先寻找一个基于环境的文件。

— 2015年

1

如果您无法量化为什么自己认为这是一种不好的做法，我认为您不应该四处称呼“不好的做法”

— Roy

81

根据定义，对您有用并且易于维护的代码是“好”。如果某人不能指出您的代码出了什么问题，则永远不要为了服从某人的“良好实践”的想法而进行更改。

在这种情况下，最明显的问题是资源被硬编码到您的应用程序中-即使动态选择资源，它们仍然被硬编码。这意味着您必须重新编译/重新部署应用程序才能更改这些资源。使用外部配置文件，您只需更改该文件并重新启动/重新加载您的应用程序即可。

这是否是一个问题取决于您如何处理。在一个自动随每个请求自动重新分发的Javascript框架中，这完全没有问题-更改的值将在每个用户下次使用该应用程序时传播到每个用户。在无法访问的位置以编译语言进行本地部署确实是一个很大的问题。重新安装该应用程序可能会花费很长时间，花费大量金钱，或者必须在晚上进行以保持可用性。

硬编码值是否有问题取决于您的情况是更像第一个示例还是第二个示例。

— 基利安·福斯（Kilian Foth）
source

15

我爱你的第一段。当然，您可以继续进行操作，指出问题出在哪里……但是，“这很糟糕，因为博客XYZ这么说”的想法是导致错误代码超出实际预防范围的原因。

— corsiKa 2015年

5

相对论应该给初学者以久经考验的原则，而不是简单地“如果对您有用，那就可以了”。我想说硬编码环境值在任何情况下都是彻头彻尾的坏习惯，我想我没错。

— 图兰斯·科尔多瓦

3

@ jpmc26：当然，您假设部署服务器端代码并非易事，并且还存在一些单独的过程，通过这些过程可以以较少的开销更新配置值。两者都不是必须的。许多商店在部署过程中的开销很少。另一方面，实际上，在某些商店中，配置更改的开销基本上与部署更改的代码一样多。（验证，需要一大堆人的批准等）。重复的担忧绝对是正确的。

— 凯文·卡斯卡特

2

在将环境设置与应用程序代码混合在一起的情况下，您将是一个逻辑错误（或执行环境中的意外更改），而无法进行生产中的测试，生产中的测试或其他意外的和可能的灾难性组合。与C＃中的代码分开维护特定于环境的属性通常很简单。为什么要冒不必要的风险？

— John M Gant 2015年

1

@ user61852“我想说硬编码环境值在任何情况下都是彻头彻尾的坏习惯，我认为我没有错。” 解析为“硬编码环境值始终是不正确的做法”如果这始终是不正确的做法，那么应该总是有可能找出至少一个硬编码环境值将引起的问题。

— emory

14

您认为这是错误的做法，这是绝对正确的。我已经在生产代码中看到了这一点，并且总是会咬你。

当您想添加另一个环境时会发生什么？还是更改您的开发服务器？或者您需要故障转移到其他位置？您不能这样做，因为您的配置与代码直接相关。

配置应从代码中强制执行，而应进入环境本身。这是十二要素应用程序（http://12factor.net/config）的原理，但是对于任何应用程序都是一个好习惯。您可能会发现环境变量不适合您的情况，在这种情况下，我建议您将配置与代码一起（但不能通过检入）存储在配置文件的数据库中。

— w
source

如果您不跟踪配置文件，怎么知道您拥有的配置文件对于您刚刚从VCS中检出的软件版本是否有效。（即，未跟踪的配置文件与未跟踪的源文件没有区别-没有它，您将无法通过VCS结帐进行构建和部署）

— mattnz 2015年

我不同意未跟踪的配置文件是一个难题。我之前处理此问题的方式有两个：一，用于部署的二进制文件还包含一个定义其配置的XML模式（因此您可以验证给定的配置文件是否可以工作）。其次，每种环境的配置文件都存储在文档控制系统中，每种环境具有不同的文件夹。在具有分支的Git中可以执行类似的操作-版本受控制，但与无环境代码有所区别。

— mgw854

5

对于一个（如其他人所提到的），这是个坏主意，因为您将实现细节绑定到了代码中。这使得改变事物变得困难。

如本答案所述，如果您现在要添加新环境，则必须在各处更新代码，而不仅仅是将程序添加到新环境中。

在您的Javascript代码中执行此操作还有另一个严重缺陷：您将公司内部暴露给潜在的攻击者。当然，您可能在防火墙后面，但是您仍然可能有不满的员工或允许病毒进入的人。

坏消息熊。

在最好做的事情是从环境中设置您的配置（如在以前链接的答案，十二因子应用程序对主题伟大的意见）。有几种方法可以执行此操作，具体取决于您的语言。最简单（通常）的方法之一就是只设置环境变量。然后，您只需要根据运行位置更改变量即可-不管是本地开发箱，质量保证还是生产环境。另一个选择是将值存储在.ini文件或JSON中。另一个选择是将配置值存储为实际代码。根据您使用的语言或环境，这可能不是一个好主意。

但是最终目标是让您采用一个代码库，将其放在具有受支持的体系结构/连接性的任何计算机上，并能够在不以任何方式修改代码的情况下运行它。

— 韦恩·沃纳（Wayne Werner）
source

1

如果我想在自己的计算机上而不是在端口55793上运行后端，例如，如果我同时运行多个版本以进行比较，该怎么办？如果我想在一台机器上运行应用程序后端，而又从另一台机器上访问该怎么办？如果要添加第四个环境怎么办？正如其他人指出的那样，您只需要重新编译即可更改基本配置。

到目前为止，您所描述的方法可能已在您的团队中实践过，但这毫无意义。一个配置系统允许在中央配置文件中任意设置类似此路径的参数，比仅提供固定选项的配置系统灵活得多，使用switch语句方法有什么好处？没有！

— 彼得·艾伦·韦伯
source

0

这是一个坏习惯。

软件设计的基本原则：不要在程序内部硬编码配置值。对于任何将来有可能发生变化的事物而言，尤其如此。

您开发的程序代码应该与用于任何环境（例如QA测试，UAT和生产）的代码相同。如果某人由于环境已更改以后需要更改配置，或者他们需要在新环境中使用它，可以。但是，他们永远不必触摸您的程序代码。而且对于每个环境，您不应有不同版本的代码。如果自测试以来您的程序已更改，则您尚未测试该版本。询问任何软件工程师，任何软件质量保证专业人员，任何IT项目管理专业人员，任何IT审核员。

有人可以将测试移至另一台服务器。可能有人会决定还需要一个用户培训环境或一个销售演示环境。他们不必去程序员那里进行管理配置。

软件应具有足够的灵活性和健壮性，以在合理范围内处理意外情况。

此外，软件不应简单地编写，但是目前看来对您来说最简单。与软件生命周期内的软件维护成本相比，软件开发成本很小。假设从一年以后，您可能不是从事该代码工作的人。您应该考虑要留给下一个可怜的傻瓜的事情，下一个可怜的傻瓜可能要拾起您可能留下的任何烂摊子，也许是在您踏上绿色牧场之后的几年。或者，您可能是几年后才开始使用代码的人，不相信您当时所做的事情。

尽最大可能对代码进行正确编码。以后不太可能成为问题。

— 沃伦
source