Osoby które kupowały "Software Engineering at Google. Lessons Learned from Programming Over Time", wybierały także:

• Wyrażenia regularne od podstaw 39,67 zÅ‚, (11,90 zÅ‚ -70%)
• Projektowanie systemów rozproszonych. Wzorce i paradygmaty dla skalowalnych, niezawodnych usÅ‚ug 39,67 zÅ‚, (11,90 zÅ‚ -70%)
• Programuj tak, aby nie naprawiać. Planowanie projektów i systemów 86,77 zÅ‚, (26,90 zÅ‚ -69%)
• F# 4.0 dla zaawansowanych. Wydanie IV 96,45 zÅ‚, (29,90 zÅ‚ -69%)
• Systemy reaktywne. Wzorce projektowe i ich stosowanie 65,31 zÅ‚, (20,90 zÅ‚ -68%)

Spis treści

Software Engineering at Google. Lessons Learned from Programming Over Time eBook -- spis treści

• Foreword
• Preface
  • Programming Over Time
  • Googles Perspective
  • What This Book Isnt
  • Parting Remarks
  • Conventions Used in This Book
  • OReilly Online Learning
  • How to Contact Us
  • Acknowledgments
• I. Thesis
• 1. What Is Software Engineering?
  • Time and Change
    • Hyrums Law
    • Example: Hash Ordering
    • Why Not Just Aim for Nothing Changes?
  • Scale and Efficiency
    • Policies That Dont Scale
    • Policies That Scale Well
    • Example: Compiler Upgrade
    • Shifting Left
  • Trade-offs and Costs
    • Example: Markers
    • Inputs to Decision Making
    • Example: Distributed Builds
    • Example: Deciding Between Time and Scale
    • Revisiting Decisions, Making Mistakes
  • Software Engineering Versus Programming
  • Conclusion
  • TL;DRs
• II. Culture
• 2. How to Work Well on Teams
  • Help Me Hide My Code
  • The Genius Myth
  • Hiding Considered Harmful
    • Early Detection
    • The Bus Factor
    • Pace of Progress
    • In Short, Dont Hide
  • Its All About the Team
    • The Three Pillars of Social Interaction
    • Why Do These Pillars Matter?
    • Humility, Respect, and Trust in Practice
      • Lose the ego
      • Learn to give and take criticism
      • Fail fast and iterate
    • Blameless Post-Mortem Culture
      • Learn patience
      • Be open to influence
    • Being Googley
  • Conclusion
  • TL;DRs
• 3. Knowledge Sharing
  • Challenges to Learning
  • Philosophy
  • Setting the Stage: Psychological Safety
    • Mentorship
    • Psychological Safety in Large Groups
  • Growing Your Knowledge
    • Ask Questions
    • Understand Context
  • Scaling Your Questions: Ask the Community
    • Group Chats
    • Mailing Lists
    • YAQS: Question-and-Answer Platform
  • Scaling Your Knowledge: You Always Have Something to Teach
    • Office Hours
    • Tech Talks and Classes
    • Documentation
      • Updating documentation
      • Creating documentation
      • Promoting documentation
    • Code
  • Scaling Your Organizations Knowledge
    • Cultivating a Knowledge-Sharing Culture
      • Respect
      • Incentives and recognition
    • Establishing Canonical Sources of Information
      • Developer guides
      • go/ links
      • Codelabs
      • Static analysis
    • Staying in the Loop
      • Newsletters
      • Communities
  • Readability: Standardized Mentorship Through Code Review
    • What Is the Readability Process?
    • Why Have This Process?
  • Conclusion
  • TL;DRs
• 4. Engineering for Equity
  • Bias Is the Default
  • Understanding the Need for Diversity
  • Building Multicultural Capacity
  • Making Diversity Actionable
  • Reject Singular Approaches
  • Challenge Established Processes
  • Values Versus Outcomes
  • Stay Curious, Push Forward
  • Conclusion
  • TL;DRs
