Refactoring Advise

I have a question about refactoring, I just joined a company with a
rails 2.3 code-base (pretty large and not many tests) this site has a
user facing site, but the bulk of the functionality is for the admin
facing portion of the site, I want to build a nice API with OAuth as
well as make it easier to maintain and push the user facing portion
forward, should I just try to build it on top of the existing rails
2.3, should I create a new site for the user and api portion on top of
rails 3.1 (not sure how I would share the models and other logic
between the two though), or some other method? ANy best practices
here?

On 2 December 2011 14:08, Rog [email protected] wrote:

I have a question about refactoring, I just joined a company with a
rails 2.3 code-base (pretty large and not many tests) this site has a
user facing site, but the bulk of the functionality is for the admin
facing portion of the site, I want to build a nice API with OAuth as

That’s not “refactoring” - that’s writing new functionality.

ANy best practices here?

Good practice would be to get buy-in from your employers; explain to
them the reason for your desire to spend time on this development, and
explain about the benefits they’ll gain. If they don’t want you to do
it, then it’s likely to be moot.

If you’ve not done so already, read the “Refactoring: Ruby Edition”
book, and start to try to apply its principles.

Thanks a lot Michael, if I can get sign-off what would be the right way
to
go about separating code. Try to leave the admin app alone and move the
user facing and api app to rails 3.1 ? Would I then need to make a
plugin
for the models so I can share them between apps? Or should I use Engine?

Thanks,

On 2 December 2011 16:37, Roger R. Smith [email protected] wrote:

Thanks a lot Michael, if I can get sign-off what would be the right way to
go about separating code. Try to leave the admin app alone and move the user
facing and api app to rails 3.1 ? Would I then need to make a plugin for the
models so I can share them between apps? Or should I use Engine?

I have no idea - it really depends on your codebase.

It might be a good plan to see if it’s possible to bring the whole app
up to Rails 3.x, and the starting place for that might be to spend
some time getting good test coverage in place.

On Fri, Dec 2, 2011 at 8:50 AM, Michael P. [email protected]
wrote:

… and the starting place for that might be to spend some time
getting good test coverage in place.

s/ might be / is definitely /

As someone who’s taken over existing apps with little or no test
coverage (and would prefer not to repeat the experience!), I can
assure you that filling in that gap before you touch anything will
make your life more pleasant :slight_smile:

And if there aren’t many tests, there’s a good chance you’ll find
code that would benefit from refactoring anyway, which will make
it easier to separate out or upgrade, whichever you choose.

FWIW,

Hassan S. ------------------------ [email protected]
http://about.me/hassanschroeder
twitter: @hassan

Thanks Hassan, I appreciate it. Once I do get that test gap filled out
based on your experience what would be the best way to move forward:

  1. move the models to a plugin?
  2. use Rails Engine?
  3. re-write everything?
  4. build the api/new user interface on top of the existing app?

Thanks a lot.

On Fri, Dec 2, 2011 at 12:10 PM, Hassan S. <

On Fri, Dec 2, 2011 at 10:04 AM, Roger R. Smith [email protected]
wrote:

based on your experience what would be the best way to move forward:

  1. move the models to a plugin?
  2. use Rails Engine?
  3. re-write everything?
  4. build the api/new user interface on top of the existing app?

I think it’s hard to say definitely without knowing more about the app,
but my inclination would be to upgrade the whole thing to 3.1, which
will also give you the opportunity to clean up the code.

Then you can take advantage of the Engine/mountable app approach
if it still makes sense. It seems like that would depend on the degree
of coupling between the admin/user/api parts, but – by the time you
finish writing tests and upgrading, you’ll be in a much better position
to
evaluate that :slight_smile:

HTH, and good luck,

Hassan S. ------------------------ [email protected]
http://about.me/hassanschroeder
twitter: @hassan

Thanks for your help. When you do the engine/mountable app do you have
to
copy the codebase from one into the other or can you simply reference
the
other codebase? If upgrading the existing app is too much, do you have
any
other recommendations for user/api app moving forward?

Thanks

On Fri, Dec 2, 2011 at 1:41 PM, Hassan S.
<[email protected]

I believe you should refactor your app to rails 3.1 and then build a
nice
API.

2011/12/2 Rog [email protected]


You received this message because you are subscribed to the Google G.
“Ruby on Rails: Talk” group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.


Taffarel de Lima Oliveira (Taffarelo3)
*
*
Desenvolvedor Web

On Fri, Dec 2, 2011 at 10:44 AM, Roger R. Smith [email protected]
wrote:

Thanks for your help. When you do the engine/mountable app do you have to
copy the codebase from one into the other or can you simply reference the
other codebase? If upgrading the existing app is too much, do you have any
other recommendations for user/api app moving forward?

I’d be willing to bet that once you’ve got a full set of tests written
and
done the inevitable cleaning up and refactoring, these questions will
be a lot easier to answer, if they’re still relevant :slight_smile:


Hassan S. ------------------------ [email protected]
http://about.me/hassanschroeder
twitter: @hassan

Thanks Taffarel, and when the move to 3.1 is complete you think it best
to
leave the admin, user and api all in the same app is best since they use
the same models etc? Or try to somehow separate out out into different
apps
somehow Luke SOA model?

Rog

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs