Week 12 - Code Reviews Continued: Library Project

             This week I worked with my team members to review our code on some Book, Reader and Shelf classes from a Library project. The library project had us develop books, readers, and shelves in a library, allowing operations like adding, removing, and listing items. It included creating to handle various functionalities like checking out and returning books and initializing the system from a file. We used standardized error handling using predefined codes to ensure consistent and clear reporting of operation outcomes.

My approach was to start with the easy code. By following the style guide, I wrote the constants, fields, getters and setters. Most of this was autogenerated with IntelliJ as well. Then I worked on the logic within the special methods. I had a pdf of the overview handy to make sure I adhered to the specifications the methods needed. I ran tests in between methods to see if they passed. And lastly, I went back to check if any code could be optimized and to comment where I thought it was necessary to make proper documentation.

Andrew shared a similar strategy, he stated that prompt for the Java class and created the file.  After reading the prompt, he used the UML diagram to create the skeleton of the method, including any autogenerated getter/setter/constructor code.  Once that was complete, he used the more detailed prompt instructions to finish creating any method's passed field names, set static final fields, and make sure the outline matches the requirements. I then run tests and write the methods one by one in the order they are generally needed. (He couldn’t remove a book until he added a book).  According to him, none of the classes required him to plan on paper, the prompt was the planning stage/instructions.

I think that since we were provided with all the necessary instructions and UML diagrams for this project, planning wasn’t too necessary. However, in the future when I’m in charge of my own project, I’d like to incorporate the same style of overview charts to ensure that I have a guide. As for the projects, I think I’d take a similar approach to this week because I’m starting to find a rhythm in the course.

According to Andrew, my code adhered to the Google Java Style guide (for the most part). He brought up a few minor things, such as my constant names which should have ended with an underscore.

Both my teammates did a fantastic job on their code. They were well-organized and inspired me to try and be more organized within my code as well. I did see that some of their functions were more effective than mine. And I was glad I was able to receive input from the to correct minor errors in my project.