Google的软件工程(影印版)
Titus Winters, Tom Manshreck, Hyrum Wright 编著
出版时间:2020年12月
页数:602
今天,软件工程师不仅需要知道如何高效编程,还得知道怎样树立正确的工程实践,以便其代码库得以可持续地健康发展。本书强调了编程和软件工程之间的区别。
软件工程师该如何管理一个活跃的代码库,使其在生命周期中不断发展并响应时刻变化的需求?基于在Google的工作经验,软件工程师Titus Winters和Hyrum Wright以及技术作家Tom Manshreck,坦率而深刻地讲述了一些世界优秀的从业者如何构建和维护软件。本书介绍了Google独特的工程文化、流程和工具,以及这些方面如何对工程组织的有效性做出贡献。
你将探索软件组织在设计、架构化、编写和维护代码时应牢记的三个基本原则:
● 时间如何影响软件的可持续性,如何使代码随着时间的推移而具有弹性
● 规模如何影响工程组织内部软件实践的可行性
● 在评估设计和开发决策时,工程师需要做出怎样的利弊权衡
  1. Foreword
  2. Preface
  3. Part I. Thesis
  4. 1. What Is Software Engineering?
  5. Time and Change
  6. Hyrum’s Law
  7. Example: Hash Ordering
  8. Why Not Just Aim for “Nothing Changes”?
  9. Scale and Efficiency
  10. Policies That Don’t Scale
  11. Policies That Scale Well
  12. Example: Compiler Upgrade
  13. Shifting Left
  14. Trade-offs and Costs
  15. Example: Markers
  16. Inputs to Decision Making
  17. Example: Distributed Builds
  18. Example: Deciding Between Time and Scale
  19. Revisiting Decisions, Making Mistakes
  20. Software Engineering Versus Programming
  21. Conclusion
  22. TL;DRs
  23. Part II. Culture
  24. 2. How to Work Well on Teams
  25. Help Me Hide My Code
  26. The Genius Myth
  27. Hiding Considered Harmful
  28. Early Detection
  29. The Bus Factor
  30. Pace of Progress
  31. In Short, Don’t Hide
  32. It’s All About the Team
  33. The Three Pillars of Social Interaction
  34. Why Do These Pillars Matter?
  35. Humility, Respect, and Trust in Practice
  36. Blameless Post-Mortem Culture
  37. Being Googley
  38. Conclusion
  39. TL;DRs
  40. 3. Knowledge Sharing
  41. Challenges to Learning
  42. Philosophy
  43. Setting the Stage: Psychological Safety
  44. Mentorship
  45. Psychological Safety in Large Groups
  46. Growing Your Knowledge
  47. Ask Questions
  48. Understand Context
  49. Scaling Your Questions: Ask the Community
  50. Group Chats
  51. Mailing Lists
  52. YAQS: Question-and-Answer Platform
  53. Scaling Your Knowledge: You Always Have Something to Teach
  54. Office Hours
  55. Tech Talks and Classes
  56. Documentation
  57. Code
  58. Scaling Your Organization’s Knowledge
  59. Cultivating a Knowledge-Sharing Culture
  60. Establishing Canonical Sources of Information
  61. Staying in the Loop
  62. Readability: Standardized Mentorship Through Code Review
  63. What Is the Readability Process?
  64. Why Have This Process?
  65. Conclusion
  66. TL;DRs
  67. 4. Engineering for Equity
  68. Bias Is the Default
  69. Understanding the Need for Diversity
  70. Building Multicultural Capacity
  71. Making Diversity Actionable
  72. Reject Singular Approaches
  73. Challenge Established Processes
  74. Values Versus Outcomes
  75. Stay Curious, Push Forward
  76. Conclusion
  77. TL;DRs
  78. 5. How to Lead a Team
  79. Managers and Tech Leads (and Both)
  80. The Engineering Manager
  81. The Tech Lead
  82. The Tech Lead Manager
  83. Moving from an Individual Contributor Role to a Leadership Role
  84. The Only Thing to Fear Is...Well, Everything
  85. Servant Leadership
  86. The Engineering Manager
  87. Manager Is a Four-Letter Word
  88. Today’s Engineering Manager
  89. Antipatterns
  90. Antipattern: Hire Pushovers
  91. Antipattern: Ignore Low Performers
  92. Antipattern: Ignore Human Issues
  93. Antipattern: Be Everyone’s Friend
  94. Antipattern: Compromise the Hiring Bar
  95. Antipattern: Treat Your Team Like Children
  96. Positive Patterns
  97. Lose the Ego
  98. Be a Zen Master
  99. Be a Catalyst
  100. Remove Roadblocks
  101. Be a Teacher and a Mentor
  102. Set Clear Goals
  103. Be Honest
  104. Track Happiness
  105. The Unexpected Question
  106. Other Tips and Tricks
  107. People Are Like Plants
  108. Intrinsic Versus Extrinsic Motivation
  109. Conclusion
  110. TL;DRs
  111. 6. Leading at Scale
  112. Always Be Deciding
  113. The Parable of the Airplane
  114. Identify the Blinders
  115. Identify the Key Trade-Offs
  116. Decide, Then Iterate
  117. Always Be Leaving
  118. Your Mission: Build a “Self-Driving” Team
  119. Dividing the Problem Space
  120. Always Be Scaling
  121. The Cycle of Success
  122. Important Versus Urgent
  123. Learn to Drop Balls
  124. Protecting Your Energy
  125. Conclusion
  126. TL;DRs
  127. 7. Measuring Engineering Productivity
  128. Why Should We Measure Engineering Productivity?
  129. Triage: Is It Even Worth Measuring?
  130. Selecting Meaningful Metrics with Goals and Signals
  131. Goals
  132. Signals
  133. Metrics
  134. Using Data to Validate Metrics
  135. Taking Action and Tracking Results
  136. Conclusion
  137. TL;DRs
  138. Part III. Processes
  139. 8. Style Guides and Rules
  140. Why Have Rules?
  141. Creating the Rules
  142. Guiding Principles
  143. The Style Guide
  144. Changing the Rules
  145. The Process
  146. The Style Arbiters
  147. Exceptions
  148. Guidance
  149. Applying the Rules
  150. Error Checkers
  151. Code Formatters
  152. Conclusion
  153. TL;DRs
  154. 9. Code Review
  155. Code Review Flow
  156. How Code Review Works at Google
  157. Code Review Benefits
  158. Code Correctness
  159. Comprehension of Code
  160. Code Consistency
  161. Psychological and Cultural Benefits
  162. Knowledge Sharing
  163. Code Review Best Practices
  164. Be Polite and Professional
  165. Write Small Changes
  166. Write Good Change Descriptions
  167. Keep Reviewers to a Minimum
  168. Automate Where Possible
  169. Types of Code Reviews
  170. Greenfield Code Reviews
  171. Behavioral Changes, Improvements, and Optimizations
  172. Bug Fixes and Rollbacks
  173. Refactorings and Large-Scale Changes
  174. Conclusion
  175. TL;DRs
  176. 10. Documentation
  177. What Qualifies as Documentation?
  178. Why Is Documentation Needed?
  179. Documentation Is Like Code
  180. Know Your Audience
  181. Types of Audiences
  182. Documentation Types
  183. Reference Documentation
  184. Design Docs
  185. Tutorials
  186. Conceptual Documentation
  187. Landing Pages
  188. Documentation Reviews
  189. Documentation Philosophy
  190. WHO, WHAT, WHEN, WHERE, and WHY
  191. The Beginning, Middle, and End
  192. The Parameters of Good Documentation
  193. Deprecating Documents
  194. When Do You Need Technical Writers?
  195. Conclusion
  196. TL;DRs
  197. 11. Testing Overview
  198. Why Do We Write Tests?
  199. The Story of Google Web Server
  200. Testing at the Speed of Modern Development
  201. Write, Run, React
  202. Benefits of Testing Code
  203. Designing a Test Suite
  204. Test Size
  205. Test Scope
  206. The Beyoncé Rule
  207. A Note on Code Coverage
  208. Testing at Google Scale
  209. The Pitfalls of a Large Test Suite
  210. History of Testing at Google
  211. Orientation Classes
  212. Test Certified
  213. Testing on the Toilet
  214. Testing Culture Today
  215. The Limits of Automated Testing
  216. Conclusion
  217. TL;DRs
  218. 12. Unit Testing
  219. The Importance of Maintainability
  220. Preventing Brittle Tests
  221. Strive for Unchanging Tests
  222. Test via Public APIs
  223. Test State, Not Interactions
  224. Writing Clear Tests
  225. Make Your Tests Complete and Concise
  226. Test Behaviors, Not Methods
  227. Don’t Put Logic in Tests
  228. Write Clear Failure Messages
  229. Tests and Code Sharing: DAMP, Not DRY
  230. Shared Values
  231. Shared Setup
  232. Shared Helpers and Validation
  233. Defining Test Infrastructure
  234. Conclusion
  235. TL;DRs
  236. 13. Test Doubles
  237. The Impact of Test Doubles on Software Development
  238. Test Doubles at Google
  239. Basic Concepts
  240. An Example Test Double
  241. Seams
  242. Mocking Frameworks
  243. Techniques for Using Test Doubles
  244. Faking
  245. Stubbing
  246. Interaction Testing
  247. Real Implementations
  248. Prefer Realism Over Isolation
  249. How to Decide When to Use a Real Implementation
  250. Faking
  251. Why Are Fakes Important?
  252. When Should Fakes Be Written?
  253. The Fidelity of Fakes
  254. Fakes Should Be Tested
  255. What to Do If a Fake Is Not Available
  256. Stubbing
  257. The Dangers of Overusing Stubbing
  258. When Is Stubbing Appropriate?
  259. Interaction Testing
  260. Prefer State Testing Over Interaction Testing
  261. When Is Interaction Testing Appropriate?
  262. Best Practices for Interaction Testing
  263. Conclusion
  264. TL;DRs
  265. 14. Larger Testing
  266. What Are Larger Tests?
  267. Fidelity
  268. Common Gaps in Unit Tests
  269. Why Not Have Larger Tests?
  270. Larger Tests at Google
  271. Larger Tests and Time
  272. Larger Tests at Google Scale
  273. Structure of a Large Test
  274. The System Under Test
  275. Test Data
  276. Verification
  277. Types of Larger Tests
  278. Functional Testing of One or More Interacting Binaries
  279. Browser and Device Testing
  280. Performance, Load, and Stress testing
  281. Deployment Configuration Testing
  282. Exploratory Testing
  283. A/B Diff Regression Testing
  284. UAT
  285. Probers and Canary Analysis
  286. Disaster Recovery and Chaos Engineering
  287. User Evaluation
  288. Large Tests and the Developer Workflow
  289. Authoring Large Tests
  290. Running Large Tests
  291. Owning Large Tests
  292. Conclusion
  293. TL;DRs
  294. 15. Deprecation
  295. Why Deprecate?
  296. Why Is Deprecation So Hard?
  297. Deprecation During Design
  298. Types of Deprecation
  299. Advisory Deprecation
  300. Compulsory Deprecation
  301. Deprecation Warnings
  302. Managing the Deprecation Process
  303. Process Owners
  304. Milestones
  305. Deprecation Tooling
  306. Conclusion
  307. TL;DRs
  308. Part IV. Tools
  309. 16. Version Control and Branch Management
  310. What Is Version Control?
  311. Why Is Version Control Important?
  312. Centralized VCS Versus Distributed VCS
  313. Source of Truth
  314. Version Control Versus Dependency Management
  315. Branch Management
  316. Work in Progress Is Akin to a Branch
  317. Dev Branches
  318. Release Branches
  319. Version Control at Google
  320. One Version
  321. Scenario: Multiple Available Versions
  322. The “One-Version” Rule
  323. (Nearly) No Long-Lived Branches
  324. What About Release Branches?
  325. Monorepos
  326. Future of Version Control
  327. Conclusion
  328. TL;DRs
  329. 17. Code Search
  330. The Code Search UI
  331. How Do Googlers Use Code Search?
  332. Where?
  333. What?
  334. How?
  335. Why?
  336. Who and When?
  337. Why a Separate Web Tool?
  338. Scale
  339. Zero Setup Global Code View
  340. Specialization 356 Integration with Other Developer Tools
  341. API Exposure 359 Impact of Scale on Design
  342. Search Query Latency 359 Index Latency
  343. Google’s Implementation 361 Search Index
  344. Ranking 363 Selected Trade-Offs
  345. Completeness: Repository at Head
  346. Completeness: All Versus Most-Relevant Results
  347. Completeness: Head Versus Branches Versus All History Versus
  348. Workspaces
  349. Expressiveness: Token Versus Substring Versus Regex
  350. Conclusion
  351. TL;DRs
  352. 18. Build Systems and Build Philosophy
  353. Purpose of a Build System
  354. What Happens Without a Build System?
  355. But All I Need Is a Compiler!
  356. Shell Scripts to the Rescue?
  357. Modern Build Systems
  358. It’s All About Dependencies
  359. Task-Based Build Systems
  360. Artifact-Based Build Systems
  361. Distributed Builds
  362. Time, Scale, Trade-Offs
  363. Dealing with Modules and Dependencies
  364. Using Fine-Grained Modules and the 1:1:1 Rule
  365. Minimizing Module Visibility
  366. Managing Dependencies
  367. Conclusion
  368. TL;DRs
  369. 19. Critique: Google’s Code Review Tool
  370. Code Review Tooling Principles
  371. Code Review Flow
  372. Notifications
  373. Stage 1: Create a Change
  374. Diffing
  375. Analysis Results
  376. Tight Tool Integration
  377. Stage 2: Request Review
  378. Stages 3 and 4: Understanding and Commenting on a Change
  379. Commenting
  380. Understanding the State of a Change
  381. Stage 5: Change Approvals (Scoring a Change)
  382. Stage 6: Commiting a Change
  383. After Commit: Tracking History
  384. Conclusion
  385. TL;DRs
  386. 20. Static Analysis
  387. Characteristics of Effective Static Analysis
  388. Scalability
  389. Usability
  390. Key Lessons in Making Static Analysis Work
  391. Focus on Developer Happiness
  392. Make Static Analysis a Part of the Core Developer Workflow
  393. Empower Users to Contribute
  394. Tricorder: Google’s Static Analysis Platform
  395. Integrated Tools
  396. Integrated Feedback Channels
  397. Suggested Fixes
  398. Per-Project Customization
  399. Presubmits
  400. Compiler Integration
  401. Analysis While Editing and Browsing Code
  402. Conclusion
  403. TL;DRs
  404. 21. Dependency Management
  405. Why Is Dependency Management So Difficult?
  406. Conflicting Requirements and Diamond Dependencies
  407. Importing Dependencies
  408. Compatibility Promises
  409. Considerations When Importing
  410. How Google Handles Importing Dependendencies
  411. Dependency Management, In Theory
  412. Nothing Changes (aka The Static Dependency Model)
  413. Semantic Versioning
  414. Bundled Distribution Models
  415. Live at Head
  416. The Limitations of SemVer
  417. SemVer Might Overconstrain
  418. SemVer Might Overpromise
  419. Motivations
  420. Minimum Version Selection
  421. So, Does SemVer Work?
  422. Dependency Management with Infinite Resources
  423. Exporting Dependencies
  424. Conclusion
  425. TL;DRs
  426. 22. Large-Scale Changes
  427. What Is a Large-Scale Change?
  428. Who Deals with LSCs?
  429. Barriers to Atomic Changes
  430. Technical Limitations
  431. Merge Conflicts
  432. No Haunted Graveyards
  433. Heterogeneity
  434. Testing
  435. Code Review
  436. LSC Infrastructure
  437. Policies and Culture
  438. Codebase Insight
  439. Change Management
  440. Testing
  441. Language Support
  442. The LSC Process
  443. Authorization
  444. Change Creation
  445. Sharding and Submitting
  446. Cleanup
  447. Conclusion
  448. TL;DRs
  449. 23. Continuous Integration
  450. CI Concepts
  451. Fast Feedback Loops
  452. Automation
  453. Continuous Testing
  454. CI Challenges
  455. Hermetic Testing
  456. CI at Google
  457. CI Case Study: Google Takeout
  458. But I Can’t Afford CI
  459. Conclusion
  460. TL;DRs
  461. 24. Continuous Delivery
  462. Idioms of Continuous Delivery at Google
  463. Velocity Is a Team Sport: How to Break Up a Deployment into Manageable Pieces
  464. Evaluating Changes in Isolation: Flag-Guarding Features
  465. Striving for Agility: Setting Up a Release Train
  466. No Binary Is Perfect
  467. Meet Your Release Deadline
  468. Quality and User-Focus: Ship Only What Gets Used
  469. Shifting Left: Making Data-Driven Decisions Earlier
  470. Changing Team Culture: Building Discipline into Deployment
  471. Conclusion
  472. TL;DRs
  473. 25. Compute as a Service
  474. Taming the Compute Environment
  475. Automation of Toil
  476. Containerization and Multitenancy
  477. Summary
  478. Writing Software for Managed Compute
  479. Architecting for Failure
  480. Batch Versus Serving
  481. Managing State
  482. Connecting to a Service
  483. One-Off Code
  484. CaaS Over Time and Scale
  485. Containers as an Abstraction
  486. One Service to Rule Them All
  487. Submitted Configuration
  488. Choosing a Compute Service
  489. Centralization Versus Customization
  490. Level of Abstraction: Serverless
  491. Public Versus Private
  492. Conclusion
  493. TL;DRs
  494. Part V. Conclusion
  495. Afterword
  496. Index
