Rails Organization

I’m just starting so forgive me for beginner questions…
When you have a team of programmers developing something in RoR, how is
the s/w organized? Is there a common class library? Before writing
something new do the programmers consult what already exists? Can you
please elaborate on methods of organizing the s/w, making sure only good
OO code is written, how reviews or unit tests are done? Thanks!

Larry H. <lists@…> writes:

I’m just starting so forgive me for beginner questions…
When you have a team of programmers developing something in RoR, how is
the s/w organized? Is there a common class library? Before writing
something new do the programmers consult what already exists? Can you
please elaborate on methods of organizing the s/w, making sure only good
OO code is written, how reviews or unit tests are done? Thanks!

Rails provides a well fleshed out framework for your code. Almost
everything
has a natural place to live following MVC and Rails conventions. This
might
be what you are refering to as “a common class library”.

When programmers start creating code it will naturally fall into
locations and
files. Programmers joining a team should be able to find the code they
are
looking for by following Rails conventions and inspecting the files
created.
This also goes for tests, which by default use Ruby’s built in “unit
test”
frame work.

Ruby treats everything (everything!) as an object, so you do not have to
worry
about ensuring the code is OO - although individual programmer can break
this
by passing variable around instead of the objects themselves.

Lastly, the biggest hurdle within a team environment is source control.
There
are many source control solutions out there, but the Ruby community has
settled on git due to its flexibility and power. The more important
underlying quesiton is how to ensure updates to your central cose
repository
do not break the application - and again, this is where a good test
framework
comes into play.