NerOcrO/clean-architecture.md

## clean-architecture.md

      
    Raw
  

              clean-architecture.md
            
          
    Clean Architecture: A Craftsman's Guide to Software Structure and Design by Robert C. Martin, 2017


PART I Introduction

Chapter 1 What Is Design and Architecture?

The Goal?
Case Study
Conclusion


Chapter 2 A Tale of Two Values

Behavior
Architecture
The Greater Value
Eisenhower’s Matrix
Fight for the Architecture


PART II Starting with the Bricks: Programming Paradigms

Chapter 3 Paradigm Overview

Structured Programming
Object-Oriented Programming
Functional Programming
Food for Thought
Conclusion


Chapter 4 Structured Programming

Proof
A Harmful Proclamation
Functional Decomposition
No Formal Proofs
Science to the Rescue
Tests
Conclusion


Chapter 5 Object-Oriented Programming

Encapsulation?
Inheritance?
Polymorphism?
Conclusion


Chapter 6 Functional Programming

Squares of Integers
Immutability and Architecture
Segregation of Mutability
Event Sourcing
Conclusion


PART III Design Principles

Chapter 7 SRP: The Single Responsibility Principle

Symptom 1: Accidental Duplication
Symptom 2: Merges
Solutions
Conclusion


Chapter 8 OCP: The Open-Closed Principle

A Thought Experiment
Directional Control
Information Hiding
Conclusion


Chapter 9 LSP: The Liskov Substitution Principle

Guiding the Use of Inheritance
The Square/Rectangle Problem
LSP and Architecture
Example LSP Violation
Conclusion


Chapter 10 ISP: The Interface Segregation Principle

ISP and Language
ISP and Architecture
Conclusion


Chapter 11 DIP: The Dependency Inversion Principle

Stable Abstractions
Factories
Concrete Components
Conclusion


PART IV Component Principles

Chapter 12 Components

A Brief History of Components
Relocatability
Linkers
Conclusion


Chapter 13 Component Cohesion

The Reuse/Release Equivalence Principle
The Common Closure Principle
The Common Reuse Principle
The Tension Diagram for Component Cohesion
Conclusion


Chapter 14 Component Coupling

The Acyclic Dependencies Principle
Top-Down Design
The Stable Dependencies Principle
The Stable Abstractions Principle
Conclusion


PART V Architecture

Chapter 15 What Is Architecture?

Development
Deployment
Operation
Maintenance
Keeping Options Open
Device Independence
Junk Mail
Physical Addressing
Conclusion


Chapter 16 Independence

Use Cases
Operation
Development
Deployment
Leaving Options Open
Decoupling Layers
Decoupling Use Cases
Decoupling Mode
Independent Develop-ability
Independent Deployability
Duplication
Decoupling Modes (Again)
Conclusion


Chapter 17 Boundaries: Drawing Lines

A Couple of Sad Stories
FitNesse
Which Lines Do You Draw, and When Do You Draw Them?
What About Input and Output?
Plugin Architecture
The Plugin Argument
Conclusion


Chapter 18 Boundary Anatomy

Boundary Crossing
The Dreaded Monolith
Deployment Components
Threads
Local Processes
Services
Conclusion


Chapter 19 Policy and Level

Level
Conclusion


Chapter 20 Business Rules

Entities
Use Cases
Request and Response Models
Conclusion


Chapter 21 Screaming Architecture

The Theme of an Architecture
The Purpose of an Architecture
But What About the Web?
Frameworks Are Tools, Not Ways of Life
Testable Architectures
Conclusion


Chapter 22 The Clean Architecture

The Dependency Rule
A Typical Scenario
Conclusion


Chapter 23 Presenters and Humble Objects

The Humble Object Pattern
Presenters and Views
Testing and Architecture
Database Gateways
Data Mappers
Service Listeners
Conclusion


Chapter 24 Partial Boundaries

Skip the Last Step
One-Dimensional Boundaries
Facades
Conclusion


Chapter 25 Layers and Boundaries

