生成代码的价值是否如此灵活，以至于永远不需要更新？

Question

我目前正与我的同事讨论如何设计一个将由我的部门使用的API。具体来说，我的任务是编写一个API作为包装器 facade 来访问Active Directory信息 - 根据我公司/部门的需求量身定制。我知道开源包装器 外观已经存在，但不是这个问题的症结所在，仅用作示例

当我向我的团队提交我的设计方案时，他们让我失望，因为API不够“可配置”。他们声称他们不希望API在“电话号码”和“电话号码＆gt;的隐藏式Active Directory表示”之间建立链接。会议中的每个人（除了我）都同意他们更愿意四处询问，“Active Directory中用于用户电话号码的正确字段是什么？”，并将其插入各自的应用程序（LOL！）。

他们问我，“如果我们公司决定使用不同的字段来获取电话号码并且您不在 源代码中进行更改，该怎么办？”他们最终承认他们 害怕 负责更改其他人的源代码，即使代码是原始的并且进行了大量的单元测试。我所在部门的每个高级IT人员都同意这一点。

这个真的在设计软件时是否有正确的态度？！

Answer 1

http://en.wikipedia.org/wiki/Inner_platform_effect

虽然在程序中硬编码过多的假设是不好的，但过度使用硬编码假设可能同样糟糕。如果您尝试使代码过于灵活，则基本上无法进行配置，因为配置方案本身几乎成为一种编程语言。我认为一般来说，电话号码是一个很常见的东西，它只能被硬编码为一个字段。

Answer 2

如果我理解正确，他们希望可以选择在代码外部映射链接，无论是通过配置文件，数据库等等。如果这是正确的，我认为他们有一个有效的观点 - 如果您需要做的就是更改配置映射，为什么要强制更改任何代码。

Answer 3

如果可能的话，你应该始终错误更容易配置。它会在以后节省您的头痛。

列名

特别是在您的情况下，表中的列是一个固有的非静态变量。它们通常会随着您的需求变化而变化。

如果您有“ phonenum ”列，那么他们会添加第二个电话号码，他们会将列更改为“ phonenum1 ”和“ phonenum2 ”。它需要在代码中进行更改。然后，如果他们将其更改为“ Home_Phone ”，“ Work_Phone ”，“ Cell_Phone ”，则必须再次更改代码。但是，如果您有一个映射文件（一个键/值配置文件），那么所有这些更改都非常简单。

一般

我不同意dsimcha一个应用程序可以“太可配置”。他所谈论的是“特征臃肿”，其中有许多相互交织的配置，如果没有充分利用其他所有配置，就无法改变任何一个。这是非常现实的问题。但是，问题不在于配置选项的数量，问题在于它们如何呈现给用户。

如果您以简洁，清晰，简化的方式呈现所有配置选项。应该有评论来解释每一个，以及它如何与其他人互动。在这种情况下，您可以拥有任意数量的配置变量，因为您已经小心地将它们分隔为单个或成对，并将它们标记为这样。

您应该编写应用程序，以便外部（环境）更改不需要更改代码。

之类的东西

• 数据库用户密码更改
• 列名称更改
• “临时文件夹”位置更改
• 目标计算机名称/ IP更改
• 应用程序需要每天运行两次而不是一次
• 记录级别

这些更改都不会影响应用程序的功能，因此不需要更改代码。如果您想知道硬编码是否可以，那么您应该使用该指标。

如果功能需要更改，则应该是代码更改。否则，使其可配置。

Answer 4

如果您说“我应该硬编码所有内容”，那么我认为这不是一个好主意。

在2年后你将会离开，并且会有一个程序员在更新配置文件时会浪费大量时间来更新遗留代码。

在某些情况下，硬编码信息是有意义的，但我不认为您的情况是这些情况之一。我需要更多关于这种情况的知识，这只是我对你说的话的猜测。

Answer 5

同样容易做到这两点：生成一个灵活的API，允许指定字段，然后是一个包装器，它知道隐藏的ActiveDirectory名称。

当然，您可以以后构建这个灵活的解决方案，并暂时对该名称进行硬编码。如果这比双管齐下的方法要容易得多，那么争论它是合理的 - 但是如果你最终可能在内部进行那种分离，那么揭露它并没有多大的危害。

Answer 6

我可以诚实地说我以前一直在你的位置，我同意他们向你提出的论点。特别是对于内部应用程序，您将看到功能蠕变。应用程序越有用，功能越蠕动越严重。您的应用程序可能会在另一个办公室中使用，并且它们的字段映射方式与您当前的办公室不同。如果你硬编码映射，那么你会遇到不同版本的不同版本。维护单独版本的源代码很快成为程序员的噩梦。如果您现在设计的可配置性和您的应用程序被遗忘，您的损失很少，但如果您的应用程序成为整个公司的标准，那么您将来会为自己节省大量时间。

Answer 7

在IT软件组织中，对变革的恐惧以及对进行变更的责任感的恐惧并不少见。通常，组织中的文化是推动这种态度的原因。

话虽如此，在您的具体示例中，您描述的是一个在ActiveDirectory服务之上提供外观的API - 一个似乎打算供组织中的不同组和/或项目使用的外观。

在该特定场景中，将API支持的一部分配置为有意义，因为您最终可能会发现不同项目或组的要求可能不同，或者随着时间的推移而变化。

作为一般惯例，当我构建涉及一个编程接口到另一个编程接口的映射的代码并且涉及数据映射考虑时，我尝试使映射可配置。我发现这有助于单元测试以及处理不断变化的需求或来自不同消费者的矛盾要求。

Answer 8

我认为这取决于创建API的原因，以及您希望解决的问题。如果API的目标是作为服务器存在于某个服务器上并管理来自不同应用程序的请求，那么我认为您的方法可能是可行的方法，可能需要添加数据库或配置文件来定制LDAP某些属性的路径。

但是，如果API的目标是简单的一组类来抽象出访问Active Directory的细节，而不是访问哪些属性，那么你的同事指定的是要走的路。< / p>

这两种方法都不一定正确或错误，因此最终取决于您首先创建API的总体原因。