After spending the previous week wrapping my head around complex data structures and how the inner workings of code should be organized, this week was more about taking a step back and thinking big picture. The first few days of the week was focused on learning about Classes and Objects in Ruby. In non-code speak, this is Ruby’s way of separating your program into different pieces, allowing you to control how each part interacts with one another. I’ve learned about Classes and Objects on my own prior to starting the bootcamp but the challenges that we did this week really helped give me a deeper understanding of how powerful they can really be and also provided me with a different perspective on how to organize my code when I write.
The second half of the week was focused on learning one of the best practices in the industry, test driven development, or TDD for short. Before I started taking this coding thing seriously, I had this preconceived notion of programmers just typing away furiously on their laptops, headphones on, completely in their own zone. While there are times when this is definitely still true, I’ve learned that a lot goes on before actual coding even begins. TDD is the first step of the journey. The TDD process begins with writing out in plain english what you want your program to do. For example, if I’m making a cash register program that mimics the checkout process of a grocery store, I would write that my program should be able to ‘pull up the price of any single item in the store’, or ‘give me a running subtotal of the transaction’, or ‘calculate the amount of change owed’. After that’s completed, the next step is to write code for each of these statements in order to test if your program can perform the intended functions. The goal is to write code that will pass each of these tests, and in that way, the code of your program is gradually developed based on the intended use cases.
I found TDD to be very helpful in organizing my thoughts and to encourage me to think deeply about what I really want my program to accomplish. It forces you to step away from actual code and consider the real world implications of what you’re trying to build, including possible modifications in the future or issues that may pop up and break your program. Essentially its like having a gameplan instead of going out and improvising. Although it takes a lot of upfront investment, in both time and effort, I already see the value TDD can provide when building more complicated applications and look forward to getting much better at testing in the near future.
Dive & Maximize 