Hunt the Wumpus
Clean Architecture?
Crossing the Streams
Splitting the Streams
Conclusion


Chapter 26 The Main Component

The Ultimate Detail
Conclusion


Chapter 27 Services: Great and Small

Service Architecture?
Service Benefits?
The Kitty Problem
Objects to the Rescue
Component-Based Services
Cross-Cutting Concerns
Conclusion


Chapter 28 The Test Boundary

Tests as System Components
Design for Testability
The Testing API
Conclusion


Chapter 29 Clean Embedded Architecture

App-titude Test
The Target-Hardware Bottleneck
Conclusion


PART VI Details

Chapter 30 The Database Is a Detail

Relational Databases
Why Are Database Systems So Prevalent?
What If There Were No Disk?
Details
But What about Performance?
Anecdote
Conclusion


Chapter 31 The Web Is a Detail

The Endless Pendulum
The Upshot
Conclusion


Chapter 32 Frameworks Are Details

Framework Authors
Asymmetric Marriage
The Risks
The Solution
I Now Pronounce You …
Conclusion


Chapter 33 Case Study: Video Sales

The Product
Use Case Analysis
Component Architecture
Dependency Management
Conclusion


Chapter 34 The Missing Chapter

Package by Layer
Package by Feature
Ports and Adapters
Package by Component
The Devil Is in the Implementation Details
Organization versus Encapsulation
Other Decoupling Modes
Conclusion: The Missing Advice


PART VII Appendix

Appendix A Architecture Archaeology


## clean-code.md

      
    Raw
  

              clean-code.md
            
          
    Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, 2008


Chapter 1 Clean Code

There Will Be Code
Bad Code
The Total Cost of Owning a Mess

The Grand Redesign in the Sky
Attitude
The Primal Conundrum
The Art of Clean Code?
What Is Clean Code?


Schools of Thought
We Are Authors
The Boy Scout Rule
Prequel and Principles
Conclusion
Bibliography


Chapter 2 Meaningful Names

Introduction
Use Intention-Revealing Names
Avoid Disinformation
Make Meaningful Distinctions
Use Pronounceable Names
Use Searchable Names
Avoid Encodings

Hungarian Notation
Member Prefixes
Interfaces and Implementations


Avoid Mental Mapping
Class Names
Method Names
Don’t Be Cute
Pick One Word per Concept
Don’t Pun
Use Solution Domain Names
Use Problem Domain Names
Add Meaningful Context
Don’t Add Gratuitous Context
Final Words


Chapter 3 Functions

Small!

Blocks and Indenting


Do One Thing

Sections within Functions


One Level of Abstraction per Function

Reading Code from Top to Bottom: The Stepdown Rule


Switch Statements
Use Descriptive Names
Function Arguments

Common Monadic Forms
Flag Arguments
Dyadic Functions
Triads
Argument Objects
Argument Lists
Verbs and Keywords


Have No Side Effects

Output Arguments


Command Query Separation
Prefer Exceptions to Returning Error Codes

Extract Try/Catch Blocks
Error Handling Is One Thing
The Error.java Dependency Magnet


Don’t Repeat Yourself
Structured Programming
How Do You Write Functions Like This?
Conclusion
SetupTeardownIncluder
Bibliography


Chapter 4 Comments

Comments Do Not Make Up for Bad Code
Explain Yourself in Code
Good Comments

Legal Comments
Informative Comments
Explanation of Intent
Clarification
Warning of Consequences
TODO Comments
Amplification
Javadocs in Public APIs


Bad Comments

Mumbling
Redundant Comments
Misleading Comments
Mandated Comments
Journal Comments
Noise Comments
Scary Noise
Don’t Use a Comment When You Can Use a Function or a Variable
Position Markers
Closing Brace Comments
Attributions and Bylines
Commented-Out Code
HTML Comments
Nonlocal Information
Too Much Information
Inobvious Connection
Function Headers
Javadocs in Nonpublic Code
Example


Bibliography


