CODEWITHSUNDEEP
ruby-on-rails
fujisan
fujisan

Reputation: 221

RoR: Large Project Management. Need help from RoR Seniors that have worked on large projects

I am currently working on a large project. It is already lunched but the problem is users are already using the app and having very erroneous results. They don't complain much but each and every day I am receiving emails on errors and improvements.

I would appreciate some help in deciding weather to debug the app or just create another one. I'm working on a rails 2.5 app with old plugins.

And I'm the only one doing all this. T.T

Upvotes: 0

Views: 195

Answers (2)

Maddy
Maddy

Reputation: 1243

Fujisan I am in the exact situation as you are. I think it is best to first debug the current rails app and then think about rebuilding it. If you are rebuilding the rails app it takes more time than expected. I started out like this:

  1. Created a separate database and repository which has the same code and data that pulls from the live website. I use this website to work with the bugs and not on the live site.
  2. First started off knowing what models are present and started with user model. It is best to use the rails console and dbconsole in this step if you havent used them before. It is easy to find the dependencies from the console with ruby.
  3. Just tweaked around the models and found the relations between different models. After the models looked at the controllers. Now once I have an idea of what is happening in the application I started with a sketch of the purpose of each model and what it is doing and how and why the dependencies are made.
  4. FInally went with working on the bugs and suggestions. The major hurdle was with gems. When the website was created by seniors the gems were very active and now they are all orphaned. This makes it hard to get answer to any of the bugs that are persisting because of those gems.

Railscasts are your best friends!

I hope that helped. Good luck!

Upvotes: 0

Keith Gaddis
Keith Gaddis

Reputation: 4113

Its really tempting on a project like you describe to toss out old code and rewrite, but its almost always a mistake (see http://en.wikipedia.org/wiki/Second-system_effect. links at end regarding rewrites are invaluable, especially http://chadfowler.com/2006/12/27/the-big-rewrite).

I'm guessing you don't have any real test suite in place, or it'd be easier to track down problems and you'd probably have a smaller project as well-tested projects tend to be well-factored (though not always). That's going to make it very difficult to reimplement and have any assurances that you've replicated all the functionality and that any dependencies work well with the "new and improved" code.

And if your users are getting erroneous results, I'd venture to say you don't actually know what the problem is, so a rewrite isn't going to fix that.

When I take over a project like this, step one is to write a suite of characterization tests, documenting the way I think the system is supposed to work AT THE PRESENT TIME. Often in doing so you'll uncover a piece of functionality that doesn't make sense or is inconsistent with the rest of the system—that may well be where your problem is. Once we're through that phase, we can start refactoring the ugly parts, cleaning up views, moving logic to someplace it belongs, removing dead code, etc. But those tests are really important to have if you want to keep the system functioning.

Finally, set reasonable expectations for yourself. Projects like this don't turn into messes overnight—you can't fix them overnight either.

Upvotes: 2

Related Questions