IntelliJ used to be my favorite Java IDE, it was seriously the tool that made the pain of working with the Java enterprise stuff bearable.

On November 1st they released a public preview of their Ruby IDE RubyMine.

Picture 1

It does feel a little shaky still, I couldn't get debugging to work, but it's a good start. I'd love having something like IntelliJ at hand, not necessarily for every day work, but especially for stuff like a good debugging session.

Keep it coming, JetBrains.

If you want to try it out, make sure you have a lot of screen real-estate at hand.

Tags: rails, ruby

It's very simple: Because it won't go away. There, that was easy.

Every line of code you write becomes legacy code, whether you like it or not. Doesn't matter if you're using a shiny new framework or something that's been develop in-house. Sooner or later someone will have to maintain your code, whether it's adding features or fixing bugs. It doesn't matter if it's you or someone else. At some point some human will come back to your code, and will want to do something with it.

So what do you do? You take all precautions so that this person can do his job. You write tests, you refactor and clean up your code, and you make it as readable as possible. Simple as that. You work your way in from the outside.

What happens when you get back to someone else's legacy code? That depends really. If there are tests you run them, you read them. If there are none, you just write tests. It's a neat way to discover a piece of code's functionality. You'll find some first pointers on where to start refactoring, or where you can add that new feature marketing wants so badly.

Legacy code is something that will give you a chance to learn.

You can learn how to refactor code. It's not always fun, but I find working with legacy code to be a more rewarding if not always pleasant experience. You get the chance to make code better, to make it easier to read, and finally to add new things. It sounds more glorious than it really is, cleaning up after others isn't something that'll win you a Jolt award, but it will deepen your knowledge of the domain, the code, and it will improve your personal skills.

Over time it will get easier to work with other people's code, no matter how big the mess they've made.

Working with legacy code is not a glamorous job. But it's a skill that'll give you a lot more knowledge about working with code than constantly working on new projects will ever do.

Mind you, legacy code doesn't need to be a mess. It's up to you to prove that.

Code metrics are a nice tool, and they're starting to become popular in the Ruby community. They statically analyze your code, and tell you with the simple power of numbers what's wrong with your code. You can spend ages changing your code to make the numbers look good. Still that doesn't tell your customer anything. He doesn't care about those numbers, he wants to see a finished product.

Why do people come back to metrics then? Not an easy question, and there are many answers:

  • They need an excuse to waste time, to beautify their code so that the metrics approve.
  • Their company has a policy that code must fulfill the strict regiment of the measuring tools.
  • They just love numbers.
  • They need a tool to tell them that they're code looks nice.

That's pretty much it. I haven't found any other real use for them. They're just a waste of time. Everything they tell you is just based on a set of rules, not common sense.

Instead of trying to fix your code to satisfy the code metrics tools, work in pairs. Work together to find code that looks doubtful, that reduces readability, that may increase the risk of bugs.

It will do a lot more for the quality of your code than any tool will ever do. Relying on tools to ensure your code's quality will only cover some deeper-lying problems within your team or organisation.

One thing I explicitly except from this is code coverage. While it's not important to have exactly 100% of your code covered with tests, it's important to have a code coverage tool and your common sense at hand to find code that still requires testing, to get the code that matters under tests. Check out this post by the Thoughtbot guys (who write excellent testing tools, by the way) on test metrics. All you ever need in my book.

Other code metrics won't tell you anything a trained eye wouldn't see without them. So read code, write code, and try to make it look neat and readable. That's the experience you need.