从代码审查到紧密执行：一种反直觉的开发哲学

Fen9Pi2026/8/11大约 9 分钟

前言：代码世界的"减法哲学"

在软件开发中，我们习惯于做加法。

功能越来越多
抽象越来越深
依赖越来越重

结果是：

代码越来越复杂
理解成本越来越高
维护越来越困难

问题不是我们加了多少，而是我们删得不够。

今天介绍一个反直觉的开发哲学：

ponytail-review → codebase-design → tight-execution

先删过度设计（ponytail-review）
再核对 seam（codebase-design）
最后把保留决策交还你（tight-execution）

一、什么是 ponytail-review？

一句话定义

ponytail-review 是一种代码审查哲学：像梳马尾一样，把杂乱的代码梳理清楚，删除所有过度设计。

核心思想

不是"这个抽象有用吗？"，而是"这个抽象真的必要吗？"

马尾梳的隐喻

想象一下梳马尾的过程：

从发根开始 - 找到问题的源头
向下梳理 - 沿着代码逻辑向下
打结就解开 - 遇到复杂抽象就拆解
保持顺直 - 让代码保持简单清晰

三步审查法

步骤 1：识别过度抽象

寻找以下模式：

"未来可能需要"的功能
"为了灵活性"的抽象
"可能扩展"的接口
"重用性"优先的组件

步骤 2：追问必要性

对每个抽象问：

这个抽象解决了当前的问题吗？
如果删除它，代码会变复杂吗？
这个抽象的使用场景是真实存在还是想象出来的？

步骤 3：果断删除

删除"可能有用"的代码
删除"过度灵活"的设计
删除"过早优化"的抽象
保留"真正必要"的复杂性

实践案例

场景：一个简单的用户认证系统

// 过度设计版本
interface AuthStrategy {
  authenticate(credentials: Credentials): Promise<AuthResult>;
}

class JwtAuthStrategy implements AuthStrategy { ... }
class OAuthStrategy implements AuthStrategy { ... }
class SessionAuthStrategy implements AuthStrategy { ... }

class AuthManager {
  private strategies: Map<string, AuthStrategy>;
  
  async authenticate(
    strategyName: string,
    credentials: Credentials
  ): Promise<AuthResult> {
    const strategy = this.strategies.get(strategyName);
    if (!strategy) {
      throw new Error('Strategy not found');
    }
    return strategy.authenticate(credentials);
  }
}

问题：

我们真的需要切换认证策略吗？
这个灵活性是否被使用过？
抽象是否带来了不必要的复杂性？

简化版本：

// 直接实现
async function authenticate(
  credentials: Credentials
): Promise<AuthResult> {
  if (credentials.type === 'jwt') {
    return verifyJwt(credentials.token);
  }
  if (credentials.type === 'oauth') {
    return verifyOAuth(credentials.token);
  }
  throw new Error('Invalid credentials');
}

价值：

代码量减少 60%
理解成本降低 80%
维护难度显著下降

流程图1

二、什么是 codebase-design？

一句话定义

codebase-design 是一种设计哲学：基于现有代码库的设计，核对 seam（接缝），确保设计的连贯性。

核心思想

不是"这个设计是否完美"，而是"这个设计是否与代码库一致"

什么是 Seam（接缝）？

Seam 是系统中可替换的部分边界：

接口（Interface）
抽象类（Abstract Class）
协议（Protocol）
边界（Boundary）

三步核对法

步骤 1：识别现有 Seam

扫描代码库，找到：

现有的抽象层次
现有的命名约定
现有的错误处理模式
现有的测试策略

步骤 2：评估新设计的 Seam

问自己：

这个新接口是否与现有接口一致？
这个新抽象是否与现有抽象对齐？
这个新命名是否与现有命名协调？
这个新错误处理是否与现有错误处理匹配？

步骤 3：调整设计

对齐现有抽象层次
遵循现有命名约定
采用现有错误处理模式
延续现有测试策略

实践案例

场景：添加一个新的数据持久化层

现有代码库模式：

// 现有的 Repository 模式
interface UserRepository {
  find(id: string): Promise<User | null>;
  save(user: User): Promise<void>;
  delete(id: string): Promise<void>;
}

class PostgresUserRepository implements UserRepository { ... }
class MongoUserRepository implements UserRepository { ... }

新设计：产品持久化

// 不一致的设计（Bad）
class ProductManager {
  getProducts(): Promise<Product[]> { ... }
  addProduct(product: Product): Promise<void> { ... }
  removeProduct(id: string): Promise<void> { ... }
}

