Ruby on Rails adoption to improve product quality?

We开发者_JS百科 are a web development company using php as development language, but we are trying to improve the quality of our code, minimizing errors. We find that PHP makes it somewhat "easy" to produce sloppy code, so we are considering RoR as an alternative. Does RoR help to improve code quality? We want to start using TDD, does RoR help picking up this methodology? In summary, is it worth start training our developers in this new technology or should we keep developing in PHP and invest in improving their PHP skills? We think that a "fresh" start and the reputation that RoR has as an enjoyable language might help in this direction.

update: as @konfoce suggested, maybe I should ask which feature set does RoR offer that may make it a better choice than a PHP framework, as far as helping developers produce quality code? I'm thinking about syntax, TDD integration, helping ensuring DRY, etc

Comparing Rails with PHP isn't very fair on PHP. After all, Rails is a platform, while PHP is a language.

If you compare PHP with Ruby, as a language, well, I personally think Ruby is better. PHP (to me) feels like something that has organically grown from a list of server directives. Ruby seems more cohesive, and as his creator says, it is thought to be enjoyed by the programmer.

Similarly, I can't compare Ruby on Rails with other PHP frameworks, because I haven't worked with any (I'm experienced with Drupal and Wordpress only).

To me, what sets Ruby on Rails apart (although I hear that others are using these ideas now) is:

• The "convention over configuration" idea. On rails, most of the things that would usually be "up to the programmer", like the naming conventions, or where to put initialization code, are set pretty much in stone. This alone helps increase the code quality - different libraries from different teams around the world follow the same set of conventions.
• The idea of beauty. Rails programmers get itchy if they see a method longer than 10 lines. They like it when their programs look like plain English. The code produced this way is the best one I've ever seen. It is short, concise, and complete.
• The test discipline. Seriously, the rails guys take testing to heart. If you find a library or plugin on rails, chances are that it will come with tests embedded on it. And any medium sized project will not accept a patch from you if it doesn't come with tests. Ruby itself (the language) is a language with specs.
• The strive for excellence. The rails community is always eager to improve. And they are not afraid of making backwards-incompatible changes, if that makes code better (see for example the drastic change in the ActiveRecord interface, from rails 2.x to 3.x).

You will notice that I haven't spoken very much about technical features. That's because to me what makes rails great isn't "technical", but "behavioral". The language chosen, or the platform itself, are reflections of a kind of mindset. And that mindset, to me, is rails best feature.

In my opinion, any programmer that gets exposed to this way of thinking will produce better code. If he programs in PHP, he'll just produce better PHP. The only pre-requisites are that he enjoys programming at least a little bit, and he has an inquisitive mind. This is not for code-monkeys that work just to put food on the table.

Would he get the same from other PHP frameworks? I have no idea. Maybe.

If you are concerned about the costs of a complete fresh start, then keep doing what you already know (PHP) to bring money in, but start a small project (maybe an internal one) on Rails. Your PHP code will be gradually better.

... until your developers tell you that they are sick of PHP and they want to do Ruby only :)

Does RoR help to improve code quality?

Not by itself, no. Code quality improves when programmers become proficient in the idoms of the language, and when they use good coding practices. Learning another language (or framework) can certainly help by exposing people to new ways of approaching problems.

We want to start using TDD, does RoR help picking up this methodology?

RoR has excellent TDD and BDD capabilities. But so do other frameworks.

In summary, is it worth start training our developers in this new technology or should we keep developing in PHP and invest in improving their PHP skills?

Those aren't the only choices. I'd say look at how RoR works, build a few test applications, and see if it appeals to your team. You should also look at building MVC applications in PHP (eg: Kohana). You may also want to consider other ways to spend your training budget (like Javascript), which could pay off more quickly.

I find that Ruby on Rails' convention over configuration makes doing the right thing easier. But that certain libraries such as ActiveRecord can make it really easy to do something really expensive without meaning too.

I feel like the primary difference between the two is that Rails is more organized by default and php, being a language not a framework, is not. Which makes it far easier to produce monolithic hunks of code which bloat and bloat and never get fixed. It might be worth investigating some of the MVC frameworks for php before deciding to migrate to RoR. Two of the ones that I tinkered with were Symfony and SolarPHP. CakePHP also aims to be Rails in php but I have not worked with it myself.

I think one of the biggest mistakes a developer can make is trying to learn Rails without first learning Ruby. Trying to learn both at once was extremely counter-productive for me and I fared much better after tinkering in Ruby for a few weeks before even touching Rails.

Rather than switch frameworks and languages, why not try switching frameworks alone?

http://www.symfony-project.org/

Any good programmer can tell you writing code is an art form, and as with most art forms, the key to success is good habits and lots of practice.

The Ruby Learning blog recently posted an interesting list of ways to improve your code quality and, perhaps more importantly, develop habits that will lead to better code creation. Developer James Schorr’s tips range from the obvious, like using a good version control system, to the more subtle: “realize that just because we “can” doesn’t mean that we “should”… anything’s possible, but not everything’s advisable.”

The article is broken into the three major parts of any programming workflow: pre-development, development and post-development. There are a number of great suggestions in each, but our favorite parts are the fourth category: Enjoying Your Development. Almost any project is fun and enjoyable in the beginning, but then there seems to come that point at which the fun evaporates and we get bogged down in the grunt work of writing code. Schorr has few tips to help break you out of those boring stretches:

Give yourself time to think and rest. There are some days where I just can’t write code well; other days where it’s just flowing. This is due to how your brain functions. You need sleep and a change of pace and scenery now and then.

Walk away for a while. It’s easy to get “tunnel vision” and think that you’re close to solving a problem and to think that more effort will solve it… You would be surprised at the ideas or solutions that will spring into your mind as you are thinking about or doing other things.