Chapter 5 Formatting

The Purpose of Formatting
Vertical Formatting

The Newspaper Metaphor
Vertical Openness Between Concepts
Vertical Density
Vertical Distance
Vertical Ordering


Horizontal Formatting

Horizontal Openness and Density
Horizontal Alignment
Indentation
Dummy Scopes


Team Rules
Uncle Bob’s Formatting Rules


Chapter 6 Objects and Data Structures

Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter

Train Wrecks
Hybrids
Hiding Structure


Data Transfer Objects

Active Record


Conclusion
Bibliography


Chapter 7 Error Handling

Use Exceptions Rather Than Return Codes
Write Your Try-Catch-Finally Statement First
Use Unchecked Exceptions
Provide Context with Exceptions
Define Exception Classes in Terms of a Caller’s Needs
Define the Normal Flow
Don’t Return Null
Don’t Pass Null
Conclusion
Bibliography


Chapter 8 Boundaries

Using Third-Party Code
Exploring and Learning Boundaries
Learning log4j
Learning Tests Are Better Than Free
Using Code That Does Not Yet Exist
Clean Boundaries
Bibliography


Chapter 9 Unit Tests

The Three Laws of TDD
Keeping Tests Clean

Tests Enable the -ilities


Clean Tests

Domain-Specific Testing Language
A Dual Standard


One Assert per Test

Single Concept per Test


F.I.R.S.T.
Conclusion
Bibliography


Chapter 10 Classes

Class Organization

Encapsulation


Classes Should Be Small!

The Single Responsibility Principle
Cohesion
Maintaining Cohesion Results in Many Small Classes


Organizing for Change

Isolating from Change


Bibliography


Chapter 11 Systems

How Would You Build a City?
Separate Constructing a System from Using It

Separation of Main
Factories
Dependency Injection


Scaling Up

Cross-Cutting Concerns


Java Proxies
Pure Java AOP Frameworks
AspectJ Aspects
Test Drive the System Architecture
Optimize Decision Making
Use Standards Wisely, When They Add Demonstrable Value
Systems Need Domain-Specific Languages
Conclusion
Bibliography


Chapter 12 Emergence

Getting Clean via Emergent Design
Simple Design Rule 1: Runs All the Tests
Simple Design Rules 2–4: Refactoring
No Duplication
Expressive
Minimal Classes and Methods
Conclusion
Bibliography


Chapter 13 Concurrency

Why Concurrency?

Myths and Misconceptions


Challenges
Concurrency Defense Principles

Single Responsibility Principle
Corollary: Limit the Scope of Data
Corollary: Use Copies of Data
Corollary: Threads Should Be as Independent as Possible


Know Your Library

Thread-Safe Collections


Know Your Execution Models

Producer-Consumer
Readers-Writers
Dining Philosophers


Beware Dependencies Between Synchronized Methods
Keep Synchronized Sections Small
Writing Correct Shut-Down Code Is Hard
Testing Threaded Code

Treat Spurious Failures as Candidate Threading Issues
Get Your Nonthreaded Code Working First
Make Your Threaded Code Pluggable
Make Your Threaded Code Tunable
Run with More Threads Than Processors
Run on Different Platforms
Instrument Your Code to Try and Force Failures
Hand-Coded
Automated


Conclusion
Bibliography


Chapter 14 Successive Refinement

Args Implementation

How Did I Do This?


Args: The Rough Draft

So I Stopped
On Incrementalism


String Arguments
Conclusion


Chapter 15 JUnit Internals

The JUnit Framework
Conclusion


Chapter 16 Refactoring SerialDate

First, Make It Work
Then Make It Right
Conclusion
Bibliography


Chapter 17 Smells and Heuristics

Comments

C1: Inappropriate Information
C2: Obsolete Comment
C3: Redundant Comment
C4: Poorly Written Comment
C5: Commented-Out Code


Environment

E1: Build Requires More Than One Step
E2: Tests Require More Than One Step


Functions

F1: Too Many Arguments
F2: Output Arguments
F3: Flag Arguments
F4: Dead Function


General

G1: Multiple Languages in One Source File
G2: Obvious Behavior Is Unimplemented
G3: Incorrect Behavior at the Boundaries
G4: Overridden Safeties
G5: Duplication
G6: Code at Wrong Level of Abstraction
G7: Base Classes Depending on Their Derivatives
G8: Too Much Information
G9: Dead Code
G10: Vertical Separation
G11: Inconsistency
G12: Clutter
G13: Artificial Coupling
G14: Feature Envy
G15: Selector Arguments
G16: Obscured Intent
G17: Misplaced Responsibility
G18: Inappropriate Static
G19: Use Explanatory Variables
G20: Function Names Should Say What They Do
G21: Understand the Algorithm
G22: Make Logical Dependencies Physical
G23: Prefer Polymorphism to If/Else or Switch/Case
G24: Follow Standard Conventions
G25: Replace Magic Numbers with Named Constants
G26: Be Precise
G27: Structure over Convention
G28: Encapsulate Conditionals
G29: Avoid Negative Conditionals
G30: Functions Should Do One Thing
G31: Hidden Temporal Couplings
G32: Don’t Be Arbitrary
G33: Encapsulate Boundary Conditions
G34: Functions Should Descend Only One Level of Abstraction
G35: Keep Configurable Data at High Levels
G36: Avoid Transitive Navigation


Java

J1: Avoid Long Import Lists by Using Wildcards
J2: Don’t Inherit Constants
J3: Constants versus Enums


Names

N1: Choose Descriptive Names
N2: Choose Names at the Appropriate Level of Abstraction
N3: Use Standard Nomenclature Where Possible
N4: Unambiguous Names
N5: Use Long Names for Long Scopes
N6: Avoid Encodings
N7: Names Should Describe Side-Effects.


Tests

T1: Insufficient Tests
T2: Use a Coverage Tool!
T3: Don’t Skip Trivial Tests
T4: An Ignored Test Is a Question about an Ambiguity
T5: Test Boundary Conditions
T6: Exhaustively Test Near Bugs
T7: Patterns of Failure Are Revealing
T8: Test Coverage Patterns Can Be Revealing
T9: Tests Should Be Fast


Conclusion
Bibliography


Appendix A Concurrency II

Client/Server Example

The Server
Adding Threading
Server Observations
Conclusion


Possible Paths of Execution

Number of Paths
Digging Deeper
Conclusion


Knowing Your Library

Executor Framework
Nonblocking Solutions
Nonthread-Safe Classes


Dependencies Between Methods Can Break Concurrent Code

Tolerate the Failure
Client-Based Locking
Server-Based Locking


Increasing Throughput

Single-Thread Calculation of Throughput
Multithread Calculation of Throughput


Deadlock

Mutual Exclusion
Lock & Wait
No Preemption
Circular Wait
Breaking Mutual Exclusion
Breaking Lock & Wait
Breaking Preemption
Breaking Circular Wait


Testing Multithreaded Code
Tool Support for Testing Thread-Based Code
Conclusion
Tutorial: Full Code Examples

Client/Server Nonthreaded
Client/Server Using Threads


Appendix B org.jfree.date.SerialDate
Appendix C Cross References of Heuristics


## legacy-code.md

      
    Raw
  

              legacy-code.md
            
          
    Working Effectively with Legacy Code by Michael C. Feathers, 2004


Part I The Mechanics of Change

Chapter 1 Changing Software

Four Reasons to Change Software
Risky Change


Chapter 2 Working with Feedback

What Is Unit Testing?
Higher-Level Testing
Test Coverings
The Legacy Code Change Algorithm


Chapter 3 Sensing and Separation

Faking Collaborators


Chapter 4 The Seam Model

A Huge Sheet of Text
Seams
Seam Types


Chapter 5 Tools

Automated Refactoring Tools
Mock Objects
Unit-Testing Harnesses
General Test Harnesses


Part II Changing Software

Chapter 6 I Don’t Have Much Time and I Have to Change It

Sprout Method
Sprout Class
Wrap Method
Wrap Class
Summary


Chapter 7 It Takes Forever to Make a Change

Understanding
Lag Time
Breaking Dependencies
Summary


Chapter 8 How Do I Add a Feature?

Test-Driven Development (TDD)
Programming by Difference
Summary


Chapter 9 I Can’t Get This Class into a Test Harness

The Case of the Irritating Parameter
The Case of the Hidden Dependency
The Case of the Construction Blob
The Case of the Irritating Global Dependency
The Case of the Horrible Include Dependencies
The Case of the Onion Parameter
The Case of the Aliashed Parameter


Chapter 10 I Can’t Run This Method in a Test Harness

The Case of the Hidden Method
The Case of the Helpful Language Feature
The Case of the Undectable Side Effect


Chapter 11 I Need to Make a Change. What Methods Should I Test?

Reasoning About Effects
Reasoning Forward
Effect Propagation
Tools for Effect Reasoning
Learning from Effect Analysis
Simplifying Effect Sketches


Chapter 12 I Need to Make Many Changes in One Area. Do I Have to Break Dependencies for All the Classes Involved?

Interception Points
Judging Design with Pinch Points
Pinch Point Traps


Chapter 13 I Need to Make a Change, but I Don’t Know What Tests to Write

Characterization Tests
Characterization Classes
Targeted Testing
A Heuristic for Writing Characterization Tests


Chapter 14 Dependencies on Libraries Are Killing Me
Chapter 15 My Application Is All API Calls
Chapter 16 I Don’t Understand the Code Well Enough to Change It

Notes/Sketching
Listing Markup
Scratch Refactoring
Delete Unused Code


Chapter 17 My Application Has No Structure

Telling the Story of the System
Naked CRC
Conversation scrutiny


Chapter 18 My Test Code Is in the Way

Class Naming Conventions
Test Location


Chapter 19 My Project Is Not Object Oriented. How Do I Make Safe Changes?

An Easy Case
A Hard Case
Adding New Behavior
Taking Advantage of Object Orientation
It's All Object Oriented


Chapter 20 This Class Is Too Big and I Don’t Want It to Get Any Bigger

Seeing Responsibilities
Other Techniques
Moving Forward
After Extract Class


Chapter 21 I’m Changing the Same Code All Over the Place

First Steps


Chapter 22 I Need to Change a Monster Method and I Can’t Write Tests for It

Varieties of Monsters
Tackling Monsters with Automated Refactoring Support
The Manual Refactoring Challenge
Strategy


Chapter 23 How Do I Know That I’m Not Breaking Anything?

Hyperaware Editing
Single-Goal Editing
Preserve Signatures
Lean on the Compiler


Chapter 24 We Feel Overwhelmed. It Isn’t Going to Get Any Better


Part III Dependency-Breaking Techniques

Chapter 25 Dependency-Breaking Techniques

Adapt Parameter
Break Out Method Object
Definition Completion
Encapsulate Global References
Expose Static Method
Extract and Override Call
Extract and Override Factory Method
Extract and Override Getter
Extract Implementer
Extract Interface
Introduce Instance Delegator
Introduce Static Setter
Link Substitution
Parameterize Constructor
Parameterize Method
Primitivize Parameter
Pull Up Feature
Push Down Dependency
Replace Function with Function Pointer
Replace Global Reference with Getter
Subclass and Override Method
Supersede Instance Variable
Template Redefinition
Text Redefinition


Appendix: Refactoring

Extract Method


## tdd.md

      
    Raw
  

              tdd.md
            
          
    Test Driven Development: By Example by Ken Beck, 2002


Part I The Money Example