// 一致的设计（Good）
interface ProductRepository {
  find(id: string): Promise<Product | null>;
  findAll(): Promise<Product[]>;
  save(product: Product): Promise<void>;
  delete(id: string): Promise<void>;
}

class PostgresProductRepository implements ProductRepository { ... }

价值：

保持代码库的一致性
降低学习成本
提高可维护性

流程图2

三、什么是 tight-execution？

一句话定义

tight-execution 是一种执行哲学：把保留的决策权交给使用者，而不是预先决定一切。

核心思想

不是"我帮你决定"，而是"你来做决定"

两种决策模式

Loose Execution（宽松执行）：

预先决定所有细节
提供预设选项
自动化一切

Tight Execution（紧密执行）：

只执行必要的步骤
暂停在关键决策点
等待使用者确认

三步执行法

步骤 1：识别决策点

找到需要使用者决策的地方：

重大架构变更
破坏性修改
数据迁移
安全相关操作

步骤 2：暂停并询问

在决策点暂停，询问：

是否继续？
使用哪个选项？
如何处理边界情况？

步骤 3：执行决策

根据使用者的决策继续执行。

实践案例

场景：数据库迁移工具

Loose Execution（自动决策）：

// 自动迁移，不询问
async function migrate() {
  // 自动备份
  await backup();
  
  // 自动执行迁移
  await executeMigration();
  
  // 自动清理
  await cleanup();
}

问题：

备份可能不需要
迁移可能失败
清理可能过早

Tight Execution（交还决策）：

// 分步执行，让用户决策
async function migrate() {
  console.log('准备迁移数据库');
  console.log('1. 备份现有数据');
  console.log('2. 执行迁移脚本');
  console.log('3. 验证迁移结果');
  console.log('4. 清理旧数据');
  
  const backup = await ask('是否备份现有数据？');
  if (backup) {
    await backupDatabase();
  }
  
  const proceed = await ask('是否执行迁移？');
  if (!proceed) {
    console.log('迁移已取消');
    return;
  }
  
  await executeMigration();
  
  const validated = await ask('迁移是否成功？');
  if (!validated) {
    console.log('迁移失败，请检查日志');
    return;
  }
  
  const cleanup = await ask('是否清理旧数据？');
  if (cleanup) {
    await cleanupOldData();
  }
  
  console.log('迁移完成');
}

价值：

使用者保持控制权
错误可以被及时发现
决策符合实际需求

流程图3

四、三个哲学的统一

从 ponytail-review 到 tight-execution

完整的开发流程：

流程图4

核心原则

1. 删减优先

删除比添加更重要
简单比灵活更有价值
必要性比可能性更关键

2. 连贯性优先

与代码库一致比创新更重要
对齐现有模式比引入新模式更安全
延续现有约定比创造新约定更有价值

3. 控制权优先

使用者的决策比自动化更重要
询问比预设更有价值
灵活比刚性更强大

实战案例：完整的开发流程

场景：重构一个认证模块

Step 1: ponytail-review

// 删除前：过度设计
interface AuthStrategy { ... }
class AuthManager { ... }
class JwtAuthStrategy { ... }
// ... 300 行抽象代码

// 删除后：简化实现
async function authenticate(credentials: Credentials) {
  if (credentials.type === 'jwt') {
    return verifyJwt(credentials.token);
  }
  throw new Error('Invalid credentials');
}
// ... 50 行直接实现

Step 2: codebase-design

// 对齐现有代码库的 Repository 模式
interface AuthRepository {
  findUser(id: string): Promise<User | null>;
  verifyToken(token: string): Promise<boolean>;
}

class PostgresAuthRepository implements AuthRepository {
  async findUser(id: string) {
    // 实现与代码库中其他 Repository 一致
  }
  
  async verifyToken(token: string) {
    // 使用代码库中现有的 JWT 工具
  }
}

Step 3: tight-execution

// 迁移工具：让使用者决策
async function migrateAuth() {
  console.log('准备迁移认证模块');
  
  const backup = await ask('是否备份现有认证数据？');
  if (backup) await backupAuthData();
  
  const migrate = await ask('是否开始迁移？');
  if (!migrate) return;
  
  await runMigration();
  
  const test = await ask('是否测试新认证系统？');
  if (test) await testNewAuth();
  
  const cleanup = await ask('是否清理旧代码？');
  if (cleanup) await cleanupOldAuth();
}