什么是“软编码”？

在Alex Papadimoulis的这篇文章中，您可以看到以下片段：

private void attachSupplementalDocuments()
{
  if (stateCode == "AZ" || stateCode == "TX") {

    //SR008-04X/I are always required in these states
    attachDocument("SR008-04X");
    attachDocument("SR008-04XI");
  }

  if (ledgerAmnt >= 500000) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
  }

  if (coInsuredCount >= 5  && orgStatusCode != "CORP") {
    //Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A
    attachDocument("AUTHCNS-1A");
  }
}

我真的不明白这篇文章。

我引用：

如果每个业务规则不断被存储在一些配置文件，生活会多[更多（原文如此）难以为大家维护软件：有会是大量的代码文件共享的一个大文件（或者，反过来，大量微型配置文件）；部署对业务规则的更改不需要新代码，而是手动更改配置文件；而调试则要困难得多。

这是反对在配置文件中包含“ 500000”常量整数或“ AUTHCNS-1A”和其他字符串常量的说法。

这怎么可能是个坏习惯？

在此代码段中，“ 500000”不是数字。例如，它与以下内容不同：

int doubleMe(int a) { return a * 2;}

其中2是不需要抽象的数字。它的用法很明显，并且不代表以后可以重用的内容。

相反，“ 500000”不仅仅是数字。这是一个重要的价值，代表了功能断点的想法。该号码可以在多个地方使用，但不是您正在使用的号码。这是限制/边界线的概念，低于此规则将适用一个规则，高于该规则将适用另一条规则。

从配置文件甚至是#define，const或您的语言提供的任何内容中引用它，比包含它的值还差吗？如果后来上节目，或者一些其他的程序员，还要求边缘，使该软件使得另一种选择，你就完蛋了（因为当它改变，没有什么可以保证你将在这两个文件改变）。对于调试而言，这显然更糟。

另外，如果明天政府要求“从5/3/2050起，您需要添加AUTHLDG-122B而不是AUTHLDG-1A”，则此字符串常量不是简单的字符串常量。它代表一个想法。这只是该想法的当前值（即“如果分类帐超过500k，则添加的内容”）。

让我澄清一下。我并不是说这篇文章是错误的；我就是不明白。也许解释得不太好（至少出于我的想法）。

我确实知道，用常量，定义或配置变量替换所有可能的字符串文字或数字值不仅不是必需的，而且会使事情复杂化，但是该特定示例似乎并不属于此类。您怎么知道以后将不需要它？还是其他人呢？

作者警告不要过早抽象。

该行if (ledgerAmt > 500000)看起来像是您对大型复杂业务系统所期望看到的那种业务规则，这些系统的需求极其复杂，但精确且有据可查。

通常，这些类型的需求是例外/边缘情况，而不是有用的可重用逻辑。这些需求通常是由业务分析师和主题专家拥有和维护的，而不是由工程师拥有和维护的。

（请注意，在这种情况下，业务分析师/专家对需求的“所有权”通常发生在专业领域的开发人员没有足够的领域专业知识的情况下；尽管我仍然希望开发人员与领域专家之间能够进行充分的沟通/合作，以防止受到攻击含糊不清或书写不当的要求。）

当维护其需求充满边缘情况和高度复杂的逻辑的系统时，通常没有办法有效地抽象该逻辑或使其更具可维护性。尝试构建抽象的尝试很容易适得其反-不仅浪费时间，而且导致可维护性降低。

如何从配置文件甚至＃define，const或您的语言提供的任何内容中引用它，而不是包含它的值？如果程序的稍后版本或其他程序员也需要该界限，那么该软件将为您做出另一选择，这很麻烦（因为更改时，不能保证在两个文件中都会更改）。对于调试而言，这显然更糟。

此类代码倾向于受到以下事实的保护：代码本身可能具有与需求的一对一映射。即，当开发人员知道该500000数字在需求中出现两次时，该开发人员也知道其在代码中出现两次。

考虑500000在需求文档中多个位置出现的另一种（同样可能的）场景，但是主题专家决定只更改其中一个。那里的风险更大，有人在更改const值可能不会意识到500000用来表示不同的意思-因此，开发人员在其中更改了它，只将他/她在代码中找到它的地方，最终破坏了他们所认为的东西没意识到他们已经改变了。

这种情况在定制的法律/财务软件（例如，保险报价逻辑）中经常发生-编写此类文档的人不是工程师，他们可以毫无问题地复制+粘贴规范的全部内容，只需修改几个单词/数字，但是保持大多数不变。

在这些情况下，处理复制粘贴要求的最佳方法是编写复制粘贴代码，并使该代码看起来与要求尽可能相似（包括对所有数据进行硬编码）。

此类需求的实际情况是，它们通常不会长时间保持复制+粘贴，并且值有时会定期更改，但它们通常不会一前一后更改，因此请尝试对这些需求进行合理化或抽象化或简化无论如何，它们最终都带来了更多的维护难题，而不仅仅是将需求逐字翻译为代码。

这篇文章很有道理。将常量提取到配置文件怎么可能是个坏习惯？如果不必要地使代码复杂化，则可能是一个坏习惯。直接在代码中拥有一个值比从配置文件中读取它要简单得多，并且编写的代码易于遵循。

此外，明天政府将发布“从5/3/2050起，您需要添加AUTHLDG-122B而不是AUTHLDG-1A”。

是的，然后您更改代码。本文的重点是，更改代码并不比更改配置文件复杂。

如果您获得更复杂的逻辑，本文中描述的方法将无法扩展，但要点是您必须做出判断，有时最简单的解决方案就是最好的解决方案。

您怎么知道以后将不需要它？还是其他人呢？

这就是YAGNI原则的重点。不要为未知的未来而设计，这可能会与现在完全不同。您是正确的，如果在程序中的多个位置使用了值500000，则应将其提取为常数。但这不是所讨论的代码中的情况。

软编码实际上是关注点分离的问题。您对可能会独立于核心应用程序逻辑更改的信息进行软编码。您永远不会将连接字符串硬编码到数据库，因为您知道它可能独立于应用程序逻辑而改变，并且您将需要针对不同的环境进行区分。在Web应用程序中，我们希望将业务逻辑与html模板和样式表分开，因为它们可能会独立更改，甚至可能由其他人更改。

但是在代码示例中，硬编码的字符串和数字是应用程序逻辑的组成部分。可以想象一个文件可能会因您无法控制的某些策略更改而更改其名称，但是也可以想象，我们需要为不同的条件添加一个新的if分支检查。在这种情况下，提取文件名和编号实际上会破坏凝聚力。

本文继续讨论“企业规则引擎”，这可能是他所反对的一个更好的例子。

逻辑是，您可以概括到您的配置变得如此复杂以至于它包含自己的编程语言。

例如，示例中的状态代码到文档的映射可以移动到配置文件中。但是您将需要表达一个复杂的关系。

<statecode id="AZ">
    <document id="SR008-04X"/>
    <document id="SR008-04XI"/>
</statecode>

也许您还要输入分类帐金额？

<statecode id="ALL">
    <document id="AUTHLDG-1A" rule="ledgerAmt >= 50000"/>
</statecode>

很快，您发现您正在使用一种新的语言进行编程，并将该代码保存在没有源代码或变更控制权的配置文件中。

应该注意的是，这篇文章是从2007年开始的，当时这种事情是一种通用方法。

如今，我们可能会通过依赖项注入（DI）解决此问题。即，您将有一个“硬编码”

InvoiceRules_America2007 : InvoiceRules

您可以将其替换为硬编码或更可配置的

InvoiceRules_America2008 : InvoiceRules

当法律或业务要求发生变化时。

相反，“ 500000”不仅仅是数字。这是一个重要的价值，代表了功能断点的想法。该数字可以在多个地方使用，但这不是您使用的数字，它是限制/边界线的概念，在该规则以下，一个规则在此之上，在另一个之上。

这可以通过以下方式表达（我可以说，即使是评论也是多余的）：

 if (ledgerAmnt >= 500000) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
  }