• 5. How to Lead a Team
  • Managers and Tech Leads (and Both)
    • The Engineering Manager
    • The Tech Lead
    • The Tech Lead Manager
  • Moving from an Individual Contributor Role to a Leadership Role
    • The Only Thing to Fear IsWell, Everything
    • Servant Leadership
  • The Engineering Manager
    • Manager Is a Four-Letter Word
    • Todays Engineering Manager
  • Antipatterns
    • Antipattern: Hire Pushovers
    • Antipattern: Ignore Low Performers
    • Antipattern: Ignore Human Issues
    • Antipattern: Be Everyones Friend
    • Antipattern: Compromise the Hiring Bar
    • Antipattern: Treat Your Team Like Children
  • Positive Patterns
    • Lose the Ego
    • Be a Zen Master
    • Be a Catalyst
    • Remove Roadblocks
    • Be a Teacher and a Mentor
    • Set Clear Goals
    • Be Honest
    • Track Happiness
  • The Unexpected Question
  • Other Tips and Tricks
  • People Are Like Plants
    • Intrinsic Versus Extrinsic Motivation
  • Conclusion
  • TL;DRs
• 6. Leading at Scale
  • Always Be Deciding
    • The Parable of the Airplane
    • Identify the Blinders
    • Identify the Key Trade-Offs
    • Decide, Then Iterate
  • Always Be Leaving
    • Your Mission: Build a Self-Driving Team
    • Dividing the Problem Space
      • Example: Subdividing the latency problem of Google Search
      • Delegating subproblems to leaders
      • Adjusting and iterating
      • Take care in anchoring a teams identity
  • Always Be Scaling
    • The Cycle of Success
    • Important Versus Urgent
    • Learn to Drop Balls
    • Protecting Your Energy
  • Conclusion
  • TL;DRs
• 7. Measuring Engineering Productivity
  • Why Should We Measure Engineering Productivity?
  • Triage: Is It Even Worth Measuring?
  • Selecting Meaningful Metrics with Goals and Signals
  • Goals
  • Signals
  • Metrics
  • Using Data to Validate Metrics
  • Taking Action and Tracking Results
  • Conclusion
  • TL;DRs
• III. Processes
• 8. Style Guides and Rules
  • Why Have Rules?
  • Creating the Rules
    • Guiding Principles
      • Rules must pull their weight
      • Optimize for the reader
      • Be consistent
      • Advantages of consistency
        • Setting the standard
      • Avoid error-prone and surprising constructs
      • Concede to practicalities
    • The Style Guide
      • Avoiding danger
      • Enforcing best practices
      • Building in consistency
      • And for everything else...
  • Changing the Rules
    • The Process
    • The Style Arbiters
    • Exceptions
  • Guidance
  • Applying the Rules
    • Error Checkers
    • Code Formatters
  • Conclusion
  • TL;DRs
• 9. Code Review
  • Code Review Flow
  • How Code Review Works at Google
  • Code Review Benefits
    • Code Correctness
    • Comprehension of Code
    • Code Consistency
    • Psychological and Cultural Benefits
    • Knowledge Sharing
  • Code Review Best Practices
    • Be Polite and Professional
    • Write Small Changes
    • Write Good Change Descriptions
    • Keep Reviewers to a Minimum
    • Automate Where Possible
  • Types of Code Reviews
    • Greenfield Code Reviews
    • Behavioral Changes, Improvements, and Optimizations
    • Bug Fixes and Rollbacks
    • Refactorings and Large-Scale Changes
  • Conclusion
  • TL;DRs
• 10. Documentation
  • What Qualifies as Documentation?
  • Why Is Documentation Needed?
  • Documentation Is Like Code
  • Know Your Audience
    • Types of Audiences
  • Documentation Types
    • Reference Documentation
      • File comments
      • Class comments
      • Function comments
    • Design Docs
    • Tutorials
      • Example: A bad tutorial
      • Example: A bad tutorial made better
    • Conceptual Documentation
    • Landing Pages
  • Documentation Reviews
  • Documentation Philosophy
    • WHO, WHAT, WHEN, WHERE, and WHY
    • The Beginning, Middle, and End
    • The Parameters of Good Documentation
    • Deprecating Documents
  • When Do You Need Technical Writers?
  • Conclusion
  • TL;DRs
