首先，我100％赞成公约和整个团队的遵守。但是，我正在研究框架（主要是各种PHP，但也包括Ruby on Rails和其他），它们几乎按照惯例强制执行编码。从表面上看，这看起来很棒，因此URL可以直接翻译为/controller/action。模型以DB表命名，系统确切地知道使用非常简单的自动加载器从何处加载所有文件。
但是，我们运营的是一个白标平台，对大多数客户来说有效的方法并不一定适用于其他客户。有些可能需要特定的URL模式，因此我们需要自定义路由。有些可能要求页面的布局与其他客户端的布局完全不同，因此我们最终会使用自动加载器，它始终检查区域特定版本的文件是否存在，如果需要则回退到默认值。这使得开发对我们来说非常简单，因为我们只是将适当命名的文件放到适当位置然后就可以了。但由于这是需要这些情况的少数情况，我们发现自动加载器花费了大量时间来检查几乎可以保证丢失的文件。
为了改善这种情况，我考虑在惯例上添加配置，因此偏离规范的区域将在配置文件中找到必要的覆盖并直接转到正确的文件，删除所有现有文件检查，我收集的不是非常有效（特别是当一些页面需要数百次调用自动加载器）。我想我们仍然会默认使用约定，但允许配置在必要时接管。
我很想知道这是一个实用的，甚至是推荐的解决方案
答案 0 :(得分：2)
Rails主要以这种方式工作。你有这个约定，但是所有东西都带有可选的参数，你可以根据需要改变它。有一个遗留数据库，其中唯一的ID未命名为id，正如Rails所期望的那样？告诉Rails这个名字。你的路线不同？您仍然可以编写自己的匹配器。在保存记录之前要做些什么？只需加入before_save。
其他一切事情都有效。你有更多的工作要声明所有不同的东西，但你必须为此编写一些代码。
我们在一个稍微不常见的环境中使用Rails，我们需要使用来自ERP系统的数据并使用未与Rails完全集成的其他系统，但它仍然需要花费很多工作才能完成。
但显然只有所有系统都有足够大的核心内容才有意义，特别是如果你打算从头开始写一些东西。增加不会破坏事物的灵活性需要仔细规划。
答案 1 :(得分：1)
在我们的应用程序中，我们使用了配置和约定，但配置略多于后者（在某些区域，反之亦然），这是因为你几乎总是会遇到你的约定没有使用的情况你的现实世界要求。
如果是这种情况，要么您的约定不适合您的架构和客户端，要么您的用例太多，以至于约定不能一致且可靠地使用。
您可以改进您的约定以满足您的应用程序要求，但我认为在您的组合中添加一些配置可以带来您可能缺少的订单。我喜欢的约定是它在某些情况下类似于魔术......但是，在任何合理大小的开发环境中工作都很难实现。
你的想法很实用，如果鞋子合适，我甚至会推荐它。
答案 2 :(得分：1)
“必须编写程序供人们阅读，并且只能偶然为机器执行。”
- Hal Abelson，计算机程序的结构和解释
你可能不喜欢我要说的话，但有时表现不是问题。我会坚持使开发人员满意的解决方案。如果有一个简单的约定，你最好坚持下去，而不是创建一个复杂的配置机制。这里没有灵丹妙药，但在我看来，你只需将一个约定（这里和那里的地方）替换为另一个（将这些配置放在这里，这些 - 这里）。是否会更难遵循？大概。您可以轻松使用它。
而且，一如既往，让同事们开心。或者他们会找到你。吃你用讨厌的评论覆盖你的代码（这是最糟糕的部分）。