这只是重复执行代码：

LEDGER_AMOUNT_REQUIRING_AUTHLDG1A=500000
if (ledgerAmnt >= LEDGER_AMOUNT_REQUIRING_AUTHLDG1A) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
}

请注意，作者假定500000的含义与该规则相关；它不是在或可能在其他地方重用的值：

此先前的软编码可以解决的唯一且唯一的业务规则更改是分类帐数量的更改，需要表格AUTHLDG-1A。任何其他业务规则更改将需要更多的工作–配置，文档，代码等

在我看来，本文的主要观点是，有时数字只是一个数字：除了代码中传达的内容之外，它没有其他意义，并且不太可能在其他地方使用。因此，仅出于避免硬编码值的目的而笨拙地概括代码在变量名中（现在）所做的事情充其量是不必要的重复。

其他答案是正确的，周到的。但是，这是我的简短回答。

  Rule/value          |      At Runtime, rule/value…
  appears in code:    |   …Is fixed          …Changes
----------------------|------------------------------------
                      |                 |
  Once                |   Hard-code     |   Externalize
                      |                 |   (soft-code)
                      |                 |
                      |------------------------------------
                      |                 |
  More than once      |   Soft-code     |   Externalize
                      |   (internal)    |   (soft-code)
                      |                 |
                      |------------------------------------

如果规则和特殊值出现在代码中的某个位置，并且在运行时未更改，则按照问题所示进行硬编码。

如果规则或特殊值出现在代码中的多个位置，并且在运行时未更改，则进行软编码。规则的软编码可以定义特定的类/方法，也可以使用Builder模式。对于值，软编码可能意味着为要在整个代码中使用的值定义单个常量或枚举。

如果规则或特殊值可能在运行时更改，则必须将其外部化。通常通过更新数据库中的值来完成。或通过用户输入数据来手动更新内存中的值。也可以通过将值存储在文本文件（XML，JSON，纯文本等）中进行重复扫描以查找文件修改日期-时间更改。

当我们尝试说明一个实际问题时，这是我们遇到的陷阱，当我们使用玩具问题然后仅提出稻草人解决方案时。

