Suhaib's CS Journal

Week 5 Learning Journal: This week, I learned about large-scale testing and how it differs from unit testing. I also learned about the importance of realistic test data, proper system configuration, and clear ownership of tests. Canary testing and A/B testing showed me how organizations like Google can test changes safely and identify problems before releasing them to everyone. In our group project, our team completed Iteration 2 by reviewing code, merging pull requests, fixing issues found during testing, responding to reviewer feedback, and verifying that the frontend, backend, and database worked together correctly. We also used Git branches, commits, pull requests, and team communication to coordinate our work. I also learned that Agile practices such as assigning priorities and estimating tasks with points are very useful because they help the team understand which work is most important, compare the size of different tasks, and divide the workload more fairly. My main takeaway is...

Week 4 Journal: What is the most interesting thing you have learned in your reading of "Software Engineering at Google"? The most interesting thing I learned from Software Engineering at Google was that code reviews are not just about checking whether code works. They also make sure the code is understandable, maintainable, and easy for the rest of the team to work with. This relates to the group project we are doing right now in this class because we are using GitHub branches and pull requests to combine everyone’s work. When I pulled the latest changes from the main branch, I saw how much code from different teammates had been added to the student controller files. That made me understand why Google uses peer engineers, readability approvers, and code base owners during reviews. Having different people check the code can make it clearer and easier to maintain, especially if the original person who wrote it is no longer available.

 Week 3 Learning Journal -  Before I started using Git, I would make a bunch of backup copies of my files whenever I changed something. I had to keep renaming them with things like “final,” “final2,” or “working version,” and it became confusing to remember which file matched each stage of the project. Git handles that much better by saving organized commits, keeping a history of changes, showing who changed what, and letting developers work on separate branches. It also makes it easier to undo mistakes, compare versions, collaborate, and review code before combining it. However, Git merge only combines file changes. It cannot determine whether two developers’ code actually works correctly together. A merge may finish without conflicts but still introduce bugs, break business rules, create inconsistent designs, or cause one feature to interfere with another. Git also cannot resolve disagreements about requirements, architecture, naming, or which implementation is better. Deve...

Learning Journal Week 2: This week I learned how React can be used to build the frontend for a full customer order application. I worked with components such as Login, Register, Order, OrderHistory, EditOrder, and Settings. I learned that React applications are organized into smaller pieces, and each component is responsible for one part of the user interface. I also learned how useState helps keep track of changing data, such as form inputs, messages, and order information. React Router was useful for creating different pages in the same application, including login, register, order, history, and settings. The lab also showed me how the frontend connects to the Spring backend using fetch requests, JWT tokens, and session storage. One strength of React is that it makes the page feel more interactive without constantly reloading the whole website. For example, the order history table and edit dialog could update based on user actions. Another strength is that reusable components, lik...