Chapter 1 Multi-Currency Money
Chapter 2 Degenerate Objects
Chapter 3 Equality for All
Chapter 4 Privacy
Chapter 5 Franc-ly Speaking
Chapter 6 Equality for All, Redux
Chapter 7 Apples and Oranges
Chapter 8 Makin' Objects
Chapter 9 Times We're Livin' In
Chapter 10 Interesting Times
Chapter 11 The Root of All Evil
Chapter 12 Addition, Finally
Chapter 13 Make It
Chapter 14 Change
Chapter 15 Mixed Currencies
Chapter 16 Abstraction, Finally
Chapter 17 Money Retrospective


Part II The xUnit Example

Chapter 18 First Steps to xUnit
Chapter 19 Set the Table
Chapter 20 Cleaning Up After
Chapter 21 Counting
Chapter 22 Dealing with Failure
Chapter 23 How Suite It Is
Chapter 24 xUnit Retrospective


Part III Patterns for Test-Driven Development

Chapter 25 Test-Driven Development Patterns
Chapter 26 Red Bar Patterns
Chapter 27 Testing Patterns
Chapter 28 Green Bar Patterns
Chapter 29 xUnit Patterns
Chapter 30 Design Patterns
Chapter 31 Refactoring
Chapter 32 Mastering TDD


Appendix I Influence Diagrams
Appendix II Fibonacci


## the-clean-coder.md

      
    Raw
  

              the-clean-coder.md
            
          
    The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin, 2011


Chapter 1 Professionalism

Be Careful What You Ask For
Taking Responsability
First, Do No Harm
Work Ethic
Bibliography


Chapter 2 Saying No

Adversarial Roles
High Stakes
Being a Team Player
The Cost of Saying Yes
Code Impossible


Chapter 3 Saying Yes

A Language of Commitment
Learning How to Say Yes
Conclusion


Chapter 4 Coding

Preparedness
The Flow Zone
Writer's Block
Debugging
Pacing Yourself
Being Late
Helo
Bibliography


Chapter 5 Test Driven Development

The Jury Is In
The Three Laws of TDD
What TDD Is Not
Bibliography


Chapter 6 Practicing

Some Background on Practicing
The Coding Dojo
Broadening Your Experience
Conclusion
Bibliography


Chapter 7 Acceptance Testing

Communicating Requirements
Acceptance Tests
Conclusion


Chapter 8 Testing Strategies

QA Should Find Nothing
The Test Automation Pyramid
Conclusion
Bibliography


Chapter 9 Time Management

Meetings
Focus-Manna
Time Boxing and Tomatoes
Avoidance
Blind Alleys
Marshes, Bogs, Swamps, and Other Messes
Conclusion


Chapter 10 Estimation

What Is an Estimate?
PERT
Estimating Tasks
The Law of Large Numbers
Conclusion
Bibliography


Chapter 11 Pressure

Avoiding Pressure
Handling Pressure
Conclusion


Chapter 12 Collaboration

Programmers versus People
Cerebellums
Conclusion


Chapter 13 Teams and Projects

Does It Blend?
Conclusion
Bibliography


Chapter 14 Mentoring, Apprenticeship, and Craftsmanship

Degrees of Failure
Mentoring
Apprenticeship
Craftsmanship
Conclusion


Appendix A Tooling

Tools
Source Code Control
IDE/Editor
Issue Tracking
Continuous Build
Unit Testing Tools
Component Testing Tools
Integration Testing Tools
UML/MDA
Conslusion


## the-pragmatic-programmer.md

      
    Raw
  

              the-pragmatic-programmer.md
            
          
    The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt & David Thomas, 1999


La préface est déjà un bon résumé


A Pragmatic Philosophy


Topic 1. It's Your Life
Topic 2. The Cat Ate My Source Code
Topic 3. Software Entropy
Topic 4. Stone Soup and Boiled Frogs
Topic 5. Good-Enough Software
Topic 6. Your Knowledge Portfolio
Topic 7. Communicate!


A Pragmatic Approach


Topic 8. The Essence of Good Design
Topic 9. DRY—The Evils of DuplicationDRY—The Evils of Duplication
Topic 10. Orthogonality
Topic 11. Reversibility
Topic 12. Tracer Bullets
Topic 13. Prototypes and Post-it Notes
Topic 14. Domain Languages
Topic 15. Estimating


