Some Limelight refactoring and Java learning

May 10, 2009 at 10:33 pm (Java, Limelight, Week 7) (, , , , )

Micah and I paired most of the day on Friday on adding a kiosk mode to Limelight. Since the codebase is a mix of Java and Ruby, we were moving back and forth between the two languages (and JUnit/RSpec), but our changes were mostly in Java. There weren’t really too many big surprises along the way, and we worked incrementally enough that, in most cases, I was able to figure out what kind of tests to write. Of course, I did get stumped a few times, but rather than just write the tests himself (which I know he could’ve done in a few seconds), Micah helped me to see the bigger picture of what exactly we were trying to test, and the tests themselves came soon enough after that.

Our Friday Lunch & Learn went in a very different direction than usual – we took a little field trip out to the movie theater and caught the new Star Trek movie. Good stuff; I recommend it!

This weekend, I’ve been finishing up reading the book I’m reviewing, and I’m really enjoying that. It’ll be a good read when it’s done, and it’s already really interesting and helpful (it’s on agile coaching). The other book I’m working on is Thinking in Java by Bruce Eckel. I’ve been pecking at Java since I arrived in March, but I feel like I’d be much better off armed with a more solid understanding of the language, like I have with Ruby. This book is great. I have it checked out from the library right now, but I may actually still end up buying it just because it clarifies so many things. One particular thing I loved when reading this morning Eckel’s coverage of polymorphism, edge cases where you might expect late binding but don’t get it, and the fact that you shouldn’t encounter these edge cases often because there are better ways to design your code. I’m reading in this book a lot of the same OO design principles I read and hear about everywhere else, but with different words, which kind of hammers it home even more.

I watched Uncle Bob’s RailsConf keynote and enjoyed it. I know that a few have pooh-poohed the talk (though many more loved it), and I do agree that the tongue-in-cheek testosterone / estrogen metaphor is outdated, but who can disagree with the crux of his argument? We should drive development with tests, have some humility, and take on tough problems like legacy codebases. Being a professional means different things to different people (one of Uncle Bob’s descriptions), but to most it means you’re good at what you do and that you’re serious about being good (but not necessarily serious about yourself and wearing a 3-piece suit all the time; that’s an entirely different meaning).

Well-tested code means you don’t have to be afraid of change. I worked on a larger project on my last job that took forever to change, because there were virtually no tests. Any change I made to the code (and on any big project, there are plenty of changes) meant I risked breakage. Luckily, the code wasn’t hammered by users or mission-critical, but it is so embarrassing to have bugs in your code, especially when they’re discovered by the client. If I had the skills at the time to get more of that project under test (and I have a good idea of what to do thanks to my apprenticeship experience so far, along with Michael Feathers’ book), things would have gone differently. Changes might not have been that much easier just because of the tests (there are also OO design issues to consider), but they would have been verifiable. I would have known when I had it right.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: