| I've done my share of cleanups in various languages. I don't agree that Rails code is "a special kind of horrible", but there are a few things that seem to be very common in Rails code. A lot of it seems to be written by inexperienced programmers. There are any number of indications for making such an observation. - Multiple different 'Rails best practices' Rails has changed a lot since version 1.0, but most of the 1.0 stuff still works. People usually learn Rails by reading blog posts and then trying out what they read. As they write code, read more, etc their perception of what the 'best practice' is changes and so does the new code that they write. This makes a mess of things. Experienced programmers will set a 'best practice' for the entire codebase and if that changes for whatever reason will refactor the entire codebase to match the new standard. This is pretty trivial in Rails simply because the codebase of even huge Rails apps is still pretty small. - Lack of tests A lack of tests is considered a sin in the Ruby world, but it happens all the time. Embracing testing, I think, is something that comes with time because if you're new you simply don't see the value of it. Lack of testing is bad, but there are also variations on this rampant in the Rails world. Different test frameworks in a single project (I call this the 'follow-the-shiny-new-trend' problem) or simply boilerplate tests that don't really tell you anything other than, yes, this ActiveRecord object without callbacks can be committed to the DB. - Breaking MVC This drives me nuts. Doing Model work in the Model except for over here where I do it in the View for whatever reason. This is a clear sign that the programmer doesn't have a good mental model of what's going on and why this is a really bad idea. - AJAX Rails embraced JavaScript very early on and is a very fine framework for doing AJAX in. However, doing AJAX is a completely different skillset and most programmers don't have it. Most projects just seem to have various widgets floating around that don't share a common coding or state system. That makes them hard to unify and also means there's a lot of arbitrary XHR calls going into the Rails app (for which there are often 'special case' Controller methods, which don't share a lot of logic with anything else) - Inconsistent use of the Rails API This ties into the 'best practices' point, the Rails API is by now pretty big and you have to take the time to study it. New programmers don't usually do this because they don't have a background in programming in frameworks and resort to trial-and-error programming ('hey this works here, let's move on'). Which, BTW, is something that Rails makes very easy. There are plenty of other things (terrible SQL, custom Ruby code with magic, arbitrary plugins, etc) but those are usually pretty easy to isolate and fix. The good news is that Rails codebases are generally pretty easy to fix incrementally. Write up a coding standard, start writing useful tests and pick a test framework (really, RSpec is fine) and work from there. Hard points to manage (which should be obvious and not Rails-specific), - If you're fixing an app that is under active development you have a lot of coordination to do
- This is easier if you can work on-site
- It's a lot easier if the dev team is small
Rails is a really nice framework and a lot of people are getting a lot of productivity out of it. It's easy to look down on shoddy code and say that from your years of coding experience on the front lines you could do a better job, but that's not how experience is built. If you're reading this you've probably written some pretty horrendous code earlier on. Look at it this way : if a startup can hire an outside consultant to clean up their code and teach them some lessons, then what they had before you came in was apparently enough to get them off the ground and their programmers learned a lot in the process.That's a good thing, right? |