The Basic Tools


Topic 16. The Power of Plain Text
Topic 17. Shell Games
Topic 18. Power Editing
Topic 19. Version Control
Topic 20. Debugging
Topic 21. Text Manipulation
Topic 22. Engineering Daybooks


Pragmatic Paranoia


Topic 23. Design by Contract
Topic 24. Dead Programs Tell No Lies
Topic 25. Assertive Programming
Topic 26. How to Balance Resources
Topic 27. Don't Outrun Your Headlights


Bend, or Break


Topic 28. Decoupling
Topic 29. Juggling the Real World
Topic 30. Transforming Programming
Topic 31. Inheritance Tax
Topic 32. Configuration


Concurrency


Topic 33. Breaking Temporal Coupling
Topic 34. Shared State Is Incorrect State
Topic 35. Actors and Processes
Topic 36. Blackboards


While You Are Coding


Topic 37. Listen to Your Lizard Brain
Topic 38. Programming by Coincidence
Topic 39. Algorithm Speed
Topic 40. Refactoring
Topic 41. Test to Code
Topic 42. Property-Based Testing
Topic 43. Stay Safe Out There
Topic 44. Naming Things


Before the Project


Topic 45. The Requirements Pit
Topic 46. Solving Impossible Puzzles
Topic 47. Working Together
Topic 48. The Essence of Agility


Pragmatic Projects


Topic 49. Pragmatic Teams
Topic 50. Coconuts Don't Cut It
Topic 51. Pragmatic Starter Kit
Topic 52. Delight Your Users
Topic 53. Pride and Prejudice


## the-software-craftsman.md

      
    Raw
  

              the-software-craftsman.md
            
          
    The Software Craftsman: Professionalism, Pragmatism, Pride by Sandro Mancuso, 2014


Chapter 1 Software Development in the Twenty-First Century

Seniority
A New Reality


Chapter 2 Agile

Process-Oriented Agile Disciplines
Technical-Oriented Disciplines
What Is It to Be Agile?

A Game Changer
People Empowerment
Professional Evolution


Agile Manifesto

Principles Behind the Agile Manifesto


The Agile Transformation Era
The Agile Hangover

A Partial Transformation
But It’s Not All Bad News


Agile Versus Software Craftsmanship
Summary


Chapter 3 Software Craftsmanship

A Better Metaphor
What Does Wikipedia Say?
A More Personal Definition
A Shorter Definition
Beyond Definitions
Craft, Trade, Engineering, Science, or Art
Software Craftsmanship History

The Software Craftsmanship Summit
Crossing Borders
Craftsman Swap
Software Craftsmanship Communities
The Software Craftsmanship Manifesto
The Manifesto


Summary


Chapter 4 The Software Craftsmanship Attitude

Who Owns Your Career?

Employer/Employee Relationship


Keeping Ourselves Up to Date

Books, Many Books
Blogs
Technical Websites


Know Who to Follow

Social Media


Practice, Practice, Practice

Katas
Pet Projects
Open Source
Pair Programming


Socialize
Deliberate Discovery
Work-Life Balance

Creating Time
Focus: The Pomodoro Technique
Balance


Summary


Chapter 5 Heroes, Goodwill, and Professionalism

Learning How to Say No

An Epic Failure
Lesson Learned
Being Professional


Providing Options

An Unexpected and Viable Option


Enlightened Managers
Summary


Chapter 6 Working Software

Working Software Is Not Enough
Looking After Our Garden
The Invisible Threat

Hostage of Your Own Software
Hire Craftsmen, Not Average Developers


The Wrong Notion of Time

A Technical Debt Story
A Busy Team with No Time to Spare
The Unit Test Task Card
Using Time Wisely


Legacy Code

A Change in Attitude
Personal and Client Satisfaction


Summary


Chapter 7 Technical Practices

