One More Byte CS Devlog

5 of the most important things I learned from this course:     1 . GitHub Project Management. Working as a team using GitHubs project management tool. This was the first time I had used GitHub as more thank just a place to store, share, or pull code from. Learning how to divide a feature into individually assigned issues and link every pull request back to its issue was a great opportunity to get a sense of how real engineering teams track who's doing what and why.     2 . Learning how to use Spring Boot Microservices. Splitting the backend into separate services, each with its own database, gave me a new perspective on how to design a large scale project. By splitting the project into multiple services, each can be developed, tested, and run independently.     3. Working with React Frontend.  Instead of manually tracking which parts of the page need to change and updating them by individually, React allowed to update the values in a centrali...

     Writing the SRS this week showed me how the waterfall method works on assumptions. The document is built on the idea that I already know how everything should work before any code exists. Deciding on things like the pickup wait being ten minutes are guesses, but the format doesn't let them look like guesses. They were formatted to be stated as if they were settled choices. Agile goes about this differently because instead of trying to be right at the start, it assumes you'll be wrong and finds out where. Rather than sixteen use cases delivered as one document, an agile team would build two or three, put them in front of test users, and let the feedback influence the rest. Though does SRS supply a document that helps to define all the goals and its scope in once neat place. Neither approach fully removes the guesswork about the ten minute wait, waterfall resolves it by committing early, agile by launching and adjusting.

     This week we focused on unit and system testing. Writing these tests changed how I think about projects. Id previously assumed most effort would be focused into writing the logic for a project followed by testing as a smaller task at the end but working through these unit tests and the Selenium system test showed testing takes just as much effort to perform successfully. A well tested feature often has as much to it as implementation code. At one point I spent some time debugging a multi dialog DOM ambiguity issue in AssignmentViews, a bug that never showed up just from reading and normally running the code, only from testing it properly.          This weeks lecture talk about needing more tests than you'd expect which also clicked once I saw unit and system tests side by side. My mocked unit tests were fast to write and good for edge cases, like an instructor trying to access another instructor's roster. But they couldn't tell me t...