Now that I’m really immersed in Ruby programming, the problems we are trying to solve are becoming more complex. This is exciting, as the programs have increased functionality, and aren’t just “one-trick ponies” that simply accept text and spit it back out to the user. We are writing code and starting to see the real-world applications it could be applied to.
With the increase in function comes an increase in the difficulty in building such programs, as one may expect. It’s easy to see the acceptance criteria for a program and get overwhelmed at how many features you need to pack into one program.
I’ve been learning that the best way to approach a problem is to break it down into smaller pieces. This allows one to work on each criteria, one at a time. This technique naturally flows into the idea of test-driven development, except without the use of automated tests. Doing so allows one to focus on one task at a time, treating them like checkpoints along the way.
This method was particularly helpful for me during the creation of a cashier program, which accepts orders and writes out transactions to a file, also reading back in this data for analysis about sales.
Focusing on one fuction at a time also allows me to concentrate more on that section of code, since I’m not worrying about the program as a whole. I can then write cleaner code that results in fewer RuboCop infractions.
After completing a feature, I can then commit to git, and move on to the next section. This serves as a good way to measure progress as well, as you can easily see what is and is not implemented.
Breaking down a problem also helps when planning out how you will structure your program, before you start coding. Writing a program is almost like putting together a puzzle, except that you must also create each piece of the puzzle before assembling it.