Structuring two similar projects

[Paul]

I've just about "completed" a fairly large Rails project for a customer. He then sold the idea to someone else, so he's come back and said, "We want practically the same program except for a different logo. And with a change to this feature, and a change to that feature, etc..."

If I believed that the two websites were actually going to be practically the same I'd just implement them both in the same codebase, but I think the two programs are going to drift significantly.

I think the best way to handle this is to just fork the project and let them vary. The advantages are that we don't have to do any retesting of project #1 as project #2 is being developed, and I won't have a bunch of conditionals scattered around making the code hard to read. The disadvantages are that fixing a bug in one program has to be manually fixed in the other. And the same functionality is likely to be implemented slightly differently in the two programs over time.

I was also thinking about extracting the really common, unlikely to change part to a gem so that at least some of the code is in common. The trick is to figure out what code gets put in the common area.

I also considered breaking the project into a bunch of small projects so that they can be mixed-and-matched. That seems like a nightmare to keep straight, though.

Any thoughts?

[Charles Feduke]

I think you're on the right track with extracting to gems, especially for shared Ruby code like controllers or the domain layer.

The more important question here is probably: do you have more Ruby code or more Javascript code in the applications?

The difficulty arises when you need to do things with views. I've only ever done this with toy projects but found that views are probably the most frustrating thing since they are what's most likely to be different between the two systems (beyond the default layout). You may be able to get away with some default views offered by a gem and the ability to execute generators to extract the view templates into the project for editing but at that point you're diverging the view code anyway (and could have to double fix bugs).

There are at least a couple Rails CDN projects that might give you a good idea how to structure the user facing components.

José Valim's Crafting Rails [4] Applications has some really good lessons on Rails internals that might help you out with structure too. (I've only read the first edition, it was excellent.) For example, he goes into details on how to put views in a database instead of the filesystem - not that that is necessarily a good idea, but knowing how to wire that up might help you be able to solve componetization better.

The alternative is, as you've mentioned, code duplication and double fixing bugs. However that may be the right decision, in terms of time and maintenance.

--
You received this message because you are subscribed to the Google Groups "Ruby Code Jam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyjam+unsubscribe@googlegroups.com.
To post to this group, send email to rub...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyjam.
For more options, visit https://groups.google.com/d/optout.

[Keith Bennett]

IMHO you're asking yourself all the right questions and are already aware of the tradeoffs.

Is the client aware of how much money could be saved by keeping the code bases as similar as possible?

- Keith

To unsubscribe from this group and stop receiving emails from it, send an email to rubyjam+u...@googlegroups.com.

[Paul]

Well, the client won't care how we internally structure this. He will get requests for changes from his clients and want us to be able to vary the two projects however it is needed. The trick is to predict how much will really end up being different.

Actually, most of the code is javascript. I think that the ruby code won't change much at all. It's a single-page app, so in the route.rb file there are just a bunch of lines where the route is directed to the same controller. The views, helpers, css, and javascript will change, but I bet the controllers and models won't.

So, the interesting thing about creating a gem is that the common code is the basic architecture: the controllers, models, and the generic javascript modules.