Is Ruby on Rails Maintainable?

kale77in asks: "I've become a big fan of Ruby over the past few months, but I'm not at all sure about Ruby On Rails. Automatic code generation sets of alarm bells in my mind; so that, to RoR's promise of 'Web Development that Doesn't Hurt', I automatically add '...until you have to maintain it'. On the other hand, some writers and coders I respect (like the Pragmatic Programming mob) seem to be fans. I've mainly written generators in Python, to produce PHP/SQL/Java from SQL files, but I've always gone back to well-constructed objects, where extension and overloading offers more precise and maintainable customization than auto-generation allows. So is Rails just a nice RAD tool for disposable, cookie-cutter apps (which have a place, of course)? Is high-level generation just a bad OO substitute? And what has your experience of Rails' maintainability been?"

Comments

It's obvious...

[eruanno]

It's quite obvious that the concept of the automatic code generation done in Ruby On Rails was either not completely grasped or completely missed by the author. The whole purpose of the code being generated was to give you a basic structure to take and change until it was what you needed it to be. This is precisely why it is called 'scaffolding', because it gives you the framework to get started with.

As far as the Ruby On Rails framework itself is concerned, it is extremely capable and flexible for handling a great deal of web application projects. Of course there will be specific functionality that Ruby On Rails will not handle very well — there never are perfect solutions.

I wouldn't consider the reviewers objections completely devoid of import, just misguided. You must always be careful about anything you didn't do yourself, but you must exert the same care and attention to the stuff that you do create yourself! Often we put far too much confidence in our own coding skills.

So, in the end, the concept of Ruby On Rails is simply to alleviate the mundane, rote programming that goes into the basics, particularly the structure and minimalistic database interaction, and make it surprisingly simple.

M.T.

Re:It's obvious...

[qslack]

This is exactly right. The scaffolding is seen as the major feature of Ruby on Rails by far too many people. It's not. In fact, if anyone were making a serious, production-level app, they wouldn't even use the scaffolding. It serves only three purposes: to help newcomers to the language become familiar, to jumpstart a simple Web app, and to look amazing on the screencasts.

Ruby on Rails is great. At the very least, everybody should try it. It's no silver bullet, but it is a huge improvement over most everything else out there.

Using Rails is a bit like using a Mac: you always run into these little helpful features that make you think it was created just for you.

Yes, very

[Bruce Perens]

Maintainability is a combination of several factors. Most important is: can you read and understand the code? Ruby on Rails wins in this category because it's brief - smaller and thus easier to comprehend than Java - without being cryptic like APL. Second most important is: is it easily modified? Here Rails wins again, because of the say it only once philosophy and because of Ruby's duck typing *. Say-it-once means that you don't have to track down the other places where you've had to say the same thing (as in Java) and change them. Duck typing means you can change an object substantially without the user of that object seeing the change, because the user only knows what methods the object is expected to respond to, not the object's type.

Bruce

* Duck typing: If it looks like a duck and sounds like a duck, it's a duck! Object types don't matter to the users of Ruby objects. What matters is that the object responds to a particular collection of methods. This is something like virtual functions, but does not require inheritance from any class or virtual class although inheritance from a Ruby module (sort of an abstract base class) is often the best way to implement those methods. So, a Ruby object might export a collection of methods called Enumerable and would respond positively to an is_enumerable? method to identify that those services are available.

Re:Yes, very

[Abcd1234]

Yeah! And if in, say, Java, you have a superclass and subclass, how do you know the subclass didn't override superclass methods to do totally different things!

It's called not doing stupid stuff. Now, I don't know much about Ruby, but in Objective-C, these things are called Protocols, and in Java, they're called Interfaces, but the rule is that if you implement a given protocol, then you must conform to a given contract. Can a developer deviate from that contract? Yes. Are they fucking retards if they do? Absolutely! If you want to prevent that, your only option is to work with a language like Eiffel which incorporates design-by-contract at the language level... of course, even that isn't foolproof.

Get the basic premise right, first

[blakeyez]

Rails is _not_ a code generation framework. Note the period on that sentence.

Rails may provide the some simple scaffold generation, but that's only there if you _want_ to use it, and it happens to fit the way you'd like a particular part of your app to work. The code produced is concise, easy-to-follow, and thus easy-to-maintain.

