[3/4] Software Engineering at Google (Do it like Google. Software development) (Category Engineering)

Continuing the story of this cool book raised in posts 1 and 2Here I will tell you about the third part of the book called Processes.

III. Processes (Processes) 8. Style guides and rules (style guides and rules) Here. The authors explain the need for standardized coding styles and rules. Consistency across all codebases reduces friction (friction)It facilitates support and enables automated tools to help enforce these standards. Interestingly, in some languages, these rules are fixed at the language level, for example, in Go. 9. Code review (code-view) Here, the authors outline Google’s approach to code review as a key process for maintaining quality. They describe best practices and benefits. (such as knowledge sharing and early error detection) and how systematic reviews support scalable development. 10. Documentation (documentation) This chapter focuses on creating clear, supported and accessible documentation. The authors emphasize how proper documentation helps ensure the long-term viability of code and facilitates the process of onboarding and collaboration. 11. Testing overview (testing) The authors present the general philosophy of testing at Google. This chapter explains how tests are important for detecting problems early, ensuring code reliability, and enabling rapid development cycles. 12. Unit testing (unit testing) The authors talk about the details of testing individual components. They emphasize the importance of well-written, fast unit tests to check that small pieces of code are working correctly. It’s funny that in some companies, engineers don’t see the point in unit tests because they don’t find all the bugs. But unit tests aren’t just about finding bugs, it’s about writing code that’s being tested. And already this goal leads us to a good decomposition of code into parts, as well as the use of compositional approaches that allow us to replace the implementation of most components during testing. 13. Test doubles (duplication) This chapter discusses strategies for using duplicates such as mocks, stalls, and fakes, which are used to simulate parts of a system in isolation. This ensures that unit tests remain local and can be run without depending on external components. 14. Larger testing (larger-scale testing) In this chapter, the authors go beyond unit tests and talk about integration, system and end2end tests. They explain how these broader tests check that multiple components work correctly together. 15. Deprecation (obsolescence) The authors offer recommendations for decommissioning old or outdated code. They emphasize life cycle management of functions and code paths to maintain stability while allowing evolution and improvement.

The ending will be in the last post of this series.

#Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps