One More Byte CS Devlog

     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...

     This week I built out the AssignmentsStudentView and Transcript components so students can view their assignment scores and course transcript. It was good practice tracking down how data is moved from a Springboot dto using a fetch call and putting it into a viewable table.      I had the opportunity to practice my ability to navigation through a multi repo project to find the source of a bug rather than just making a bandaid fix where I first noticed it. When I saw that typing a lowercase semester like "fall" returned no results, I decided to figure out where that value actually originated and traced the input back to SelectTerm, which is a shared component across several student and instructor views. Fixing the case sensitivity there meant the correction applied project wide instead of needing to be duplicated across each view that used it.

     One of the things that I found interesting from 'Software engineering at Google' was the distinction between programming and software engineering. Before taking this class and reading the text, I viewed software engineering as just an advanced form of designing and integrating large systems. While I understood that practices like code reviews, version control, and project planning were important, I thought of them more as supporting tools rather than a defining part of engineering itself.     It makes a lot of sense now that software engineering encompasses much more than writing code or designing architecture. The processes that guide development like code reviews, version control, project organization, documentation, and team collaboration are what allow software to be developed reliably by many people over long periods of time. These noncoding aspects are what separate software engineering from simply programming. I think this shift in perspective i...

     One of the biggest advantages of using git for source code management is that it provides a complete history of a project. If a new feature or bug fix accidentally breaks the program its easy to look back through previous commits and return to a working state. Git also makes collaboration much easier by allowing multiple developers to work on different features at the same time without constantly worrying about keeping every file perfectly synchronized. Branches allow developers to experiment independently before integrating their work into the main project.      Though git doesn't solve every problem that someone might run into when multiple developers are working on the same project. Merge conflicts are an most obvious issue, needing developers to manually decide how conflicting changes should be combined. Additionally, even when Git merges code automatically, its unable to determine whether the merged code makes sense logically. Two developers may m...

     This week we focused on using React alongside Spring Boot to build a full stack web application and learned how the front end communicates with the back end. I really enjoyed this topic because, while previous classes had covered front end or back end development separately, this was one of the first times I got to see how the two actually work together. It was exciting to see how data is passed between the client and server, stored in a database, and then retrieved to update the user interface. Seeing the complete flow made the overall design much easier to understand.      The solo portion of the lab was incredibly valuable because it made me have to think about how to implement the different pieces so they could communicate correctly which really reinforced how each part of the application fits together. Working through the implementation myself helped me understand the mechanics instead of just following along with examples.     ...