CST 438 - Week 4

 This was our fourth week in CST 438 - Software Engineering.

Reflection

Last week we set up a GitHub organization, along with some repositories and a project, for our multi-week group project for this course. We also planned who would do each task for the first two weeks, and our gave our estimates for how large and time consuming each task would be. This week we started working on the first set of tasks, which all focus on the API for the backend of the service. In the lecture material for the prooject it was mentioned that writing unit tests would take up more time than the code itself. This ended up being true, as most of my time was spent writing tests.
 
As part of this reflection, we were given the prompt "What is the most interesting thing you have learned in your reading of Software Engineering at Google?" For me I think the most interesting thing would be its coverage on tests, which I talked about in last week's post. The second most interesting thing that SAG discusses would be code reviews. According to the book, developers spend a large amout of time on code reviews. It also mentioned that new developers are often afraid of the criticism that code reviews bring. I very much felt this when I made a pull request for my portion of the project and recieved feedback. They had a lot to say, which made me feel a little overwhelmed. Ultimately, feedback from others is needed to see where you need to improve, so it was good that I had that experience.

SAG Ch. 9 - Code Reviews

Chapter nine of SAG discusses code review, which is defined as, "a process in which code is reviewed by someone other than the author, often before the introduction of that code into a codebase".
 
According to the text, code reviews follow these steps:
  1. An author writes a change to the codebase, then creates a snapshot of the change.
  2. The author sends the change to one or more reviewers.
  3. The reviewers post comments on the changes if needed.
  4. The author makes any needed changes and sends new snapshots to the reviewers. Steps 3 and 4 may be repeated.
  5. Once the reviewers are satisfied with the changes, they mark it as approved.
  6. The author is allowed to commit the change to the codebase.
Google also requires approval in three different ways for each change:
  • Approval from another engineer that the code is appropriate and does what the author claims.
  • Approval from one of the code owners that the code is appropriate for that part of the codebase.
  • Approval that the code conforms to readability practices from someone with language readability.
A well-designed code review process results in the following benefits:
  • Checks code correctness
  • Ensures the code change is comprehensible to other engineers
  • Enforces consistency across the codebase
  • Psychologically promotes team ownership
  • Enable knowledge sharing
  • Provides a historical record of the code review itself
Code reviews can fall into the following categories (sometimes having overlap):
  • Greenfield reviews and new features
  • Behavioral changes, improvements, and optimizations
  • Bug fixes and rollbacks
  • Refactorings and large-scale changes
 

Comments

Post a Comment

Popular posts from this blog

Week 26

CST-334 Week 2 This week was our second week in CST-334, also known as Operating Systems. Operating Systems: Three Easy Pieces This week we read chapters 4-8 of our course textbook. Chapter 4: Processes This chapter discusses processes, which are running programs, and how the OS virtualizes the CPU to run multiple processes. Key Takeaways: The OS runs multiple processes by stopping and starting them during context switches. All OSs have APIs that processes use to interact with resources and the OS. To create a process executable code of a program must be loaded from storage onto memory. Processes can be running, ready, or blocked. The OS tracks data for each process.  Chapter 5: Process API This chapter discusses certain important aspects in Process APIs. Key Takeaways: The fork() system call creates a new process. The new process is identical to its parent process when it made the system call. The wait() system call allows a process to wait for another process, or its child proces...
Read more

Week 22

Image
 CST-363 Week 6 This is our sixth week in CST-363, also known as Introduction to Database Systems. Summary This week we read about integrating SQL into programs and other languages. We learned about some of  the differences between SQL and other languages and some of the ways to integrate SQL into a program, such as Embedded SQL and APIs. Then, we learned how to use an SQL API for Java called JDBC. Vocabulary Programming Languages Imperative Languages:  Contain control flow statements that determine the execution order of program steps. Two popular types of imperative languages are: Procedural Languages:  Composed of procedures, also called functions or subroutines. Most languages developed prior to 1990 are procedural. Ex: C and COBOL. Object-Oriented Languages:  Organize code into classes. A class combines variables and procedures into a single construct. Most languages developed since 1990 are object-oriented. Ex: Java, Python, and C++. Declarative Languages:...
Read more

Week 18

CST 363 Week 2 This is the second week in CST-363, also known as Intro to Database Systems. Questions Think of example where joining on something other than keys would be needed. An example of this would be when you want to join to tables that don't have any keys in common, or when one table doesn't reference the other with foreign keys. In this case you could compare other columns when joining the tables, such as checking if a value in one table is high than the value of the another table. What is your opinion of SQL as a language? I think the basic syntax is easier to learn and understand than other programming languages. I find myself completing simple queries faster than I can solve some basic problems in other programming languages. However, I find more complex SQL queries harder to understand and write. I think this is the case because SQL functions differently from other programming languages. When I first see a complex query I want to approach it like I would when I am ...
Read more