【问题标题】:Rails best practices to build activable (or not) features?Rails 构建可激活(或不可激活)功能的最佳实践?
【发布时间】:2011-09-10 10:59:05
【问题描述】:

好吧,假设我有一个很棒的 Rails 应用程序,带有一些帖子,可以评论和投票。它是在线的,人们喜欢它。

现在想象一个客户过来告诉我“嘿,这个应用看起来不错!我可以拥有相同的应用,但我的徽标和投票也在 cmets 上吗?”

好吧,我克隆应用程序,进行更改,然后将调整后的应用程序交付给客户,然后我回到原来的应用程序并继续改进它。

几个月后,另一个客户来了,也想要同样的应用程序(现已改进),但也在 cmets 上投票。

当然,我首先意识到克隆应用并不是一个聪明的主意。

我想知道的是,您将如何从一开始就使在第二个项目中重用为第一个客户制作的功能变得简单、可维护和 DRY?

然后想象一下,很多客户都有很多不同的请求功能。现在您意识到能够“构建”仅具有此功能或此功能的新应用程序真是太棒了,而不是这个功能等等。

您将如何实现这一目标?

我认为 git 分支可能是实现这一目标的好方法,或者可能是 Rails Engines/Gems,或者我不知道,但我绝对没有足够熟练的 git 或 rails 来清楚地看到漏洞图片。

谢谢!

【问题讨论】:

    标签: ruby-on-rails-3 modularity application-design


    【解决方案1】:

    我们公司也遇到过同样的情况,我们做了很多不同的事情来使我们的开发更加模块化。

    首先,我们使用了一些内部 gem 和 Rails 引擎。例如,我们开发了一个博客引擎,几乎每个项目都会启动它。

    另一种选择可能是担忧。例如,您可以将评论系统外推到关注点,然后将其移植到具有类似需求的其他项目。

    另一种选择(也许是我最不喜欢的选择)是为每个功能维护一些 git 存储库,并使用 git 模块将它们添加到您的项目中。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-02-03
      • 1970-01-01
      • 2021-05-05
      • 1970-01-01
      • 1970-01-01
      • 2016-12-28
      • 1970-01-01
      • 2017-01-12
      相关资源
      最近更新 更多