Contents

Preface

0.1 Who Should Read This Book

0.1.1 Prerequisites

0.1.2 A note for software architects

0.2 Organisation

0.2.1 About the code style

0.2.2 To var or not to var

0.2.3 Code listings

0.3 A note on the bibliography

0.3.1 Quoting myself

0.4 Acknowledgements

I Acceleration

1 Art or Science?

1.1 Building a house

1.1.1 The problem with projects

1.1.2 The problem with phases

1.1.3 Dependencies

1.2 Growing a garden

1.2.1 What Makes a Garden Grow?

1.3 Towards engineering

1.3.1 Software as a craft

1.3.2 Heuristics

1.3.3 Earlier notions of software engineering

1.3.4 Moving forward with software engineering

1.4 Conclusion

2 Checklists

2.1 An aid to memory

2.2 Checklist for a new code base

2.2.1 Use Git

2.2.2 Automate the build

2.2.3 Turn on all error messages

2.3 Adding checks to existing code bases

2.3.1 Gradual improvement

2.3.2 Hack your organisation

2.4 Conclusion

3 Tackling Complexity

3.1 Purpose

3.1.1 Sustainability

3.1.2 Value

3.2 Why programming is difficult

3.2.1 The brain metaphor

3.2.2 Code is read more than it’s written

3.2.3 Readability

3.2.4 Intellectual work

3.3 Towards software engineering

3.3.1 Relationship to computer science

3.3.2 Humane code

3.4 Conclusion

4 Vertical Slice

4.1 Start with working software

4.1.1 From data ingress to data persistence

4.1.2 Minimal vertical slice

4.2 Walking Skeleton

4.2.1 Characterisation Test

4.2.2 Arrange Act Assert

4.2.3 Moderation of static analysis

4.3 Outside-in

4.3.1 Receive JSON

4.3.2 Post a reservation

4.3.3 Unit test

4.3.4 DTO and Domain Model

4.3.5 Fake Object

4.3.6 Repository Interface

4.3.7 Create in Repository

4.3.8 Configure dependencies

4.4 Complete the slice

4.4.1 Schema

4.4.2 SQL Repository

4.4.3 Configuration with database

4.4.4 Perform a Smoke Test

4.4.5 Boundary test with Fake database

4.5 Conclusion

5 Encapsulation

5.1 Save the data

5.1.1 The Transformation Priority Premise

5.1.2 Parametrised Test

5.1.3 Copy DTO to Domain Model

5.2 Validation

5.2.1 Bad dates

5.2.2 Red Green Refactor

5.2.3 Natural numbers

5.2.4 Postel’s law

5.3 Protection of invariants

5.3.1 Always valid

5.4 Conclusion

6 Triangulation

6.1 Short-term versus long-term memory

6.1.1 Legacy code and memory

6.2 Capacity

6.2.1 Overbooking

6.2.2 The Devil’s Advocate

6.2.3 Existing reservations

6.2.4 Devil’s Advocate versus Red Green Refactor

6.2.5 When do you have enough tests?

6.3 Conclusion

7 Decomposition

7.1 Code rot

7.1.1 Thresholds

7.1.2 Cyclomatic complexity

7.1.3 The 80/24 rule

7.2 Code that fits in your brain

7.2.1 Hex flower

7.2.2 Cohesion

7.2.3 Feature Envy

7.2.4 Lost in translation

7.2.5 Parse, don’t validate

7.2.6 Fractal architecture

7.2.7 Count the variables

7.3 Conclusion

8 API design

8.1 Principles of API design

8.1.1 Affordance

8.1.2 Poka-yoke

8.1.3 Write for readers

8.1.4 Favour well-named code over comments

8.1.5 X out names

8.1.6 Command Query Separation

8.1.7 Hierarchy of communication

8.2 API design example

8.2.1 Maître d’

8.2.2 Interacting with an encapsulated object

8.2.3 Implementation details

8.3 Conclusion

9 Teamwork

9.1 Git

9.1.1 Commit messages

9.1.2 Continuous Integration

9.1.3 Small commits

9.2 Collective code ownership

9.2.1 Pair programming

9.2.2 Mob programming

9.2.3 Code review latency

9.2.4 Rejecting a change set

9.2.5 Code reviews

9.2.6 Pull requests

9.3 Conclusion

II. Sustainability

10 Augmenting Code

10.1 Feature flags

10.1.1 Calendar flag

10.2 The Strangler Pattern

10.2.1 Method-level Strangler

10.2.2 Class-level Strangler

10.3 Versioning

10.3.1 Advance warning

10.4 Conclusion

11 Editing Unit Tests

11.1 Refactoring unit tests

11.1.1 Changing the safety net

11.1.2 Adding new test code

11.1.3 Separate refactoring of test and production code

11.2 See tests fail

11.3 Conclusion

12 Troubleshooting

12.1 Understanding

12.1.1 Scientific method

12.1.2 Simplify

12.1.3 Rubber ducking

12.2 Defects

12.2.1 Reproduce defects as tests

12.2.2 Slow tests

12.2.3 Non-deterministic defects

12.3 Bisection

12.3.1 Bisection with Git

12.4 Conclusion

13 Separation of Concerns

13.1 Composition

13.1.1 Nested composition

13.1.2 Sequential composition

13.1.3 Referential transparency

13.2 Cross-cutting concerns

13.2.1 Logging

13.2.2 Decorator

13.2.3 What to log

13.3 Conclusion

14 Rhythm

14.1 Personal rhythm

14.1.1 Time-boxing

14.1.2 Take breaks

14.1.3 Use time deliberately

14.1.4 Touch type

14.2 Team rhythm

14.2.1 Regularly update dependencies

14.2.2 Schedule other things

14.2.3 Conway’s law

14.3 Conclusion

15 The usual suspects

15.1 Performance

15.1.1 Legacy

15.1.2 Legibility

15.2 Security

15.2.1 STRIDE

15.2.2 Spoofing

15.2.3 Tampering

15.2.4 Repudiation

15.2.5 Information disclosure

15.2.6 Denial of service

15.2.7 Elevation of privilege

15.3 Other techniques

15.3.1 Property-based testing

15.3.2 Behavioural code analysis

15.4 Conclusion

16 Tour

16.1 Navigation

16.1.1 Seeing the big picture

16.1.2 File organisation

16.1.3 Finding details

16.2 Architecture

16.2.1 Monolith

16.2.2 Cycles

16.3 Usage

16.3.1 Learning from tests

16.3.2 Listen to your tests

16.4 Conclusion

A List of practices

A.1 The 50/72 rule

A.2 The 80/24 rule

A.3 Arrange Act Assert

A.4 Bisection

A.5 Checklist for a new code base

A.6 Command Query Separation

A.7 Count the variables

A.8 Cyclomatic complexity

A.9 Decorators for cross-cutting concerns

A.10 Devil’s Advocate

A.11 Feature flag

A.12 Functional core, imperative shell

A.13 Hierarchy of communication

A.14 Justify exceptions from the rule

A.15 Parse, don’t validate

A.16 Postel’s law

A.17 Red Green Refactor

A.18 Regularly update dependencies

A.19 Reproduce defects as tests

A.20 Review code

A.21 Semantic Versioning

A.22 Separate refactoring of test and production code

A.23 Slice

A.24 Strangler

A.25 Threat-model

A.26 Transformation Priority Premise

A.27 X-driven development

A.28 X out names

Bibliography