• Writing ANY code (features, fixes, utilities)
• Refactoring existing code
• Planning or designing architecture
• Reviewing code quality
• Debugging issues
• Creating tests
• Making design decisions

"Code is to create products for users & customers. Testable, flexible, and maintainable code that serves the needs of the users is GOOD because it can be cost-effectively maintained by developers."

1. RED    - Write a failing test that describes the behavior
2. GREEN  - Write the SIMPLEST code to make it pass
3. REFACTOR - Clean up, remove duplication (Rule of Three)

1. You cannot write production code unless it makes a failing test pass
2. You cannot write more test code than is sufficient to fail
3. You cannot write more production code than is sufficient to pass

1. Consistency - Same concept = same name everywhere
2. Understandability - Domain language, not technical jargon
3. Specificity - Precise, not vague (avoid

   data

   ,

   info

   ,

   manager

   )
4. Brevity - Short but not cryptic
5. Searchability - Unique, greppable names

• One level of indentation per method
• No

  else

  keyword when possible (early returns)
• When validating untrusted strings against an object/map, use

  Object.hasOwn(...)

  (or

  Object.prototype.hasOwnProperty.call(...)

  ) — do not use the

  in

  operator, which matches prototype keys
• ALWAYS wrap primitives in domain objects - IDs, emails, money amounts, etc.
• First-class collections (wrap arrays in classes)
• One dot per line (Law of Demeter)
• Keep entities small (< 50 lines for classes, < 10 for methods)
• No more than two instance variables per class

// ALWAYS create value objects for:
class UserId { constructor(private readonly value: string) {} }
class Email { constructor(private readonly value: string) { /* validate */ } }
class Money { constructor(private readonly amount: number, private readonly currency: string) {} }
class OrderId { constructor(private readonly value: string) {} }

// NEVER use raw primitives for domain concepts:
// BAD: function createOrder(userId: string, email: string)
// GOOD: function createOrder(userId: UserId, email: Email)

1. "What pattern is this?" (Entity, Service, Repository, Factory, etc.)
2. "Is it doing too much?" (Check object calisthenics)

• Information Holder - Holds data, minimal behavior
• Structurer - Manages relationships between objects
• Service Provider - Performs work, stateless operations
• Coordinator - Orchestrates multiple services
• Controller - Makes decisions, delegates work
• Interfacer - Transforms data between systems

• Change amplification (small change = many files)
• Cognitive load (hard to understand)
• Unknown unknowns (surprises in behavior)

• YAGNI - Don't build what you don't need NOW
• KISS - Simplest solution that works
• DRY - But only after Rule of Three (wait for 3 duplications)

• Features as end-to-end slices
• Each feature self-contained

• Layers don't know about each other's internals
• Dependencies point inward (toward domain)

• Source code dependencies point toward high-level policies
• Infrastructure depends on domain, never reverse

1. Runs all the tests - Must work correctly
2. Expresses intent - Readable, reveals purpose
3. No duplication - DRY (but Rule of Three)
4. Minimal - Fewest classes, methods possible

1. Unit Tests - Single class/function, fast, isolated
2. Integration Tests - Multiple components together
3. E2E/Acceptance Tests - Full system, user perspective

// Arrange - Set up test state
const calculator = new Calculator();

// Act - Execute the behavior
const result = calculator.add(2, 3);

// Assert - Verify the outcome
expect(result).toBe(5);

// BAD: 'can add numbers'
// GOOD: 'when adding 2 + 3, returns 5'

• Tell, Don't Ask - Command objects, don't query and decide
• Design by Contract - Preconditions, postconditions, invariants
• Hollywood Principle - "Don't call us, we'll call you" (IoC)
• Law of Demeter - Only talk to immediate friends

1. Do I understand the requirement? (Write acceptance criteria first)
2. What test will I write first?
3. What is the simplest solution?
4. What patterns might apply? (Don't force them)
5. Am I solving a real problem or a hypothetical one?

1. Is this the simplest thing that could work?
2. Does this class have a single responsibility?
3. Am I depending on abstractions or concretions?
4. Can I name this more clearly?
5. Is there duplication I should extract? (Rule of Three)

1. Do all tests pass?
2. Is there any dead code to remove?
3. Can I simplify any complex conditions?
4. Are names still accurate after changes?
5. Would a junior understand this in 6 months?

• Writing code without a test
• Class with more than 2 instance variables
• Method longer than 10 lines
• More than one level of indentation
• Using

  else

  when early return works
• Hardcoding values that should be configurable
• Creating abstractions before the third duplication
• Adding features "just in case"
• Depending on concrete implementations
• God classes that know everything

"A little bit of duplication is 10x better than the wrong abstraction."

"Focus on WHAT needs to happen, not HOW it needs to happen."

"Design principles become second nature through practice. Eventually, you won't think about SOLID - you'll just write SOLID code."