• 11. Testing Overview
  • Why Do We Write Tests?
    • The Story of Google Web Server
    • Testing at the Speed of Modern Development
    • Write, Run, React
    • Benefits of Testing Code
  • Designing a Test Suite
    • Test Size
      • Small tests
      • Medium tests
      • Large tests
      • Properties common to all test sizes
        • Test sizes in practice
    • Test Scope
    • The Beyoncé Rule
    • A Note on Code Coverage
  • Testing at Google Scale
    • The Pitfalls of a Large Test Suite
  • History of Testing at Google
    • Orientation Classes
    • Test Certified
    • Testing on the Toilet
    • Testing Culture Today
  • The Limits of Automated Testing
  • Conclusion
  • TL;DRs
• 12. Unit Testing
  • The Importance of Maintainability
  • Preventing Brittle Tests
    • Strive for Unchanging Tests
    • Test via Public APIs
    • Test State, Not Interactions
  • Writing Clear Tests
    • Make Your Tests Complete and Concise
    • Test Behaviors, Not Methods
      • Structure tests to emphasize behaviors
      • Name tests after the behavior being tested
    • Dont Put Logic in Tests
    • Write Clear Failure Messages
  • Tests and Code Sharing: DAMP, Not DRY
    • Shared Values
    • Shared Setup
    • Shared Helpers and Validation
    • Defining Test Infrastructure
  • Conclusion
  • TL;DRs
• 13. Test Doubles
  • The Impact of Test Doubles on Software Development
  • Test Doubles at Google
  • Basic Concepts
    • An Example Test Double
    • Seams
    • Mocking Frameworks
  • Techniques for Using Test Doubles
    • Faking
    • Stubbing
    • Interaction Testing
  • Real Implementations
    • Prefer Realism Over Isolation
    • How to Decide When to Use a Real Implementation
      • Execution time
      • Determinism
      • Dependency construction
  • Faking
    • Why Are Fakes Important?
    • When Should Fakes Be Written?
    • The Fidelity of Fakes
    • Fakes Should Be Tested
    • What to Do If a Fake Is Not Available
  • Stubbing
    • The Dangers of Overusing Stubbing
      • Tests become unclear
      • Tests become brittle
      • Tests become less effective
      • An example of overusing stubbing
    • When Is Stubbing Appropriate?
  • Interaction Testing
    • Prefer State Testing Over Interaction Testing
    • When Is Interaction Testing Appropriate?
    • Best Practices for Interaction Testing
      • Prefer to perform interaction testing only for state-changing functions
      • Avoid overspecification
  • Conclusion
  • TL;DRs
• 14. Larger Testing
  • What Are Larger Tests?
    • Fidelity
    • Common Gaps in Unit Tests
      • Unfaithful doubles
      • Configuration issues
      • Issues that arise under load
      • Unanticipated behaviors, inputs, and side effects
      • Emergent behaviors and the vacuum effect
    • Why Not Have Larger Tests?
  • Larger Tests at Google
    • Larger Tests and Time
    • Larger Tests at Google Scale
  • Structure of a Large Test
    • The System Under Test
      • The benefits of hermetic SUTs
      • Reducing the size of your SUT at problem boundaries
      • Record/replay proxies
    • Test Data
    • Verification
  • Types of Larger Tests
    • Functional Testing of One or More Interacting Binaries
    • Browser and Device Testing
    • Performance, Load, and Stress testing
    • Deployment Configuration Testing
    • Exploratory Testing
      • Limitations
      • Bug bashes
    • A/B Diff Regression Testing
      • Limitations
    • UAT
    • Probers and Canary Analysis
      • Limitations
    • Disaster Recovery and Chaos Engineering
      • Limitations
    • User Evaluation
  • Large Tests and the Developer Workflow
    • Authoring Large Tests
    • Running Large Tests
      • Speeding up tests
      • Driving out flakiness
      • Making tests understandable
    • Owning Large Tests
  • Conclusion
  • TL;DRs
