一个函数超过20行? 聊聊我的函数式代码洁癖

大家好,我又来了😁

我得承认，我有个毛病，或者说洁癖吧。

在Code Review的时候，当我点开一个*.js / *.ts文件，看到一个函数洋洋洒洒地写了50行、80行，甚至更多时，我的第一反应不是去读它的逻辑，而是生理性地发慌😖。

我会下意识地在评论区留下一句：这个函数是不是太长了？能不能拆一下？

20行这个数字，是我给自己设的一个 代码量阈值。它不绝对，但足够灵敏。

我知道，很多人会觉得我这是小题大做、形式主义。但今天我想聊聊，这个洁癖背后，隐藏的是一个被函数式思想洗礼过的、关于代码可维护性、可测试性和认知成本的严肃思考。

为什么长函数让人如此发慌？😒

一个超过20行的函数，对我来说，通常意味着三场灾难：

1. 阅读成本极高

javascript 复制代码

// 这是一个超过 50 行的函数
// 目的：根据用户数据生成报告并发送邮件（其实做了三件事）
function handleUserReport(users, sendEmail, isAdmin) {
  let result = [];
  let flag = false;

  console.log("开始处理用户数据...");

  for (let i = 0; i < users.length; i++) {
    let u = users[i];
    if (u.age > 18) {
      if (u.active) {
        if (u.score > 80) {
          result.push({ name: u.name, status: "优秀" });
          flag = true;
        } else if (u.score > 60) {
          result.push({ name: u.name, status: "良好" });
        } else {
          result.push({ name: u.name, status: "待提升" });
        }
      } else {
        if (isAdmin) {
          result.push({ name: u.name, status: "非活跃但保留" });
        } else {
          result.push({ name: u.name, status: "非活跃" });
        }
      }
    } else {
      if (u.active) {
        result.push({ name: u.name, status: "未成年用户" });
      }
    }
  }

  console.log("用户数据处理完毕");
  console.log("生成报告中...");

  let report = "用户报告：\n";
  for (let i = 0; i < result.length; i++) {
    report += `${result[i].name} - ${result[i].status}\n`;
  }

  if (flag) {
    console.log("存在优秀用户！");
  }

  if (sendEmail) {
    console.log("准备发送邮件...");
    // 模拟邮件发送逻辑
    for (let i = 0; i < result.length; i++) {
      if (result[i].status === "优秀") {
        console.log(`已发送邮件给：${result[i].name}`);
      }
    }
  }

  console.log("处理完成。");
  return report;
}

上面👆这个50多行的函数，就像一篇没有分段的短文。你必须从头到尾把它加载到你的大脑里，才能理解它到底在干嘛。

第5行定义的一个flag变量，在第15行被修改了。
中间夹杂着三层if/else嵌套。
它到底做了几件事？天知道🤷‍♂️。

这种函数，是可写，不可读的。写的人洋洋得意，几个月后他自己回来维护，一样骂娘😠。

2. 根本无法单元测试

我们来谈谈单元测试。你怎么去测试一个50行的、混合了数据请求、数据格式化和UI状态更新的函数？

先看代码👇：

javascript 复制代码

// 一个50行的混合函数：既请求接口、又格式化数据、还更新UI状态
async function loadUserProfile(userId) {
  setLoading(true);

  try {
    // 1️⃣ 请求数据
    const response = await fetch(`/api/user/${userId}`);
    const data = await response.json();

    // 2️⃣ 本地缓存
    localStorage.setItem('lastUserId', userId);

    // 3️⃣ 格式化数据
    const displayName = data.firstName + ' ' + data.lastName;
    const ageText = data.age ? `${data.age}岁` : '未知年龄';

    // 4️⃣ UI状态更新
    setUser({
      name: displayName,
      age: ageText,
      hobbies: data.hobbies?.join('、') || '无'
    });

    // 5️⃣ 额外副作用
    if (data.isVIP) {
      trackEvent('vip_user_loaded');
      showVIPBadge();
    }

    setLoading(false);
  } catch (error) {
    console.error('加载失败', error);
    setError('加载用户信息失败');
    setLoading(false);
  }
}

测试代码：

javascript 复制代码

