- TDD by its own CANNOT leads to good design, obviously
- TDD as a mechanism to help us to learn more about good design
- Software is "Soft" just because it can be changed, it is not meant to be settled in the stone
- Test-first programming can help the team to reduce defects but it will not lead to good design
- Cohesive
- Loosely coupled
- Encapsulated
- Assertive
- Nonredundant
Good code is CLEAN code
- Passes its tests
- Minimizes duplication
- Maximizes clarity
- Has fewer elements
- It talks to the database
- It communicates across the network
- It touches the file system
- It can't run at the same time as any of your other unit tests
- You have to do special things to your environment (such as editing config files) to run it.
- Red: Write a failing test
- Green: Make the test pass as fast as possible
- Refactor: Take a look at your code
- One codebase tracked in revision control, many deploys
- Explicitly declare and isolate dependencies
- Store config in the environment
- Treat backing services as attached resources
- Strictly separate build and run stages
- Execute the app as one or more stateless processes
- Export services via port binding
- Scale out via the process model
- Maximize robustness with fast startup and graceful shutdown
- Keep development, staging, and production as similar as possible
- Treat logs as event streams
- Run admin/management tasks as one-off processes