keep-it-simple

KISS（保持简单，笨蛋）

概述

能奏效的最简单方案就是最佳方案。

耍小聪明的代码不会让人印象深刻。简单的代码交付更快、故障更少，也更容易维护。

适用场景

• 解决方案感觉很复杂
• 编写“优雅”或耍小聪明的代码
• 存在多种实现方式
• 想要炫耀自己的技能
• 用高级模式解决简单问题

铁律

NEVER choose clever over clear. Simple wins.

没有例外：

• 不能因为“这样更优雅”
• 不能因为“这样能展现高级技能”
• 不能因为“技术上更好”
• 不能因为“这是个不错的单行代码”

识别信号：“耍小聪明”的气味

如果你为代码有多巧妙而自豪，就把它简化：

// ❌ VIOLATION: Clever one-liner
const isPalindrome = (s: string): boolean =>
  (s = s.toLowerCase().replace(/[^a-z0-9]/g, '')) === [...s].reverse().join('');

// ✅ CORRECT: Simple and clear
function isPalindrome(str: string): boolean {
  const cleaned = str.toLowerCase().replace(/[^a-z0-9]/g, '');
  
  for (let i = 0; i < cleaned.length / 2; i++) {
    if (cleaned[i] !== cleaned[cleaned.length - 1 - i]) {
      return false;
    }
  }
  
  return true;
}

复杂性的代价

复杂代码	影响
耍小聪明的单行代码	难以阅读、难以调试
嵌套三元表达式	逻辑变得晦涩
过度抽象	间接层掩盖意图
过早优化	复杂性增加，却没有经过衡量的收益
过度使用设计模式	为模式而使用模式

正确模式：一目了然的代码

编写让初级开发者能在 30 秒内看懂的代码：

// ❌ COMPLEX: "Elegant" functional chain
const result = data
  .filter(Boolean)
  .map(x => transform(x))
  .reduce((acc, x) => ({ ...acc, [x.id]: x }), {})
  .values()
  .filter(x => x.active)
  .sort((a, b) => b.date - a.date)
  .slice(0, 10);

// ✅ SIMPLE: Clear steps with names
const validItems = data.filter(Boolean);
const transformed = validItems.map(transform);
const activeItems = transformed.filter(item => item.active);
const sorted = activeItems.sort((a, b) => b.date - a.date);
const topTen = sorted.slice(0, 10);

抵御压力的规程

1. “这样更优雅”

压力：“这个单行版本比冗长的版本更优雅。”

**回应：**优雅在于清晰，而非简短。简单的代码比耍小聪明的代码更优雅。

**行动：**使用清晰的版本。为中间变量命名。

2. “这样能展现高级技能”

压力：“我想展示自己懂高级模式。”

**回应：**高级工程师因简单的解决方案而受认可，而非复杂的方案。

**行动：**简单地解决问题。把巧思留给真正需要的地方。

3. “技术上更好”

压力：“复杂版本的复杂度是 O(n)，而不是 O(n log n)。”

**回应：**这是过早优化。它真的是瓶颈吗？

**行动：**编写简单的代码。只有分析结果表明确有需要时才优化。

4. “让我展示多种方案”

压力：“我会提供两种实现方式，展示自己的应变能力。”

**回应：**一个清晰的解决方案胜过多个选项。

**行动：**选择最简单的方法。只提供这一种。

危险信号——立即停下并重新考虑

如果你发现以下任何一种情况，就简化代码：

• 代码需要注释来解释
• 嵌套三元表达式 ? : ? :
• 多个操作串联（5 个以上）
• 需要解读的正则表达式
• 为代码有多巧妙而自豪
• “单行”实现
• 初级开发者无法在 30 秒内看懂
• 为了“展示应变能力”而提供多个方案

以上情况都意味着：重写得简单些。

简化技巧

复杂写法	简单写法
嵌套三元表达式	if/else 语句
长操作链	有名称的中间变量
巧妙的正则表达式	多个简单检查
单行代码	带注释的多行代码
隐式	显式
魔法数字	有名称的常量

快速参考

症状	行动
“优雅”的单行代码	展开成清晰的多行代码
嵌套三元表达式	改为 if/else
复杂操作链	拆分成有名称的步骤
多种方案	选择最简单的一种
为巧思自豪	简单地重写

常见的自我辩解（均不成立）

借口	事实
“这样更优雅”	清晰的代码比耍小聪明的代码更优雅。
“能展现高级技能”	简单的解决方案更能体现技能。
“这是个不错的单行代码”	单行代码往往难以阅读。
“技术上更好”	过早优化是坏事。
“多个选项能展示应变能力”	一个清晰的解决方案更好。
“专家就是这么做的”	专家编写简单的代码。

归根结底

简单胜过巧妙。清晰胜过简短。一目了然胜过优雅。

解决问题时，找到能奏效的最简单方案。如果初级开发者无法在 30 秒内看懂，就把它简化。