// 测试代码（伪代码）
test('loadUserProfile should set formatted user data', async () => {
  // Mock 一堆外部依赖
  global.fetch = jest.fn().mockResolvedValue({
    json: () => Promise.resolve({ firstName: 'Tom', lastName: 'Lee', age: 28, isVIP: true })
  });
  localStorage.setItem = jest.fn();
  const setUser = jest.fn();
  const setLoading = jest.fn();
  const setError = jest.fn();
  const trackEvent = jest.fn();
  const showVIPBadge = jest.fn();

  // 还要通过依赖注入或hook替换上下文...
  await loadUserProfile(123);

  // 然后验证每一步是否被正确调用
  expect(fetch).toHaveBeenCalledWith('/api/user/123');
  expect(localStorage.setItem).toHaveBeenCalledWith('lastUserId', 123);
  expect(setUser).toHaveBeenCalledWith({
    name: 'Tom Lee',
    age: '28岁',
    hobbies: '无'
  });
  expect(trackEvent).toHaveBeenCalledWith('vip_user_loaded');
  expect(showVIPBadge).toHaveBeenCalled();
  expect(setLoading).toHaveBeenLastCalledWith(false);
});

你根本没法测试。你只能去集成测试。

为了测试它，你不得不mock掉fetch、localStorage、useState... 你会发现，你的测试代码，比你的业务代码还长、还复杂。

3. 你看不见的地雷

函数越长，它顺手去干点脏活的概率就越大。

举个例子👇：

js 复制代码

// 名字看起来挺纯洁的 ------ 获取用户配置
// 实际上它干了很多事没人知道...
function getUserConfig(userId) {
  console.log('开始获取用户配置...');

  // 1️⃣ 顺手改了全局变量
  globalCache.lastRequestTime = Date.now();

  try {
    // 2️⃣ 发起网络请求
    const res = fetch(`/api/config/${userId}`);
    const data = res.json();

    // 3️⃣ 顺手改了一下全局设置
    window.__APP_MODE__ = data.isAdmin ? 'admin' : 'user';

    // 4️⃣ 顺手写了一点 localStorage
    localStorage.setItem('lastConfigUser', userId);

    // 5️⃣ 格式化返回数据
    const config = {
      theme: data.theme || 'light',
      lang: data.lang || 'en-US'
    };

    return config;
  } catch (err) {
    console.error('获取配置出错', err);

    // 6️⃣ 顺手派发了一个事件
    window.dispatchEvent(new CustomEvent('config_load_failed', { detail: { userId } }));

    // 7️⃣ 顺手清空了一个全局标记
    globalCache.lastRequestTime = null;

    return { theme: 'light', lang: 'en-US' }; // 假装有个默认值
  }
}

调用者根本不知道它干了些什么 😵‍💫

js 复制代码

const config = getUserConfig(42);
console.log(config.theme); // 看起来很正常

// 但此时：
// window.__APP_MODE__ 已被改动
// localStorage 里写入了 lastConfigUser
// globalCache.lastRequestTime 已变化
// 如果请求失败，还会触发一个全局事件

它在函数的中间，顺手改了一个全局变量。
它在catch块里，顺手dispatch了一个event。
它顺手往window上挂了个东西。

这种充满隐形副作用的函数，是系统中最不可预测的地雷。你根本不知道你调用它，会影响到哪里。

谈一谈函数式思想

我的洁癖，其实是来源于函数式编程思想。

我并不追求写出高阶组合子那些高深的东西。我只坚守两个最朴素的原则：

函数必须小，且只做一件事

这是 单一职责原则 的终极体现。一个函数，就只做一件事。

getUserData就只负责fetch。
formatUserData就只负责格式化。
setUserState就只负责更新状态。

一个函数超过20行，对我来说，往往就是它至少做了两件以上的事情的强烈信号。

追求纯函数，隔离掉它的一切副作用

一个纯函数：给它什么（入参），它就吐出什么（返回），绝不搞小动作。

我追求的目标，就是把所有的业务逻辑和计算，都抽成纯函数。而那些不得不做的脏活（比如API请求、DOM操作），则被我隔离在最外层的协调函数里。

重构一个函数

