将一个非常大的php代码库迁移到rails的理想选择是什么？

im just soliciting opinions/advices. Like we have this really large PHP code base, by large these are what i meant:

over 500 tables over 4000 files - action, displays & templates. over 1,000,000 lines of code - this software spans more than 8 years already.

So many deprecated, duplicated code all over the place, and so many hacks.

I want to be able to still run the software, while parts of it are being migrated to rails.

So it will be running in hybrid mode, that is, both PHP and rails at the same time. Parts of the software that hav been migrated already, will start using the Rails version.

I suppose my idea is:

  1. migrate to Git
  2. I suppose all the more than 500 tables remain.
  3. Find a way so PHP and rails will interoperate?
  4. Chew one display & management screen at a time?
  5. Work on the front end?

I expect such a thing is going to be toff. Anyway let me try to give some advice.

  1. Build both basic "runnable" applications.
  2. Make sure that both applications can access the same database, the same session sources, the same cache and so on. Here'll you have to make sure that that your data sources are compatible to both your applications. For example: you could migrate your user sessions to the database.
  3. Build an extra routing component (in mod_rewrite, PHP or whatever you like) to start routing several pages to your Ruby application instead to PHP. Test it thorougly. Build the router in such way that it can function in development mode as well as in production mode.
  4. Slowly start adding routes to your router for added components in your Ruby application.
  5. When you've completely migrated, change the default route to your Ruby application. You can start using Ruby-specific data sources now.

While I'm far from convinced that migrating from PHP to Ruby will make your life any easier, I think there is a very strong case for mapping out the dependencies within the current codebase.

  • Which PHP scripts are entry points to execution (i.e. map directly to URLs)
  • which PHP files are included by other scripts (and which are they)
  • which templates are used by which URL
  • which scripts access which tables

That will at least allow you to divide the exercise up into discrete chunks. Note that in some cases it may be a good idea to rewrite the PHP / DB as an interim measure instead of going directly to Ruby, e.g.

  1. If there is scope for amalgamating several database tables - then do so - and create views on the resulting table named according to the replaced table.

  2. If needed, try to re-implement every entry point PHP script as 'index.php' in its own directory - and always reference the script by the directory. That way you can transparently start replacing components written in a different language.