Week 4 CST438
What is the most interesting thing you have learned in your reading of "Software Engineering at Google"?
This week in CST 438 the most interesting thing I have learned from the reading of "Software Engineering at Google" was how Google structures its code review process around three distinct approval “bits" which are the "LGTM" permission bit, owner approval, and readability approval. I have always been familiar with the term "LGTM", but I never realized it was only one part of a larger system at Google. To me it was sort of the admission or approval of code by simply just mentioning that it looks good, but at google it functions as a more formal permission "bit" that, when combined with the other required approvals, allows a code change to be committed to the codebase. Going into the phrase a bit more, I now understand what makes the permission bit significant as it demonstrates that a reviewer has performed a correctness and comprehension check. The book mentioned it as a way for the reviewer to agree that the code functions as the author has claimed it would and that it would be understandable to other engineers. Something else I learned about this is that LGTM can just be required by one reviewer for a change to proceed, though it depends on how teams want to proceed with the review process as some may request agreements from all reviewers. The book mentions that google has found that the first one was important and the subsequent ones are often diminishing returns.
Something else that I thought was interesting was the mechanism of OWNERS files located within the directory tree. The chapter explains that ownership isn't about the permissions but rather about stewardship. The owners are responsible for the long-term health of the code in their area, and the approval from them makes sure that the changes fit the design and expectations of that portion of the codebase. An interesting aspect was the hierarchical style structure such as the hierarchically additive system which signifies that a file is owned by a union of all members listed in the OWNERS files in its immediate directory and every directory above it in the tree. It's quite interesting to see the different structure and hierarchy that exists behind the scenes just to keep a massive monorepo functioning smoothly. This process not only helps solve catching bugs or issues with the code changes, it sort of fosters a collective responsibility that helps maintain high quality coding. Overall, it was eye‑opening to see how much coordination goes into maintaining code quality at a company operating at Google’s scale.
This week in CST 438 the most interesting thing I have learned from the reading of "Software Engineering at Google" was how Google structures its code review process around three distinct approval “bits" which are the "LGTM" permission bit, owner approval, and readability approval. I have always been familiar with the term "LGTM", but I never realized it was only one part of a larger system at Google. To me it was sort of the admission or approval of code by simply just mentioning that it looks good, but at google it functions as a more formal permission "bit" that, when combined with the other required approvals, allows a code change to be committed to the codebase. Going into the phrase a bit more, I now understand what makes the permission bit significant as it demonstrates that a reviewer has performed a correctness and comprehension check. The book mentioned it as a way for the reviewer to agree that the code functions as the author has claimed it would and that it would be understandable to other engineers. Something else I learned about this is that LGTM can just be required by one reviewer for a change to proceed, though it depends on how teams want to proceed with the review process as some may request agreements from all reviewers. The book mentions that google has found that the first one was important and the subsequent ones are often diminishing returns.
Something else that I thought was interesting was the mechanism of OWNERS files located within the directory tree. The chapter explains that ownership isn't about the permissions but rather about stewardship. The owners are responsible for the long-term health of the code in their area, and the approval from them makes sure that the changes fit the design and expectations of that portion of the codebase. An interesting aspect was the hierarchical style structure such as the hierarchically additive system which signifies that a file is owned by a union of all members listed in the OWNERS files in its immediate directory and every directory above it in the tree. It's quite interesting to see the different structure and hierarchy that exists behind the scenes just to keep a massive monorepo functioning smoothly. This process not only helps solve catching bugs or issues with the code changes, it sort of fosters a collective responsibility that helps maintain high quality coding. Overall, it was eye‑opening to see how much coordination goes into maintaining code quality at a company operating at Google’s scale.
Comments
Post a Comment