Tuesday, February 15, 2011

Learning about testing, debugging and optimizing Ruby code

I just finished up chapter 8 in Beginning Ruby. It was mostly about documenting, debugging, testing and optimizing code. Not the most interesting chapter, but it's still important to understand.

Writing custom exceptions is easy enough to understand. Begin and Rescue makes sense. Once again, I'm amazed at how easy Ruby is to grasp. You want Ruby to do something 100 times?

100.times do
  puts "DO WHAT NOW"

Maybe it's just because I've got some experience now, but this bit of code is easy to break down. I'm looking forward to the day that more complex bits of code are as easy to grasp! One step at a time.

But here's a question about optimizing code. Do you typically try to optimize as you write the code, or do you write the code and then optimize it? At first, it seemed logical to try and optimize as you write the code, because it seemed like the most efficient way to work. However, once I read further, writing code and then optimizing it seemed more efficient, since you could figure out which parts of your code need to be reworked. This way you wouldn't waste time thinking of ways to optimize code that wasn't really a problem to begin with.

Benchmarking code is another concept that made sense immediately. Since Ruby offers you the ability to do something in multiple ways, being able to figure out if one method is inefficient is important.

Next up is Chapter 9: Files and Databases. OH YEAH! Never thought I'd be so excited to learn how to call a database for information and then manipulate that information and display NEW information to the user! This is what I've been interested in since I started reading Beginning Ruby.

1 comment:

  1. You'll get a feel for extremely inefficient things and learn to avoid those, but mostly you just do what's easy and gets it done. Later you can circle back if the inefficiency is actually a problem, it rarely is.