什么是“软编码”？

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");
  }
}

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

#1 楼

作者警告不要过早抽象。

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

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

（请注意，在这种情况下，业务分析师/专家对需求的“所有权”通常发生在开发人员从事专家工作的情况下。领域没有足够的领域专业知识；尽管我仍然希望开发人员和领域专家之间能够进行充分的沟通/合作，以防止模棱两可或写得不好的需求。）
对于边缘情况和高度复杂的逻辑，通常没有办法有效地抽象该逻辑或使其更具可维护性。尝试构建抽象的尝试很容易适得其反-不仅浪费时间，而且导致可维护性降低。


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

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

这种情况在定制的法律/金融软件（例如，保险报价逻辑）中经常发生-编写此类文档的人不是工程师，他们没有问题，无需复制+粘贴整个规范，修改一些单词/数字，但大部分保持不变。

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

这种要求的现实是，它们通常不会长时间保持复制+粘贴状态，并且值有时会定期更改，但通常不会一并更改，因此，试图将这些需求合理化或抽象化或以任何方式简化它们最终会导致更多的维护难题，而不仅仅是将需求逐字翻译为代码。

#2 楼

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


另外，明天，政府将“从5/3/2050开始，您需要
添加AUTHLDG-122B而不是AUTHLDG-1A“。


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

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

您如何知道以后不再需要它？还是其他人
？


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

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

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

#3 楼

本文继续讨论“企业规则引擎”，这可能是他所反对的一个更好的例子。它包含自己的编程语言。

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

 <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

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

#4 楼

相反，“ 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。任何其他业务规则更改都将需要甚至更多的工作–配置，文档，代码等


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

#5 楼

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

   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，纯文本等）中进行重复扫描以查找文件修改日期-时间更改。

#6 楼

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

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

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

看看，如果周围有代码，那么显然会发生不好的事情。

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

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

稻草人的唯一解决不透明常量问题的方法是将它们隐藏在某些配置文件中无关的服务。

您可以一起使用这两个谬论来证明任何论点为真。

#7 楼

其中有几个问题。

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

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

允许每个规则具有其自身的有效性，某些规则每年更改一次，某些更改取决于获得许可的时间给定或开具发票。规则本身包含必须应用哪个版本的检查。

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

然后有一个列表所有规则并应用列表。

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

#8 楼

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

像上面的示例一样，对外部指定的业务需求进行编码的代码应确实驻留在源代码树的不同部分（可能名为businesslogic或类似名称）中，应注意确保仅以尽可能简单，可读和简洁的方式对业务需求进行编码，以最少的样板并提供清晰，有用的信息注释。

不应与实现业务逻辑所需功能的“基础结构”代码混合使用，例如示例中attachDocument()方法的实现，例如UI，日志记录或数据库代码。虽然执行这种分离的一种方法是在配置文件中“软编码”所有业务逻辑，但这远非唯一（或最佳）方法。写得足够清楚，如果您向没有编码技能的业务领域专家展示它，他们将能够理解它。至少，如果以及当业务需求发生变化时，对它们进行编码的代码应该足够清晰，以至于即使是一个事先不熟悉代码库的新程序员也应该能够轻松地定位，查看和更新​​业务逻辑，并假设理想情况下，此类代码也将以特定于域的语言编写，以实现业务逻辑与底层基础结构之间的分离，但是对于基本的而言，这可能不必要地复杂内部应用程序。也就是说，如果您是将软件出售给每个都需要自己的自定义业务规则集的多个客户，简单的特定于域的脚本语言（例如，可能基于Lua沙箱）就可以了。