判断一个任务该不该放进函数，核心就两条：边界清晰到一句话说清“它做什么”，执行过程短到不用翻页就能看完，满足这两点的任务，抽成函数几乎不会错。
函数什么时候需要封装？先给任务画两条线
写代码时总会遇到一段逻辑，看起来能独立成块，但又不确定值不值得单独拎出来，这时候不用纠结“函数什么时候需要封装”这个抽象问题,直接拿两个标准去套。
边界清晰，指的是这段代码有明确的输入、输出和单一职责，比如手机号脱敏、金额格式化、日期转时间戳，都属于边界清晰的任务，输入什么、返回什么、不碰哪些数据,基本一眼能看出来。
短时完成，指的是执行步骤在个位数以内，函数体多数情况下不超过20行，逻辑分支不超过3层，这类任务通常以毫秒级完成，不会涉及复杂的事务、长循环或多个外部依赖。
反过来，如果一个任务里混着查数据库、调第三方接口、写缓存、发消息，那就不该塞进一个函数，它的边界已经模糊，执行时长也无法用“短时”形容。
- 边界清晰的三类典型信号：输入输出类型固定、函数内不读取全局状态、代码块复制到别处也能独立运行。
- 短时完成的实操判断：从函数第一行扫到最后一行，不超过一个屏幕高度；分支嵌套不超过三层；不需要打断点才能理清执行顺序。
- 常见适合场景：登录状态校验、手机号格式判断、价格小数位处理、列表去重、文案截断。
代码重复多少行应该抽函数？一条多数团队默认的底线
代码重复多少行应该抽函数，这是很多开发者在代码评审时被问过的问题，没有官方标准，但行业共识认为：连续出现的相同逻辑超过3行，且出现次数达到2次以上,通常就应该抽取。
这个标准不是拍脑袋定的，行数太少的重复，比如一行取值、一行赋值，抽成函数反而增加跳转成本，超过3行后，重复代码开始携带业务意图，一旦修改,漏掉一处的风险明显上升。
| 重复行数 | 建议动作 | 理由 |
|---|---|---|
| 1-2行 | 多数情况下保持原样 | 抽取后函数调用成本接近甚至超过重复代码 |
| 3-8行 | 出现2次即建议抽函数 | 修改维护时容易出现漏改，边界仍然容易识别 |
| 8行以上 | 无条件抽取 | 重复块内部往往已经包含多步逻辑，直接复制属于隐患 |
不要只盯行数，如果一段10行代码只重复一次，但业务上未来两到三个迭代会再次用到，也可以提前抽，反过来，一段4行代码重复了五次，但每次都有细微参数差异,就得先统一结构再抽。
函数封装和直接写代码的区别：一个金额格式化场景
函数封装和直接写代码的区别，拿最简单的支付金额展示场景就能说清，前端页面多个位置需要把数字转成“1,234.56”格式,直接写死就是每次复制三行：
let amount = 1234.56;
let formatted = amount.toFixed(2).replace(/B(?=(d{3})+(?!d))/g, ",");
console.log(formatted);
复制到第二个页面时，可能会漏掉正则里的某个转义符,抽成函数后：
function formatMoney(amount) {
return amount.toFixed(2).replace(/B(?=(d{3})+(?!d))/g, ",");
}
区别在三个地方：
- 修改成本：格式化规则从“改三处”变成“改一处”。
- 测试成本：函数可以单独跑测试,不用打开整个页面点按钮验证。
- 复用成本：后续页面直接调
formatMoney(price),不用再复制正则。
实际操作路径在主流编辑器里都能一步完成：
- IntelliJ IDEA：选中代码片段，按
Ctrl+Alt+M（Windows）或Cmd+Option+M（Mac）,输入函数名后回车。 - VS Code：选中代码片段，右键选择
Refactor...，点击Extract Method。 - WebStorm：选中代码后按
Ctrl+Alt+M,和IDEA同源。
抽完函数后，编辑器会自动识别返回值和参数类型,这是多数现代IDE的基础能力。
前端函数抽取场景：从按钮防重复提交说起
前端开发里，按钮防重复提交是典型的短时且边界清晰任务，用户在提交订单时连续点击两次,没有防抖处理就会产生重复请求。
把防重复逻辑直接写在每个点击事件里，会出现大量isSubmitting变量，在杭州、成都等地的互联网团队中，这类重复代码是代码评审时被重点点名的对象，比较自然的做法是抽一个withLock函数：
async function withLock(btn, task) {
btn.disabled = true;
try {
await task();
} finally {
btn.disabled = false;
}
}
边界很清晰：输入是按钮元素和一个异步任务，输出是恢复按钮状态，执行过程短：设置禁用、执行任务、恢复状态，三步以内，后续无论登录按钮、支付按钮还是表单提交按钮,都能复用。
这个场景也回答了前端函数抽取场景里常见的疑问：什么时候抽、抽到什么粒度，答案是任务本身能不能用一句话说清楚,能不能在几毫秒内跑完。
为什么函数要短小精悍？看两个维护现场
为什么函数要短小精悍，不需要抽象论证,放到维护现场就明白。
一个超过300行的订单处理函数，里面混着参数校验、库存扣减、优惠计算、日志记录，排查一个越权漏洞时，开发者需要从上到下逐行判断哪一步没做权限检查，实际修复只改两行,定位却花了近一个小时。
一个80行的价格计算函数，涉及会员折扣、满减、优惠券叠加，产品要调整满减规则，开发者在三个分支里反复寻找计算入口,担心改错一行影响其他优惠。
业内专家指出，函数长度和缺陷密度之间存在明显关联，但具体比例因项目类型而异，短函数不一定没缺陷，但定位缺陷的平均时间会缩短,因为你能在十几秒内扫完整段逻辑。
把任务短小精悍地拆开后，还会带来一个附加好处：单元测试好写，一个函数只做金额格式化，测试就是传几个用例看输出，一个函数做格式化、校验、请求、缓存,测试成本会成倍增加。
抽函数能降低开发成本吗？从外包项目报价说起
外包项目里，函数复用的程度会直接影响后续维护报价，一个边界清晰、可独立测试的函数库，后续改需求时不用每次都翻完整项目，多数情况下,这类项目的二次开发沟通成本会低一些。
但抽函数不是零成本，函数数量太多、边界粒度过细，也会让代码跳转频繁，阅读体验下降，相当一部分外包团队在交付时会保留一张函数清单，方便后续维护人员快速定位,这张清单只有在函数边界清晰时才做得出来。
成本上的客观规律是：抽取一个短任务函数，耗时为分钟级；不抽，后续每次改重复代码都要承担漏改风险，这个投入产出比,多数场景下不需要精确计算。
把边界清晰且短时完成的任务放进函数，本质是用一分钟的抽取动作，为之后每一轮维护省下反复理解代码的时间。
函数什么时候需要封装？三个高频追问
函数应该多长合适？
多数情况下不超过20行比较合理，逻辑分支不超过3层，行数不是硬性指标，核心判断依据是：不滚动屏幕能否看完,不打断点能否说清执行顺序。
抽函数会增加性能开销吗？
现代JavaScript引擎、JVM和编译器对短函数的内联优化已经非常成熟，一个几毫秒级别的小函数，调用开销通常可以忽略，多数场景下,可维护性收益远大于纳秒级的调用成本。
边界清晰但执行时间稍长能放函数吗？
能，短时完成不是排斥所有长任务，而是强调任务内部不要同时混杂多个边界，一个导入Excel并做格式转换的函数可能执行几秒，但如果它只做“读取-转换-返回”这一件事，边界依然清晰，可以放进函数，真正不适合的是把“导出Excel”“发送邮件”“记录日志”一起塞进同一个函数。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637663.html
