Week 10: CST 338 - Software Design

Week 2 Learning Journal – Reflections on Lab 00, Lab 01, Unit Testing, Git, and Interfaces

We're now at the end of Week 2, and looking back, Lab 00 and Lab 01 were fairly simple but served as a solid introduction to Java, JUnit testing, Git, and working with IntelliJ. As someone who hasn't worked with Java before, I found it surprisingly similar to C++, though there are some odd differences. For instance, String.length() is a method, while array.length is a public field. These inconsistencies can be a bit confusing at first.

Although I have some experience using Google Test in C++, JUnit was new to me. Still, the concept was familiar - writing tests to validate code behavior - and I appreciated the hands-on practice. I can already see how unit testing helps catch small mistakes and improves confidence in code changes.

Regarding Git, I was already familiar with basic version control concepts and commands, but most of my prior usage was through the Visual Studio GUI. These labs gave me valuable practice using Git from the terminal, which helped reinforce the core workflow and gave me a better understanding of how everything fits together - cloning, branching, committing, and pushing changes.

Interfaces were also briefly introduced, and while I've worked with them in .NET environments, I'm still a bit unsure about when and why to use them in practice. I understand they act as a blueprint - declaring methods (and constants) that must be implemented by any class that uses them - but I haven't personally encountered a situation where I needed one. I'm hoping the professor will walk us through a real-world example that shows where interfaces actually make things better, so the concept will click more for me. In the meantime, I plan to read more on my own and try to find some good use cases.

One thing I want to reflect on is the professor's strong emphasis on commenting code. While I try to follow that guideline, I honestly don't see the benefit of commenting every part of the code. In my experience, well-named variables and methods make the code much easier to read than extensive comments. In fact, too many comments can double the file size and make it harder to navigate, especially in large codebases. I usually only find comments useful when they explain unusual logic or something that would be unclear even with good naming. Otherwise, I tend to skip over comments entirely. I understand the importance of documenting code, especially in team settings or for public-facing libraries, but I believe clarity should start with naming and structure. That said, I respect the professor's expectations and will do my best to meet them, even if I don't fully agree.

Overall, these first two weeks helped me establish a foundation in Java, sharpen my testing skills, and gain comfort using IntelliJ and Git. I'm looking forward to diving deeper into Java-specific concepts like interfaces and seeing how they're applied in larger programs.