Laravel程序员花3天重构1个函数

一个 burnout 的开发者，在凌晨三点盯着屏幕上的 14 行代码，突然意识到：自己不是为了解决业务问题，而是在证明某种编程范式「可以这么写」。这大概就是函数式编程最隐蔽的陷阱——它承诺让你写出更优雅的代码，却从不告诉你优雅是有利息的。

从「能跑就行」到「必须优雅」

故事的主角是个 Laravel 开发者，原本写了一个简单粗暴的 tryPartial 函数：传入模板名称和参数数组，返回渲染好的 HTML 字符串。代码不长，逻辑直白，业务方用了两年没出过问题。

但某天他读了篇关于函数式编程的文章，突然看自己的代码不顺眼了。那个硬编码的 $args = [] 默认参数，那个提前执行调用的 $callable($args)，在他眼里变成了「不够函数式」的原罪。

于是他动手重构。第一步是把参数默认值从空数组改成 null，这样可以区分「没传参数」和「传了空数组」两种情况。第二步更关键：他让 tryPartial 支持柯里化（currying，即把多参数函数拆成单参数链式调用）——如果只传模板名，返回一个包裹在 Result 类型里的偏函数；如果同时传了参数，再用 ap 方法把数据「应用」进去。

新代码用了 map、ap、Result 这些 Monad 世界的黑话，行数没变少，理解成本却指数级上升。

原版的 tryPartial 是个老实干活的工具函数；新版则像个需要说明书才能启动的精密仪器。

Monad 的诱惑与代价

这里需要解释下 Result 是什么。在函数式编程里，它是一种「容器类型」，用来包裹可能成功也可能失败的操作结果，避免抛异常破坏函数纯度。听起来很美——直到你发现每个操作都要拆成 map、flatMap、ap 的俄罗斯套娃。

作者的原话是：「Where I realized if tryPartial was curried I could return the Result which would contain the functional component and then I could use ap on the Result to apply the data」。这句话的语法结构本身，就是函数式编程认知负荷的绝佳标本。

更微妙的是动机。作者在文章开头坦承自己 burnout 了，「从未想过当程序员」却困在这行。这种状态下，代码重构很容易变成逃避现实的出口——业务需求令人疲惫，但「把代码写得更优雅」能带来即时的掌控感和道德优越感。

Laravel 社区有个老梗：「你写 PHP 的，装什么 Haskell」。话糙理不糙。PHP 的 array 和 callable 是动态类型的野孩子，硬要套上 Haskell 的紧身衣，缝缝补补的地方比优雅的地方多。

技术债的另一种形态

这次重构没有解决任何用户投诉，没有提升渲染性能，没有减少 bug。它解决的是作者心里的一个痒点：「这个函数不够函数式」。

两年后的某个深夜，接手这段代码的新人会盯着 fn(array $args) => Str::of($callable($args)) 这行匿名函数套匿名函数的嵌套，怀疑前任是不是在故意炫技。而作者本人，大概早已离开这家公司， burnout 的痕迹留在 git log 里，像考古层里的火山灰。

技术债通常指烂代码的累积，但「过度设计」是反向的技术债——它把简单问题复杂化，用未来的维护成本换取当下的智力快感。函数式编程的 Monad 模式尤其擅长制造这种债，因为它的抽象层级足够高，高到每个参与者都能说服自己「这是必要的复杂性」。

作者贴出的两段代码对比，本质上是一个微型的技术决策标本。老代码 5 行，新代码 10 行，功能完全一致，测试覆盖率没有变化，唯一增加的是「如果以后需要柯里化调用，不用重写」的可能性。而这个「以后」，在 web 开发的实际场景中，出现的概率接近于零。

burnout 的代码会说话

回到文章开头那个场景：作者说「I never even wanted to be a programmer... how did I get here?」这种 existential 的困惑，和他在代码里追求的「纯粹性」形成奇怪的呼应。当现实世界失控时，人会在虚拟世界里寻找确定性的锚点——对于程序员，这个锚点就是「正确的代码范式」。

但代码不会回答「我为什么在这里」的问题。它只会安静地躺在仓库里，等待下一个 burnout 的人前来解读。

那个 tryPartial 函数的最终命运如何？作者没有说。也许它被回滚了，也许它成了团队里的「祖传代码」，也许某天有人发现 ap 方法的实现里藏着一个微妙的 bug，而调试它需要先读完半本《范畴论》。

如果你也在凌晨三点重构过「本来就能跑」的代码，你后来后悔了吗？