The Right Thing versus the Thing Right
Context
Extreme Programming History
Practices and Values

Adding Value through Practices


Pair Programming
Accountability
Pragmatism
Summary


Chapter 8 The Long Road

A Tale from a Brazilian Teenager
Focus and Determination

But What if We Don’t Know Where We Are Going?


Job as Investment
Autonomy, Mastery, and Purpose
Career Inside Companies
Summary


Chapter 9 Recruitment

An Ordinary Job Description
Too Busy to Interview
No Job Descriptions

What if a Job Description Is Needed?
A Job Is Not Just a Job


Recommendations
Community Involvement
Defining Effective Filtering Criteria
Proactive Recruitment
Summary


Chapter 10 Interviewing Software Craftsmen

A Business Negotiation
Identifying Productive Partnerships

A Hiring Company’s Perspective
A Candidate’s Perspective


Good Interviews

The Right Focus
Mind-Mapping a Conversation
Pair-Programming Interview
Bring Your Own Computer
Tailor-Made Interviews


Taking a Punt
Hiring for an Existing Team versus Hiring for a New Team
Pre-Interview Coding Exercises
Everyone Should Know How to Interview
Developers Must Interview Developers
Summary


Chapter 11 Interview Anti-Patterns

Don’t Be a Smart-Ass Interviewer
Don’t Use Brainteasers
Don’t Ask Questions to Which You Don’t Know the Answers
Don’t Try to Make the Candidate Look Like a Fool
Don’t Block the Internet
Don’t Code on a Piece of Paper
Don’t Use Algorithms
Don’t Conduct Phone Interviews
Summary


Chapter 12 The Cost of Low Morale

The Agile Hangover: Low Morale
The Cost of Employing 9-to-5 Developers
Constrained by Lack of Motivation
Injecting Passion
Summary


Chapter 13 Culture of Learning

Wrong Motivation
Creating a Culture of Learning

Start a Book Club
Have a Tech Lunch (Brown Bag Session)
Have Group Discussions (Roundtables)
Switch Projects for an Iteration
Conduct Group Code Reviews
Have Hands-On Coding Sessions
Start Internal Communities of Practice (CoP)
Encourage Pet-Project Time
Engage with External Technical Communities


What if Others Don’t Want to Join In?

Be an Example
Focus on Those Who Care
Don’t Force
Don’t Try to Change Everyone
Avoid Consensus Delays
Don’t Ask for Authorization
Don’t Complicate
Establish a Rhythm


Summary


Chapter 14 Driving Technical Changes

Identifying Skepticism Patterns
Be Prepared
Where Do We Start?

Establish Trust
Lead by Example
Choose Your Battles
Iterate, Inspect, and Adapt


Fear and Incompetence
How Do I Convince My Manager?
How Do I Convince My Team to Do TDD?
Facing the Skeptics

The Ivory-Tower Architect
The Wronged


Should We Really Care about All That?
Summary


Chapter 15 Pragmatic Craftsmanship

Quality Is Always Expected
Busting the “Expensive and Time-Consuming Quality” Myth

Do We Need to Test-Drive Everything?


Refactoring
The “One Way” of Developing Software
Helping the Business

A Simple and Quick Solution


Software Projects Are Not about Us
Great Versus Mediocre
Four Rules of Simple Design

Design Patterns
Refactoring to Patterns


Craftsmanship and Pragmatism
Summary


Chapter 16 A Career As a Software Craftsman

Being a Craftsman

Honesty and Courage


Career Progression

Different Ladders


Roads and Milestones

Building Our Careers, One Job at a Time
What if We Don’t Know Where We Want to Go?


Job Diversity
The Mission


Appendix Craftsmanship Myths and Further Explanations

Software Craftsman versus Software Developers
Elitism
Apprentice, Journeyman, and Master
Master Craftsman
Narrow Focus
Craftsmanship versus XP
Attachment to Practices
Agile Coaches and Managers
Software Apprenticeships
The Problem with Metaphors