书名:Google的软件工程(影印版)
国内出版社:东南大学出版社
出版时间:2020年12月
页数:602
书号:978-7-5641-9207-5
原版书书名:Software Engineering at Google
原版书出版商:O'Reilly Media
Titus Winters
 
Titus Winters,Google资深软件工程师,是Google C++代码库的负责人:每月有数以千计的各色工程师编辑2.5亿行代码。
 
 
Tom Manshreck
 
Tom Manshreck是Google软件工程部门的专职技术作家。他是C++库团队的成员之一,负责开发文档,推出培训课程并为Google的开源C++代码Abseil编制文档。
 
 
Hyrum Wright
 
Hyrum Wright是Google的一名资深软件工程师,他领导着Google的自动变更工具组。Hyrum对Google的代码库所做的个人编辑比公司历史上的任何工程师都多。
 
 
The animal on the cover of Software Engineering at Google is an American flamingo (Phoenicopterus ruber). This bird can be found primarily near the coast in Central and South America and the Gulf of Mexico, though they will sometimes travel as far as Southern Florida in the United States. The flamingo’s habitat consists of mudflats and coastal salt water lagoons.
The iconic pink plumage of the flamingo is acquired as the bird matures and comes from carotenoid pigments in its food. Because these pigments are more readily found in their natural food sources, wild flamingos tend to display more vibrant plumage than their captive counterparts, although zoos will sometimes add supplemental pig‐ ments to their diets. Flamingos are typically about 42 inches tall, and their black- tipped wingspan extends approximately five feet. A wading bird, the flamingo has webbed, three-toed pink feet. Though there are no common distinctions between male and female flamingos, males tend to be a little larger.
Flamingos are filter feeders and use their long legs and necks to feed in deep water, and they spend most of their day searching for food. They have two rows of lamellae inside their bills, which are comb-like bristles that filter their diet of seeds, algae, microscopic organisms, and small shrimp. Flamingos live in large groups of up to 10,000 and will migrate when they have eaten all the food in one location. In addition to being social birds, flamingos are extremely vocal. They have location calls to help find specific mates and alarm calls to warn the larger group.
Though it was once considered a part of the same species as the greater flamingo (Phoenicopterus roseus), which may be found in Africa, Asia, and souther Europe, the American flamingo is now considered to be a separate species. While the American flamingo’s current conservation status is currently listed as of Least Concern, many of the animals on O’Reilly covers are endangered; all of them are important to the world.
购买选项
定价:118.00元
书号:978-7-5641-9207-5
出版社:东南大学出版社