2

Firstly, I'm 100% in favour of conventions and an entire team complying. However, I'm looking at frameworks (mostly various PHP but also Ruby on Rails and others) that pretty much enforce coding by convention. On the surface this seems like a great thing, so URLs are directly translated to /controller/action, for example. Models are named after DB tables, and the system knows exactly where to load all files from using a really simple autoloader.

However, we operate a white-label platform and what works for most clients doesn't necessarily work for others. Some may require a particular URL pattern, so we need to customise routes. Some may require that pages have a completely different layout to what other clients have, so we end up with an autoloader that is always checking whether zone-specific versions of files exist first, and fall-back to default if required. This makes development REALLY easy for us, because we just drop an appropriately named file into place and away it goes. But since it is the minority of cases where these are required, we find that the autoloader is spending an inordinate amount of time checking for files that are almost guaranteed to be missing.

To improve the situation a little, I was considering adding configuration over convention, so the zones that deviate from the norm would find the necessary overrides in a configuration file and will just go straight to the correct file, removing all of the existing-file checks, which I gather isn't terribly efficient (especially when some pages require hundreds of calls to the autoloader). I guess we would still be using convention by default, but allowing configuration to take over where necessary.

I'm interested to understand whether this is a practical or even recommended solution

4

3 回答 3

2

Rails 主要是这样工作的。您有约定，但所有内容都带有可选参数，可让您根据需要进行更改。有一个遗留数据库，其中唯一 id 没有id像 Rails 所期望的那样命名？只需告诉 Rails 名称即可。你的路线不一样？您仍然可以编写自己的匹配器。在保存记录之前有什么事情要做吗？只需钩入before_save.

对于其他一切，一切正常。您需要做更多的工作来声明所有不同的东西，但无论如何您都必须为此编写一些代码。

我们在一个稍微不常见的环境中使用 Rails，我们需要使用来自 ERP 系统的数据并使用未与 Rails 完全集成的其他系统，但它仍然需要大量的核心工作。

但显然，只有当所有系统都具有足够大的核心时，它才有意义，特别是如果您打算完全从头开始编写一些东西。添加不会一直破坏事物的灵活性需要仔细计划。

于 2014-02-14T10:37:32.783 回答
1

“必须编写程序供人们阅读，并且只是偶然地供机器执行。”</p>

― Hal Abelson，计算机程序的结构和解释

您可能不喜欢我要说的内容，但有时性能不是问题。我会坚持让开发人员满意的解决方案。如果有一个简单的约定可以遵循，你最好坚持它，而不是创建一个复杂的配置机制。这里没有灵丹妙药，但在我看来，您只需将一种约定（将其放在此处和彼处）替换为另一种约定（将这些配置放在此处，而将这些 - 放在此处）。会不会更难追？大概。它在您的手中，使其易于使用。

而且，一如既往，让你的同事开心。或者他们会找到你。并且吃掉你。并用讨厌的注释覆盖您的代码（这是最糟糕的部分）。

于 2014-02-14T10:54:55.183 回答
1

在我们的应用程序中，我们同时使用配置和约定，但配置比后者稍微多一些（在某些领域，情况正好相反），这是因为您几乎总是会遇到约定与现实世界不符的情况要求。

如果是这种情况，要么是您的约定不太适合您的架构和客户端，要么是您的用例过于多样化，以至于约定无法一致且可靠地使用。

您可以改进您的约定以满足您的应用程序要求，但我认为在您的组合中添加一些配置可以带来一些您可能缺乏的顺序。我喜欢约定的地方在于，它在某些情况下类似于魔术……但是，在任何合理规模的纯约定开发环境中工作都会很困难。

你的想法很实用，如果鞋子合脚，我什至会推荐它。

于 2014-02-14T10:40:31.423 回答