诊断生产力系统反复失效的根因,给出最小干预——容量测算、瓶颈定位、可靠的本地记录。
编程
code-quality-principles
试用Applies KISS, YAGNI, and SOLID principles for clean code with reduced complexity
它能做什么
**Night Market Skill** — ported from claude-night-market/conserve. For the full experience with agents, hooks, and commands, install the Claude Code plugin.
技能文档
Night Market Skill — ported from claude-night-market/conserve. For the full experience with agents, hooks, and commands, install the Claude Code plugin.
Code Quality Principles
Guidance on KISS, YAGNI, and SOLID principles with language-specific examples.
When To Use
- Improving code readability and maintainability
- Applying SOLID, KISS, YAGNI principles during refactoring
When NOT To Use
- Throwaway scripts or one-time data migrations
- Performance-critical code where readability trades are justified
KISS (Keep It Simple, Stupid)
Principle: Avoid unnecessary complexity. Prefer obvious solutions over clever ones.
Guidelines
| Prefer | Avoid |
|---|---|
| Simple conditionals | Complex regex for simple checks |
| Explicit code | Magic numbers/strings |
| Standard patterns | Clever shortcuts |
| Direct solutions | Over-abstracted layers |
Python Example
# Bad: Overly clever one-liner
users = [u for u in (db.get(id) for id in ids) if u and u.active and not u.banned]
# Good: Clear and readable
users = []
for user_id in ids:
user = db.get(user_id)
if user and user.active and not user.banned:
users.append(user)
Rust Example
// Bad: Unnecessary complexity
fn process(data: &[u8]) -> Result, Box> {
data.iter()
.map(|&b| b.checked_add(1).ok_or("overflow"))
.collect::, _>>()
.map_err(|e| e.into())
}
// Good: Simple and clear
fn process(data: &[u8]) -> Result, &'static str> {
let mut result = Vec::with_capacity(data.len());
for &byte in data {
result.push(byte.checked_add(1).ok_or("overflow")?);
}
Ok(result)
}
YAGNI (You Aren't Gonna Need It)
Principle: Don't implement features until they are actually needed.
Guidelines
| Do | Don't |
|---|---|
| Solve current problem | Build for hypothetical futures |
| Add when 3rd use case appears | Create abstractions for 1 use case |
| Delete dead code | Keep "just in case" code |
| Minimal viable solution | Premature optimization |
Python Example
# Bad: Premature abstraction for one use case
class AbstractDataProcessor:
def process(self, data): ...
def validate(self, data): ...
def transform(self, data): ...
class CSVProcessor(AbstractDataProcessor):
def process(self, data):
return self.transform(self.validate(data))
# Good: Simple function until more cases appear
def process_csv(data: list[str]) -> list[dict]:
return [parse_row(row) for row in data if row.strip()]
TypeScript Example
// Bad: Over-engineered config system
interface ConfigProvider {
get(key: K): T[K];
set(key: K, value: T[K]): void;
watch(key: K, callback: (v: T[K]) => void): void;
}
// Good: Simple config for current needs
const config = {
apiUrl: process.env.API_URL || 'http://localhost:3000',
timeout: 5000,
};
SOLID Principles
Single Responsibility Principle
Each module/class should have one reason to change.
# Bad: Multiple responsibilities
class UserManager:
def create_user(self, data): ...
def send_welcome_email(self, user): ... # Email responsibility
def generate_report(self, users): ... # Reporting responsibility
# Good: Separated responsibilities
class UserRepository:
def create(self, data): ...
class EmailService:
def send_welcome(self, user): ...
class UserReportGenerator:
def generate(self, users): ...
Open/Closed Principle
Open for extension, closed for modification.
# Bad: Requires modification for new types
def calculate_area(shape):
if shape.type == "circle":
return 3.14 * shape.radius ** 2
elif shape.type == "rectangle":
return shape.width * shape.height
# Must modify to add new shapes
# Good: Extensible without modification
from abc import ABC, abstractmethod
class Shape(ABC):
@abstractmethod
def area(self) -> float: ...
class Circle(Shape):
def __init__(self, radius: float):
self.radius = radius
def area(self) -> float:
return 3.14 * self.radius ** 2
Liskov Substitution Principle
Subtypes must be substitutable for their base types.
# Bad: Violates LSP - Square changes Rectangle behavior
class Rectangle:
def set_width(self, w): self.width = w
def set_height(self, h): self.height = h
class Square(Rectangle): # Breaks when used as Rectangle
def set_width(self, w):
self.width = self.height = w # Unexpected side effect
# Good: Separate types with common interface
class Shape(ABC):
@abstractmethod
def area(self) -> float: ...
class Rectangle(Shape):
def __init__(self, width: float, height: float): ...
class Square(Shape):
def __init__(self, side: float): ...
Interface Segregation Principle
Clients shouldn't depend on interfaces they don't use.
// Bad: Fat interface
interface Worker {
work(): void;
eat(): void;
sleep(): void;
}
// Good: Segregated interfaces
interface Workable {
work(): void;
}
interface Feedable {
eat(): void;
}
// Clients only implement what they need
class Robot implements Workable {
work(): void { /* ... */ }
}
Dependency Inversion Principle
Depend on abstractions, not concretions.
# Bad: Direct dependency on concrete class
class OrderService:
def __init__(self):
self.db = PostgresDatabase() # Tight coupling
# Good: Depend on abstraction
from abc import ABC, abstractmethod
class Database(ABC):
@abstractmethod
def save(self, data): ...
class OrderService:
def __init__(self, db: Database):
self.db = db # Injected abstraction
Quick Reference
| Principle | Question to Ask | Red Flag |
|---|---|---|
| KISS | "Is there a simpler way?" | Complex solution for simple problem |
| YAGNI | "Do I need this right now?" | Building for hypothetical use cases |
| SRP | "What's the one reason to change?" | Class doing multiple jobs |
| OCP | "Can I extend without modifying?" | Switch statements for types |
| LSP | "Can subtypes replace base types?" | Overridden methods with side effects |
| ISP | "Does client need all methods?" | Empty method implementations |
| DIP | "Am I depending on abstractions?" | new keyword in business logic |
When Principles Conflict
- KISS vs SOLID: For small projects, KISS wins. Add SOLID patterns as complexity grows.
- YAGNI vs DIP: Don't add abstractions until you have 2+ implementations.
- Readability vs DRY: Prefer slight duplication over wrong abstraction.
Integration with Code Review
When reviewing code, check:
- No unnecessary complexity (KISS)
- No speculative features (YAGNI)
- Each class has single responsibility (SRP)
- No god classes (> 500 lines)
- Dependencies are injected, not created (DIP)
Verification: Run wc -l to check line counts and rg -c "class " (or grep -c "class " ) to count classes per file.
Related Skills
imbue:karpathy-principles- The "Simplicity First" principle wraps KISS, YAGNI, and SOLID into a four-principle synthesis derived from Karpathy's observations on LLM coding pitfalls- See
docs/quality-gates.md#skill-level-quality-gate-compositionfor the full gate-skill federation graph
相关技能
在本地磁盘以分类纯 Markdown 文件保存需要长期留存的事实,与智能体内置记忆并存。
把自然语言描述转为结构化 JSON,并由 mcp-diagram-generator MCP 服务生成 Draw.io、Mermaid 或 Excalidraw 图表文件。
以 AI 机器人身份加入视频会议,提供语音、虚拟形象与屏幕共享四种模式。
执行 Git 操作(提交、分支、合并、变基、冲突解决与恢复)时强制套用安全规则。
编写、调试与调优 Playwright 测试,涵盖定位器策略、追踪诊断与 CI 友好的超时配置。
athola 的更多技能
浏览全部技能Evaluate hook security, performance, and SDK compliance. Use for audits
Configures pre-commit hooks for linting, type checking, formatting, and testing
Executes implementation plans with progress tracking, checkpoint validation, and quality gates. Use after planning is complete and tasks are ready to implement
Guide creating Claude Code hooks with security-first design. Use for validation and enforcement
Analyze and improve the improvement process. Use for detecting regressions and meta-optimization
Selects and routes to the right architecture paradigm