• 15. Deprecation
  • Why Deprecate?
  • Why Is Deprecation So Hard?
    • Deprecation During Design
  • Types of Deprecation
    • Advisory Deprecation
    • Compulsory Deprecation
    • Deprecation Warnings
  • Managing the Deprecation Process
    • Process Owners
    • Milestones
    • Deprecation Tooling
      • Discovery
      • Migration
      • Preventing backsliding
  • Conclusion
  • TL;DRs
• IV. Tools
• 16. Version Control and Branch Management
  • What Is Version Control?
    • Why Is Version Control Important?
    • Centralized VCS Versus Distributed VCS
      • Centralized VCS
      • Distributed VCS
    • Source of Truth
      • Scenario: no clear source of truth
    • Version Control Versus Dependency Management
  • Branch Management
    • Work in Progress Is Akin to a Branch
    • Dev Branches
      • How did we become addicted to dev branches?
    • Release Branches
  • Version Control at Google
    • One Version
    • Scenario: Multiple Available Versions
    • The One-Version Rule
    • (Nearly) No Long-Lived Branches
    • What About Release Branches?
  • Monorepos
  • Future of Version Control
  • Conclusion
  • TL;DRs
• 17. Code Search
  • The Code Search UI
  • How Do Googlers Use Code Search?
    • Where?
    • What?
    • How?
    • Why?
    • Who and When?
  • Why a Separate Web Tool?
    • Scale
    • Zero Setup Global Code View
    • Specialization
    • Integration with Other Developer Tools
    • API Exposure
  • Impact of Scale on Design
    • Search Query Latency
    • Index Latency
  • Googles Implementation
    • Search Index
    • Ranking
      • Query independent signals
      • Query dependent signals
      • Retrieval
      • Result diversity
  • Selected Trade-Offs
    • Completeness: Repository at Head
    • Completeness: All Versus Most-Relevant Results
    • Completeness: Head Versus Branches Versus All History Versus Workspaces
    • Expressiveness: Token Versus Substring Versus Regex
  • Conclusion
  • TL;DRs
• 18. Build Systems and Build Philosophy
  • Purpose of a Build System
  • What Happens Without a Build System?
    • But All I Need Is a Compiler!
    • Shell Scripts to the Rescue?
  • Modern Build Systems
    • Its All About Dependencies
    • Task-Based Build Systems
      • The dark side of task-based build systems
        • Difficulty of parallelizing build steps
        • Difficulty performing incremental builds
        • Difficulty maintaining and debugging scripts
    • Artifact-Based Build Systems
      • A functional perspective
        • Getting concrete with Bazel
      • Other nifty Bazel tricks
        • Tools as dependencies
        • Extending the build system
        • Isolating the environment
        • Making external dependencies deterministic
    • Distributed Builds
      • Remote caching
      • Remote execution
        • Distributed builds at Google
    • Time, Scale, Trade-Offs
  • Dealing with Modules and Dependencies
    • Using Fine-Grained Modules and the 1:1:1 Rule
    • Minimizing Module Visibility
    • Managing Dependencies
      • Internal dependencies
      • External dependencies
        • Automatic versus manual dependency management
        • The One-Version Rule
        • Transitive external dependencies
        • Caching build results using external dependencies
        • Security and reliability of external dependencies
  • Conclusion
  • TL;DRs
• 19. Critique: Googles Code Review Tool
  • Code Review Tooling Principles
  • Code Review Flow
    • Notifications
  • Stage 1: Create a Change
    • Diffing
    • Analysis Results
    • Tight Tool Integration
  • Stage 2: Request Review
  • Stages 3 and 4: Understanding and Commenting on a Change
    • Commenting
    • Understanding the State of a Change
      • Whose turn feature
      • Dashboard and search system
  • Stage 5: Change Approvals (Scoring a Change)
  • Stage 6: Commiting a Change
    • After Commit: Tracking History
  • Conclusion
  • TL;DRs
• 20. Static Analysis
  • Characteristics of Effective Static Analysis
    • Scalability
    • Usability
  • Key Lessons in Making Static Analysis Work
    • Focus on Developer Happiness
    • Make Static Analysis a Part of the Core Developer Workflow
    • Empower Users to Contribute
  • Tricorder: Googles Static Analysis Platform
    • Integrated Tools
    • Integrated Feedback Channels
    • Suggested Fixes
    • Per-Project Customization
    • Presubmits
    • Compiler Integration
    • Analysis While Editing and Browsing Code
  • Conclusion
  • TL;DRs
