我一直有一个朋友，我有一个库（它的Python，但我没有把它作为一个标签，因为这个问题适用于任何语言）有一些依赖关系的辩论。争论的是在初始化中提供默认环境还是强制代码的用户明确设置一个。我应该使用我的图书馆为某人默认环境吗？
我的意见是强制用户明确，避免混淆，并说明他们指的是什么。
我的朋友这是更安全，更方便的默认环境，并让用户覆盖，如果他想。
想法？流行的库中是否有任何好的参考或例子/模式支持我们的论点？还有，讨论这个API设计要点的任何流行的博客或文章？
我没有任何参考，但这里是我作为该图书馆的潜在用户的想法。
我认为最好有一个默认配置可供开发人员快速评估库。我不想通过一堆配置来查看库是否能够满足我的需求。一旦我很高兴图书馆会做我想做的事情，那么我很乐意按照自己想要的方式进行配置。
一个很好的例子是微软的ASP.Net MVC框架。当您创建一个新的MVC项目时，它会挂载默认的身份验证和成员资格提供程序，从而使开发人员能够快速启动并运行正常运行的应用程序。如果默认的提供商不符合相关应用的要求，那么配置不同的提供商也很容易。
作为一个稍微不同的例子，Atlassian Confluence是支持许多不同后端数据库的wiki软件。 Atlassian本可以选择没有默认的数据库配置，但是相反，Confluence提供了一个默认的，简单的基于文件的数据库，以允许用户评估软件。对于生产安装，您可以连接到Oracle，SQL Server，mySQL或其他任何你喜欢的东西。
有些情况下，图书馆的默认配置文件没有意义，但我认为这将是一个特例，而不是一般规则。
这取决于。如果您可以提供合理的默认设置，您可能需要这样做：它会让图书馆的偶尔用户生活更加复杂，因为他们只能设置相关设置，而不是整个环境（可能会设置它们的影响不完全理解（还））。你是对的，在这种情况下，这可能会导致沮丧和困惑，因为默认设置可能会导致意外的行为（用户（没有经验）的用户意想不到） - 你必须权衡减少的便利性与未付费的价格之间的沮丧，了解默认设置，以便为这些可能的默认设置中的每一个做出选择，哪个选项可能会影响其他相关设置的选择
另一方面，如果没有合理的默认设置（例如DB凭据，远程地址），您应该要求用户提供这些设置。
这两种情况下的关键是在库的文档和错误消息（无论是缺少设置还是相互冲突）中提供足够的信息，以便用户可以弄清楚这些设置实际上意味着什么，而无需阅读库的源代码。这一部分很难，因为1）从图书馆开发人员的角度来看，这是非常乏味的（所以经常被忽略）和2）文档必须从新手的心态写入图书馆，这通常是不同的从图书馆开发人员的想法 - 后者知道隐含的联系/含义，前者必须以可理解的方式告诉他们。
虽然在问题域方面并不完全相同，但这引起我作为Convention over Configuration参数。
近年来，CoC背后的发展势头很猛，在我看来，它有很多意义。只要灵活性不会丢失，你就能获得一切。降低摩擦的发展是我们所有人的事情，如果我必须配置API的各个方面才能使其发挥作用，那么我不太倾向于将它用于具有相同功能的其他API。
我碰巧喜欢Hanselman的播客，所以如果你想要一点点聆听，请查看this podcast。
我认为你的问题需要一些澄清。对于初学者，我不认为库应该有任何运行时配置。就依赖性而言，应该以适合其编写环境的方式来处理库依赖性。在python中，这些依赖关系应该在setup.py文件中（根据需求），并且最终该文件应该满足您计划使其可用的所有服务（即python的pypi）的要求。
对于应用程序来说，要求运行时配置是完全可以的，但您应该尝试设置合理的默认值。如果您的应用程序依赖于库，那么即使该信息在安装程序的上下文中可能是多余的（如果需要），也应按照处理库依赖性的方式处理该依赖性。大多数情况下，第一次运行的脚本和它们的流派应该是安装程序/ rpm的一部分。
对于Web框架，通常应用程序会携带配置，并且可能需要以与传统应用程序不同的方式进行安装。在这里，你可以做的唯一事情就是尽量遵循你正在编写的任何框架的约定。
类似的思考http://stackoverflow.com/questions/1166539/do-you-find-convention-over -configuration-good-or-bad – mguymon 2012-03-17 07:46:06
@mguymon - 我认为它是一个稍微不同的话题。 – leora 2012-03-17 12:46:14
目标受众是另一个需要考虑的重要因素。一个公司内部对网络上的任何人是内部的东西吗？对于有设计师思维和工程思维的用户？等等。 – 2012-05-03 16:07:31