For my own applications, I barely ever use scaffolding. It works well for simple admin screens where I just want 'something' that works for now, then will spend some effort on designing it a little better, later.

Rails is as maintainable as you make it. If you're a poor programmer, you're likely to write unmaintainable code, no matter what language or framework you have to help you. Rails helps point you in the right direction, but in the end, it's up to the _developer_ how maintainable his/her code is.

Gem up on Ruby First!

[Boss, Pointy Haired]

Rails has created quite a buzz in the Web 2.0 community, which means a lot of people jump straight into Rails without any prior knowledge of Ruby; and then when they find they can't get very far they blame that on Rails.

It's like hacking the Linux Kernel without ever having programmed in C. You're bound to think it sucks because you won't have a clue what's going on.

It isn't really code generation

[Anonymous Coward]

Ruby on Rails script/generate generates very little code. If you choose "File, New class" in Eclipse, you get the about the same amount of code, as you would get if you used rails generation features. The only difference is that ruby on rails also generates a test class for the model.

Scaffolding generates a bit more code, but it is never intended to be actually used. It is ment to be slowly replaced, piece by piece, by your own code. So I don't think the disadvantages of code generation really applies here.

So yes, in my experience a ruby on rails project is maintainable.

Bad OO Substitute?

[cheesedog]

I'll make a bold counter-claim: Object-oriented programming is a bad substitute for straight-forward dynamic binding and typing.

I've been doing almost pure OO programming for the past 8 years (using mostly C++ and Java), but recently took up Python (for python-twisted and pyWxWindows) and Ruby on Rails (for server-side development), and I can tell you that it is much simpler, easier to debug, and quicker to get done than taking the time to create massive class hierarchies whose inheritance structures and interfaces only exist to satisfy type-safety requirements.

Don't get me wrong. I like writing class hierarchies as much as the next guy. I've spent years doing it. But when I compare what I can get done in 30 minutes in, say, Python, to what I can't get done in 3 hours in C++, the advantages start to become very clear.

Try Ruby here! In your browser! Painless!

[5n3ak3rp1mp]

Try Ruby (the language) here. Integral to understanding much of Rails.

I released my first production Rails app last month. I like it a lot. I have a background in ASP/SQL Server/PHP. Not having to use Microsoft Windows itself is a huge win. But I like the design of the language and the framework and the built-in separation and a thousand little other things. Check out #rubyonrails on irc.freenode.net, great community there too.

Re:Uhm...

[Pxtl]

Well, if you have to do maintenance work on the resulting machine code, then yes, it does alarm me. Otherwise, not so much. Likewise, any code gen environment where you're maintaining the generated code instead of working on the generator should worry people.

Static vs Dynamically Typed maintainability

[TheNarrator]

Ruby is not statically typed, which means that if you have a very large program and you change an API in that program you have to go and find all the instances of calls to that API in your program yourself, either through running automated tests or seeing the broken calls in the debug log of your application. Compiled langauges on the other hand such as Java,C,C++,C# have static calling conventions which means that when you break an api the compiler will point out all the broken calls to you and not let you run your program till you fix them all. This tends to make statically typed languages more maintainable. If you need to break out of static calling conventions you can in Java at least using introspection and bytecode enhancement but this is usually only done in well defined scenarios inside of application frameworks instead of for every class like in Ruby.

RoR is maintainable enough -- but...

[oldCoder]

But the programmers API isn't nicely documented in RoR, although there is a web page that claims to do that. For example, to search the RoR API web page you have to use google. Half the time I come up with a blank document. That is, the entry for the function I want is a blank page, and there is no context (no "up" button) so I can't use it as a starting place for more navigation.

The result of the somewhat sloppy documentation is that if I find a function that does something (like by looking at the source) I don't know if it is guaranteed to be there next release. The existing book ("Agile web programming...") is too chatty and not complete and accurate like a reference manual would be.

So I'm somewhat blindly following the examples and when something doesn't work I have to backtrack. Still, all in all, I like it. I need the speed.

And, like a lot of people, I found I had to go back and study Ruby a few times. The existing Ruby docs are great.

But I desperately want a good Rails reference manual.