• 21. Dependency Management
  • Why Is Dependency Management So Difficult?
    • Conflicting Requirements and Diamond Dependencies
  • Importing Dependencies
    • Compatibility Promises
      • C++
      • Go
      • Abseil
      • Boost
    • Considerations When Importing
    • How Google Handles Importing Dependendencies
  • Dependency Management, In Theory
    • Nothing Changes (aka The Static Dependency Model)
    • Semantic Versioning
    • Bundled Distribution Models
    • Live at Head
  • The Limitations of SemVer
    • SemVer Might Overconstrain
    • SemVer Might Overpromise
    • Motivations
    • Minimum Version Selection
    • So, Does SemVer Work?
  • Dependency Management with Infinite Resources
    • Exporting Dependencies
      • Example: open sourcing gflags
  • Conclusion
  • TL;DRs
• 22. Large-Scale Changes
  • What Is a Large-Scale Change?
  • Who Deals with LSCs?
  • Barriers to Atomic Changes
    • Technical Limitations
    • Merge Conflicts
    • No Haunted Graveyards
    • Heterogeneity
    • Testing
    • Code Review
  • LSC Infrastructure
    • Policies and Culture
    • Codebase Insight
    • Change Management
    • Testing
    • Language Support
  • The LSC Process
    • Authorization
    • Change Creation
    • Sharding and Submitting
      • Testing
      • Mailing reviewers
      • Reviewing
      • Submitting
    • Cleanup
  • Conclusion
  • TL;DRs
• 23. Continuous Integration
  • CI Concepts
    • Fast Feedback Loops
      • Accessible and actionable feedback
    • Automation
      • Continuous Build
      • Continuous Delivery
    • Continuous Testing
      • Why presubmit isnt enough
      • Presubmit versus post-submit
      • Release candidate testing
      • Production testing
    • CI Challenges
    • Hermetic Testing
  • CI at Google
    • CI Case Study: Google Takeout
      • Scenario #1: Continuously broken dev deploys
        • What the team did
        • Lesson learned
      • Scenario #2: Indecipherable test logs
        • What the team did
        • Lesson learned
      • Scenario #3: Debugging all of Google
        • What the team did
        • Lesson learned
        • Remaining challenge
        • Future improvement
      • Scenario #4: Keeping it green
        • What the team did
        • Lessons learned
        • Future improvement
        • Further challenges
    • But I Cant Afford CI
  • Conclusion
  • TL;DRs
• 24. Continuous Delivery
  • Idioms of Continuous Delivery at Google
  • Velocity Is a Team Sport: How to Break Up a Deployment into Manageable Pieces
  • Evaluating Changes in Isolation: Flag-Guarding Features
  • Striving for Agility: Setting Up a Release Train
    • No Binary Is Perfect
    • Meet Your Release Deadline
  • Quality and User-Focus: Ship Only What Gets Used
  • Shifting Left: Making Data-Driven Decisions Earlier
  • Changing Team Culture: Building Discipline into Deployment
  • Conclusion
  • TL;DRs
• 25. Compute as a Service
  • Taming the Compute Environment
    • Automation of Toil
      • Simple automations
      • Automated scheduling
    • Containerization and Multitenancy
      • My neighbors dog barks in my RAM
      • Rightsizing and autoscaling
    • Summary
  • Writing Software for Managed Compute
    • Architecting for Failure
    • Batch Versus Serving
    • Managing State
    • Connecting to a Service
    • One-Off Code
  • CaaS Over Time and Scale
    • Containers as an Abstraction
      • Containers and implicit dependencies
    • One Service to Rule Them All
      • Multitenancy for serving jobs
    • Submitted Configuration
  • Choosing a Compute Service
    • Centralization Versus Customization
      • Need for customization
    • Level of Abstraction: Serverless
      • What is serverless?
      • Pros and cons
      • The trade-off
    • Public Versus Private
  • Conclusion
  • TL;DRs
• V. Conclusion
• Afterword
• Index