CSUMB Learning Journal

Q. List the 5 most important things that you learned in the course, and why you chose them. A. I think the 5 most important concepts I learned during this course were Agile development with BDD and TDD, Git version control, automated testing with JUnit and Selenium, Cloud Deployment with AWS, and service-oriented architecture. These concepts are very important because they all tie into the ability to be able to rapidly deliver reliable and scalable high quality software.

 Q.  Describe some of the differences between using an Agile process and using a Plan and Document (or Waterfall) process.   A. The primary different between Agile and a Plan and Document (Waterfall) process lies in how they approach requirements and execution of a project. Waterfall uses sequential phases that need to be fully completed before moving on to the next phase of the plan. This model makes it difficult to make changes later on. Agile works in much shorter cycles that iterate on themselves which allows the project requirements to change and grow as the product is incrementally refined into a final product. Waterfall makes a plan with comprehensive documentation (unaware of future complications) and Agile prioritizes putting together smaller pieces of the project while staying open to being able to adapt to an environment of smaller changes that might need to be made to the project. Plan and Document is more rigid while Agile is more flexible.

The most important thing I learned this week is about CaaS (Compute as a Service) and how it solves the messy and inefficient processes that came before it. Previously, teams managed their own "snowflake" machines, which were unique environments that wasted engineering effort on tasks like OS patching and manual scaling. CaaS provides a standardized platform where developers simply package their application in a container and declare its resource requirements. A central cluster manager then automates scheduling, resource allocation, and failure recovery for a large shared pool of hardware. This shift in strategy improves efficiency and reliability, which allows engineers to focus more time on building products instead of managing infrastructure.

 This week I learned about large tests from the textbook. This also went into when, where, and why you would use larger tests sometimes as compared to smaller tests and weighs the pros and cons of both. The things that stood out to me the most in this chapter were the sections talking about unfaithful doubles and issues with configurations causing bugs and not being caught because they sometimes aren't including in the version control system with the rest of the project code. Interestingly, the textbook claims that configuration changes is one of the major reasons for major outages at Google.

Q. What is the most interesting thing you have learned in your reading of "Software Engineering at Google"? A. I think it's interesting how Google does code reviews. I didn't expect that they would tag approved changes with something kind of silly like LGTM which stands for "looks good to me", but it does make sense and seems quite practical in use. It's also cool to learn that Google uses an in-house code reviewing tool, Critique, since I haven't heard of it before.

Q. Describe what are the good points about using Git for source code management. A. Git is a good version control system. Everyone gets their own copy of the project which adds extra redundancy in case the main version gets deleted. Git allows you to create branches to keep the main branch of the project clean while developers work on new code. As a version control system it prevents your projects from getting messed up or corrupted. Q. What are possible problems that Git merge does not solve when merging code from different developers? A. Git merges do not take context into consideration. 

Q. Summarize what you learned about React this week. A. I learned that React uses the two-server model where you have a separate front-end and back-end. The React front-end is just a fancy way of sending API requests to the back-end that actually does everything. Q. In your opinion, what are the strengths and weaknesses of React? A. I think one strength is React's component based architecture. It's easy to organize and manage different components of your project. I think one weakness is that it can be difficult to set up and configure the application to get it working properly. That might have just been an issue exclusive to my experience though.