开发者

Rails best practices to build activable (or not) features?

OK let's assume I have an awesome looking rails app with somes Posts, which can be commented and voted on. It's online and people love it.

Now imagine a client comes up and tells me "Hey, this app looks good ! Could I have just the same one, but with my logo and votes also on comments ?"

So ok I clone the app, make the changes, then I deliver the tweaked app to the client, and then I get back to my original app and continue to make it better.

A couple on months later another client come and also wants the same app (now improved) but with votes also on comments.

Of course I realize cloning the app in the first place was not a clever idea.

What I'd like to know is how would you do from the beginning to make it as easy, maintainable and DRY to reuse the feature made for the first client in the second's project ?

Then imagine l开发者_如何学Cots of clients come with lots of different requested features. Now you realize it would be just awesome to be able to 'build' a new app with just this feature or this one, but not this one, and so forth.

How would you achieve that ?

I imagine git branches could be a nice way to achieve that, or maybe Rails Engines/Gems, or I don't know, but I'm definitely not git or rails skilled enough to clearly see the hole picture.

Thanks !


We've had the same situation in our firm and we've done a number of different things to make our development more modular.

For one, we use a few internal gems and Rails engines. For example, we developed a blogging engine that we launch with pretty much every project.

Another option might be concerns. For example, you could extrapolate the commenting system into a concern and just port that over to the other projects with similar needs.

Alternatively (and, perhaps, my least favorite option) would be to maintain a few git repos with each feature and use git modules to add them to your project.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