engineering-standards

name	engineering-standards
description	Core software engineering principles (SOLID, DRY, YAGNI, KISS) with detection patterns and refactoring guidance. Load when reviewing code quality, planning architecture, or identifying technical debt.

Engineering Standards

Foundational principles for high-quality software. Use this skill when:

• Reviewing code for quality issues
• Planning architectural changes
• Identifying refactoring opportunities
• Evaluating technical debt

SOLID Principles

Single Responsibility (SRP)

A class/module should have one reason to change.

Detection patterns:

• Class with 5+ public methods doing unrelated things
• Method longer than 50 lines
• Class name contains "And" or "Manager" with mixed concerns
• File imports from 10+ unrelated modules

Refactoring:

• Extract class for each responsibility
• Split into focused modules
• Use composition over inheritance

Open/Closed (OCP)

Open for extension, closed for modification.

Detection patterns:

• Switch/case on type with frequent additions
• if/else chains checking instance types
• Modifying existing code to add new features

Refactoring:

• Strategy pattern for varying behaviors
• Plugin architecture for extensions
• Dependency injection for configurability

Liskov Substitution (LSP)

Subtypes must be substitutable for their base types.

Detection patterns:

• Override that throws "not implemented"
• Subclass that ignores parent behavior
• Type checks before calling inherited methods

Refactoring:

• Favor composition over inheritance
• Extract interface for true polymorphism
• Use abstract base with required overrides

Interface Segregation (ISP)

Clients shouldn't depend on methods they don't use.

Detection patterns:

• Interface with 10+ methods
• Implementing classes that stub methods as no-ops
• "Fat" interfaces with unrelated method groups

Refactoring:

• Split into role-specific interfaces
• Use mixins/traits for optional behaviors
• Compose multiple focused interfaces

Dependency Inversion (DIP)

Depend on abstractions, not concretions.

Detection patterns:

• Direct instantiation of dependencies (new ConcreteClass())
• Hard-coded database/API connections
• Test files creating production instances

Refactoring:

• Constructor injection
• Factory pattern for complex creation
• Interface-based dependencies

---

DRY (Don't Repeat Yourself)

Detection patterns:

• Copy-pasted code blocks (3+ occurrences)
• Similar functions with minor variations
• Duplicated validation logic
• Repeated configuration values

Refactoring:

• Extract shared function/class
• Parameterize variations
• Create configuration constants
• Use template method pattern

Exceptions (acceptable duplication):

• Test code clarity (explicit over DRY)
• Cross-boundary isolation (microservices)
• Performance-critical paths

---

YAGNI (You Aren't Gonna Need It)

Detection patterns:

• Unused parameters "for future use"
• Abstract classes with single implementation
• Configuration options never used
• Speculative generalization

Guidance:

• Build for current requirements
• Refactor when needs emerge
• Delete dead code immediately
• Prefer simple over flexible

---

KISS (Keep It Simple, Stupid)

Detection patterns:

• Cyclomatic complexity > 10
• Nested callbacks/promises 4+ deep
• Generic solutions for specific problems
• Framework overkill for simple tasks

Refactoring:

• Flatten control flow
• Extract named functions
• Use early returns
• Choose boring technology

---

Code Smells Quick Reference

Smell	Symptom	Fix
Long Method	>50 lines, multiple concerns	Extract method
Large Class	>500 lines, many responsibilities	Extract class
Feature Envy	Method uses other class more than own	Move method
Data Clumps	Same fields appear together	Extract object
Primitive Obsession	Strings/ints for domain concepts	Value objects
Switch Statements	Type-based switching	Polymorphism
Parallel Inheritance	Every subclass needs partner subclass	Merge hierarchies
Lazy Class	Class doing too little	Inline class
Speculative Generality	Unused abstraction	Remove it
Temporary Field	Field only set sometimes	Extract class

---

When to Apply

Always apply:

• SRP, DRY for production code
• KISS for all code

Apply with judgment:

• OCP when extension points are clear
• ISP when interfaces grow beyond 5 methods
• DIP at module boundaries

Defer:

• YAGNI violations until pattern emerges 3+ times

See references/refactoring-catalog.md for detailed refactoring techniques.