软件工程核心设计原则：构建可维护代码的基石

随着项目规模增长，问题往往不是「不会写代码」，而是代码越来越难改、一个改动牵连多处、新人不知道规则在哪里。这些问题几乎都源自缺乏清晰一致的设计原则。本文深入探讨五大核心原则——SSOT、DRY、KISS、YAGNI、SRP——它们是构建可维护软件的永恒基石。

1. 原则全景

原则	核心关注	解决的问题
SSOT	唯一权威来源	避免逻辑不一致
DRY	避免重复实现	减少重复代码
KISS	保持简单	防止过度设计
YAGNI	不提前实现	避免无用复杂度
SRP	单一职责	降低修改成本

2. SSOT：Single Source of Truth

核心思想

某个事实，只能有一个权威来源。

SSOT 关注的是数据一致性和规则归属，确保系统中每个「真相」只有一个定义位置。

典型场景

用户权限由后端决定，前端只做展示
状态枚举由 schema 定义，而非散落在代码里
配置项集中管理，而非硬编码

反例：

// 前端硬编码角色列表
const roles = ["admin", "user", "guest"];

// 后端也定义了一份
enum Role {
  ADMIN,
  USER,
  GUEST,
}

正例：

// 后端 API 返回角色列表，前端直接使用
const roles = await fetchRoles();

3. DRY：Don’t Repeat Yourself

核心思想

相同的知识，只写一次。

DRY 关注的是代码结构和逻辑复用，目标是消除复制粘贴。

典型场景

多处相同的 if/else 判断
重复的计算逻辑
散落各处的校验规则

反例：

// 权限检查散落在多处
if (user.role === "admin") {
  /* ... */
}
// 另一个文件
if (currentUser.role === "admin") {
  /* ... */
}

正例：

// 抽取为工具函数
function isAdmin(user: User): boolean {
  return user.role === "admin";
}

SSOT vs DRY

维度	SSOT	DRY
关注点	事实来源	实现方式
解决问题	多版本真相	重复代码
作用层级	架构/数据层	代码层

4. KISS：Keep It Simple, Stupid

核心思想

能简单解决，就不要复杂化。

KISS 原则由工程师 Kelly Johnson 提出，强调简单性优先。

反模式信号

当你看到这样的命名时，可能想多了：

AbstractFactoryStrategyManagerProviderFactory;

实践要点

偏爱直接的设计
避免过早抽象
代码要让半年后的自己一眼看懂

反例：

// 过度设计：为简单配置引入复杂模式
class ConfigurationStrategyFactory {
  createStrategy(type: string): ConfigStrategy {
    /* ... */
  }
}

正例：

// 简单直接
const config = {
  apiUrl: process.env.API_URL,
  timeout: 5000,
};

5. YAGNI：You Aren’t Gonna Need It

核心思想

现在不需要的功能，不要提前实现。

典型误区

“以后可能要支持多租户”
“先写好插件化架构，免得以后改”
“加个配置项，万一以后要改呢”

结果往往是：代码复杂度暴涨，真正需求来了反而原设计不合适。

反例：

// 过早优化：项目只有单一数据源
class MultiDatabaseConnectionPool {
  private pools: Map<string, ConnectionPool>;
  // 复杂的多数据库管理逻辑...
}

正例：

// 满足当前需求即可
const db = new Database(process.env.DATABASE_URL);

6. SRP：Single Responsibility Principle

核心思想

一个模块/类，只对一个变化原因负责。

判断标准

如果描述一个模块的功能需要用「和」连接多件事，它可能违反了 SRP。

反例：

class UserService {
  login(credentials: Credentials) {
    /* ... */
  }
  validatePassword(password: string) {
    /* ... */
  }
  sendWelcomeEmail(user: User) {
    /* ... */
  }
  generateReport(user: User) {
    /* ... */
  }
}

正例：

class AuthService {
  login(credentials: Credentials) {
    /* ... */
  }
  validatePassword(password: string) {
    /* ... */
  }
}

class NotificationService {
  sendWelcomeEmail(user: User) {
    /* ... */
  }
}

class ReportService {
  generateUserReport(user: User) {
    /* ... */
  }
}

7. 原则之间的关系

这些原则并非孤立存在，它们形成一个层次化的约束体系：

┌─────────────────────┐
│        SRP          │  ← 定义职责边界
└──────────┬──────────┘
           ↓
┌─────────────────────┐
│        DRY          │  ← 在边界内复用
└──────────┬──────────┘
           ↓
┌─────────────────────┐
│       SSOT          │  ← 确定谁说了算
└──────────┬──────────┘
           ↓
┌─────────────────────┐
│    KISS + YAGNI     │  ← 约束整体复杂度
└─────────────────────┘

SRP 定边界 → DRY 促复用 → SSOT 定权威 → KISS/YAGNI 控复杂度

8. 工程实践清单

将这些原则转化为日常检查项：

一个规则只有一个定义位置（SSOT）
不复制规则，用引用（DRY）
不为假设的未来写代码（YAGNI）
代码让半年后的自己一眼看懂（KISS）
一个模块只负责一件事（SRP）

9. 延伸阅读

Clean Code – Robert C. Martin
The Pragmatic Programmer – David Thomas & Andrew Hunt
Refactoring – Martin Fowler
SOLID Principles

这些原则不是教条，而是经过数十年验证的工程智慧。掌握它们的精神，比死记规则更重要。