Before our first lecture class for Software Engineering, I have not programmed in Java for months. Given this task to implement FizzBuzz in Java, I took about 10 minutes to code FizzBuzz off the top of my head (and partially from what I could remember from last week) and run it with an at-a-glance "passed" for verification of correct output. However, at this 10-minute mark, I knew I had yet to appropriately verify my code, figure out how to place it in the proper Java package (edu.hawaii.ics314, in this case), and comment my code for good programmer citizenship's sake. With fellow classmate Jason Yeo's help, I discovered that I had always been missing one simple step to placing a Java source file in a custom package, and that step is to specify a name for the "Package" text field upon creation of a new Java class. As can be seen in the following figure, I had multiple packages before I made the right one (and later got rid of the others):
Commenting each subsection of the code took only a few minutes. It was the line-by-line verification of the correct output that comprised the bulk of the 15 extra minutes I spent to polish my code. Each of the "FizzBuzz" and "Buzz" outputs were a given, since multiples of 15 and 5 are hard to miss. In order to verify the "Fizz" multiples of 3, I mentally added each multiple's digits and divided the resulting sum by 3. In the near future, I shall learn to use JUnit to test my code instead of this human error-prone line-by-line verification method.
In conclusion, I learned that writing the code itself is a downhill slide. It's the uphill climb - the polishing of code and learning of new concepts to polish it even better - that takes more time, but in the end, it matters most.
Figure 3: My Java Implementation of the FizzBuzz Program
25 minutes? Why so long?
ReplyDelete