我们来看一个在React项目里，极其常见的函数（绝对超过20行）：

javascript 复制代码

// 场景：一个提交用户注册的函数
async function handleRegister(formData) {
  setLoading(true);
  
  // 1. 业务逻辑：验证
  if (!formData.username) {
    showToast('用户名不能为空');
    setLoading(false);
    return;
  }
  if (formData.password.length < 6) {
    showToast('密码不能少于6位');
    setLoading(false);
    return;
  }
  
  // 2. 业务逻辑：数据转换
  const apiPayload = {
    user: formData.username,
    pass: btoa(formData.password + 'my_salt'), // 假设的加密
    source: 'web',
    registerTime: new Date().toISOString(),
  };

  // 3. 副作用：API请求
  try {
    const result = await api.post('/register', apiPayload);
    
    // 4. 副作用：更新UI状态
    if (result.code === 200) {
      setUserData(result.data.user);
      trackEvent('register_success');
      showToast('注册成功！');
      router.push('/dashboard');
    } else {
      showToast(result.message);
    }
  } catch (err) {
    showToast(err.message);
    trackEvent('register_fail', { msg: err.message });
  } finally {
    setLoading(false);
  }
}

这个函数，就是一场灾难。它混合了4-5种职责，你根本没法测试它。

重构过程如下👇：

1.先分离纯业务逻辑（可测试）

js 复制代码

// 纯函数1：验证逻辑 (可独立测试)
// (5行)
export function validateRegistration(formData) {
  if (!formData.username) return '用户名不能为空';
  if (formData.password.length < 6) return '密码不能少于6位';
  return null; // 验证通过
}

// 纯函数2：数据转换 (可独立测试)
// (7行)
export function createRegisterPayload(formData) {
  return {
    user: formData.username,
    pass: btoa(formData.password + 'my_salt'),
    source: 'web',
    registerTime: new Date().toISOString(),
  };
}

2.再分离它的副作用

js 复制代码

// 副作用函数1：API调用
// (3行)
export async function postRegistration(payload) {
  return api.post('/register', payload);
}

// 副作用函数2：处理成功后的UI逻辑
// (6行)
function handleRegisterSuccess(userData) {
  setUserData(userData);
  trackEvent('register_success');
  showToast('注册成功！');
  router.push('/dashboard');
}

// 副作用函数3：处理失败后的UI逻辑
// (3行)
function handleRegisterFail(error) {
  showToast(error.message);
  trackEvent('register_fail', { msg: error.message });
}

3.最后重组函数

现在，我们原来的handleRegister函数，变成了一个清晰的调用者：

js 复制代码

// (18行)
async function handleRegister(formData) {
  // 1. 验证
  const validationError = validateRegistration(formData);
  if (validationError) {
    showToast(validationError);
    return;
  }
  
  setLoading(true);
  try {
    // 2. 转换
    const payload = createRegisterPayload(formData);
    // 3. 执行
    const result = await postRegistration(payload);
    // 4. 响应
    if (result.code === 200) {
      handleRegisterSuccess(result.data.user);
    } else {
      handleRegisterFail(new Error(result.message));
    }
  } catch (err) {
    handleRegisterFail(err);
  } finally {
    setLoading(false);
  }
}

等等！你这个handleRegister函数，不还是快20行了吗？😂

是的，但你发现区别了吗？这个函数，几乎没有任何逻辑 ，它只负责调用其他小函数。它像一个流程图，清晰得一目了然。

而所有的业务逻辑（validate和createPayload），都被我拆分到了可独立测试、可复用、可预测的纯函数里。这，就是这次的重构的价值。

20行代码的标准不是一个KPI，它是一个预警。

它在提醒我们，这个函数的负载可能已经超标了，它在 单一职责 的路上可能已经走偏了。

这种洁癖，不是为了追求代码的短小，而是为了追求代码的简单和可预测。

在一个由几十万行代码构成的、需要长期维护的系统里，简单和可预测，是比炫技（屎代码💩），要宝贵一百倍😁。

一个函数超过20行? 聊聊我的函数式代码洁癖

为什么长函数让人如此发慌？😒

谈一谈 函数式思想

重构一个函数

谈一谈函数式思想