在给定的示例中，给定的值是硬编码为内联值还是定义为const都没有什么不同。

周围的代码使该示例成为维护和编码方面的恐怖。如果是没有周围的代码，则该代码段是好的，至少在恒定重构的环境。在不太可能进行重构的环境中，该代码的维护者已经死了，原因很快就会变得显而易见。

看，如果周围有代码，那么显然会发生坏事。

第一件坏事是值50000被某处的另一个值使用，例如某些州的税率发生变化的分类帐额...然后，当发生更改时，维护者无法知道，何时发现这些值代码中的两个50000实例，无论它们是相同的50k还是完全不相关的50ks。并且如果有人也将它们用作常量，您还应该搜索49999和50001吗？这不是在单独服务的配置文件中对这些变量进行划分的调用：但是内联对其进行硬编码显然也是错误的。相反，它们应该是常量，在使用它们的类或文件中定义并限定范围。如果两个50k实例使用相同的常数，则它们可能代表相同的立法限制；如果没有，他们可能不会；无论哪种方式，他们都会有一个名字，

文件名将被传递给一个函数-AttachDocument（）-该函数接受基本文件名作为字符串，没有路径或扩展名。从本质上来说，文件名是指向某些文件系统或数据库的外键，或者是attachDocument（）从何处获取文件的外键。但是这些字符串对您一无所知-有多少文件？它们是什么类型的文件？您如何知道在开拓新市场时是否需要更新此功能？它们可以附在什么类型的东西上？维护人员完全不知所措，他所拥有的只是一个字符串，它可能在代码中多次出现，并且每次出现时都具有不同的含义。在一个地方，“ SR008-04X”是一个作弊代码。在另一个命令中，这是命令订购四枚SR008助推火箭的命令。来啦 一个文件名？这些有关系吗？有人刚刚更改了该功能，以提及另一个文件“ CLIENT”。然后，您，糟糕的维护者，被告知“ CLIENT”文件需要重命名为“ CUSTOMER”。但是字符串“ CLIENT”在代码中出现了937次……您甚至从哪里开始寻找？

的 玩具的问题是，值都是不寻常的，能够合理保证在代码中是独一无二的。不是“ 1”或“ 10”，而是“ 50,000”。不是“客户端”或“报告”，而是“ SR008-04X”。

的 稻草人是唯一的其他方式来解决impenetrably不透明常数的问题是蜂巢不送到一些不相关的服务的配置文件。

您可以一起使用这两个谬论来证明任何论点都是正确的。

这有几个问题。

一个问题是是否应该构建规则引擎以使所有规则都可以在程序本身之外轻松配置。在类似情况下的答案通常不是。规则将以难以预测的奇怪方式变化，这意味着只要发生​​变化，就必须扩展规则引擎。

另一个问题是如何处理这些规则及其在版本控制中的更改。最好的解决方案是将规则分为每个规则的一个类。

这使得每个规则都有其自己的有效性，某些规则每年都会更改，某些更改将取决于已颁发许可或开具发票的时间。规则本身包含必须应用哪个版本的检查。

同样，由于常量是私有的，因此不能在代码的其他任何地方滥用它。

然后，列出所有规则并应用该列表。

另一个问题是如何处理常量。500000可能看起来不起眼，但是必须非常小心以确保正确转换。如果应用了任何浮点算法，则可能会将其转换为500,000.00001，因此与500,000.00000的比较可能会失败。甚至更糟的是500000总是按预期工作，但是以某种方式转换时565000失败。确保转换是显式的，并且不是由编译器猜测的，而是由您进行的。通常，这是通过在使用之前将其转换为一些BigInteger或BigDecimal来完成的。

尽管问题中没有直接提及，但我想指出重要的是不要掩埋业务逻辑代码中。

像上面的示例一样，对外部指定的业务需求进行编码的代码应该确实存在于源树的不同部分（可能是命名的businesslogic或类似的名称），并且应注意确保其仅对业务需求进行简单，易读且可编码的编码。尽可能简明扼要，尽量减少样板，并提供清晰，有益的评论。

不应将其与实现业务逻辑所需功能的“基础结构”代码混合，例如，attachDocument()示例中方法的实现，或者通常是UI，日志记录或数据库代码。虽然执行这种分离的一种方法是在配置文件中“软编码”所有业务逻辑，但这远非唯一（或最佳）方法。

这样的业务逻辑代码还应该足够清晰地编写，如果您向没有编码技能的业务领域专家展示了该代码，他们将能够理解它。至少，如果以及当业务需求发生变化时，对它们进行编码的代码应该足够清晰，以至于即使是一个事先不熟悉代码库的新程序员也应该能够轻松地定位，查看和更新​​业务逻辑，并假设从本质上讲，不需要任何新功能。

理想情况下，此类代码也将以特定于域的语言编写，以实现业务逻辑与底层基础结构之间的分隔，但是对于基本的内部应用程序而言，这可能不必要地变得复杂。就是说，如果您要将软件出售给多个需要各自定制的业务规则的客户，那么简单的特定于域的脚本语言（例如，可能基于Lua沙箱）就可以了。