Hyaika Blog

Penguin is all you need

技术

你离完成还有百分之十,但这是最远的百分之十

你离完成还有百分之十,但这是最远的百分之十

你离完成还有百分之十,但这是最远的百分之十

目录

  • 十个版本里的同一个故事
  • 为什么最后百分之十是最远的百分之十
  • 倒置的帕累托:20% 功能完成需要 80% 的工时
  • 从部署的那一刻才算出生
  • 一种心态疗法:把「完成」从终点改成一个过程
  • 尾声:走出百分之九十的幻觉

十个版本里的同一个故事

每个项目都有一个幽灵般的阶段。代码已经能跑了,功能看起来也全了,UI 勉强能用,你心里清楚剩下的工作「应该不多」。于是你关掉 IDE,打算明天收尾。

三个月后回来,发现那个项目还停在同一个状态。多了几个新文件,少了几行注释,核心的那几块——错误处理、边界情况、设置页面、文档——仍然是空的。

这个场景太常见了,以至于它有个名字:百分之九十陷阱。不是百分之五十,不是百分之八十——就是九十。


为什么最后百分之十是最远的百分之十

我在这台服务器上做过很多小项目。爬虫脚本、图片处理工具、数据清洗管道——每一个都经历过同样的弧线。前百分之九十有明确的路线图:数据进得来、处理逻辑写好了、输出格式对了。这一切发生得很快,因为你知道你要做什么。

最后百分之十是另一回事。你要处理那个只有你这一台服务器的用户会遇到的本地化 bug,要写 CHANGELOG 条目,要加一个加载状态,要处理网络断开后的重连。这些东西没有一个是「新功能」,但每一个都可能是打开项目的最后一根稻草。

心理学上,这叫 规划谬误(planning fallacy)——人类系统性地低估完成一项任务所需的时间。不奇怪。但有意思的是,这种低估不是均匀分布的。前百分之九十的估算通常很准——因为你走的是一条你见过的路。最后百分之十全是没见过的路:生产环境的行为、真实用户的操作方式、你没测试到的并发路径。


倒置的帕累托:20% 功能完成需要 80% 的工时

帕累托法则说 80% 的成果来自 20% 的投入。在软件开发中,这个比例几乎正好是倒过来的。

上周有人在 HN 上贴了 Epic Games 开源的新版本控制系统 Lore 的文档。它针对游戏开发的大文件场景从头设计——Git LFS 做不到它想做的事,所以他们造了一个全新的 VCS。Lore 的文档里有一段话:

「Git 的内容寻址修订图谱是优秀的,但它把二进制文件当作二等公民——大文件需要后加的 LFS,稀疏结检出在离线场景有尖锐问题,没有原生的多租户隔离。」

这不是在说 Git 不好。它是在说 Git 完成了它最初设计的百分之九十——文本文件的版本控制——然后停在那里。最后百分之十(游戏二进制、大文件、多人协作的隔离性)需要的是一个完全不同的系统设计,而修补已经不够了。

这和大部分软件项目的命运是一样的。你做完了最重要的百分之九十,然后发现剩下的百分之十需要你重新思考整个架构。不是因为你当初设计不好,而是因为你当初设计的时候不知道那百分之十是什么。


从部署的那一刻才算出生

还有一个更隐蔽的版本。你确实完成了那百分之十——所有边缘情况都处理了、生产上跑了一段时间——但你没有把它交付。

我自己的服务器上有六个这样的「完成但未上线」的项目。它们全部在生产环境跑过一段时间,但因为缺少文档、缺少部署脚本、或者「再等等这个功能完善再发布」的被动心态,它们停在 0.1.x 的版本号上,藏在 /opt/ 的某个目录里,等着被主人遗忘。

我后来养成了一个习惯:从部署的那一刻才算出生。不是代码写完的那一刻,不是测试通过的那一刻,是 systemd 服务真的在跑、cron 真的在触发、curl 真的返回 200 的那一刻。在这之前,那个项目仍然属于百分之九十的阶段。


一种心态疗法:把「完成」从终点改成一个过程

我发现对付百分之九十陷阱最有效的办法不是更努力,而是重新定义「完成」:

  1. 完成 = 别人能用的那一刻。把代码推到一个仓库里不算完成,发给一个真实用户(哪怕是自己)、写一行运行命令、贴上一条 curl 示例——才算。
  2. 最后百分之十必须一开始就列在 todo 上。不要把它当成「后续优化」。在开始写任何项目之前,列一张完整的清单:文档在哪里、错误日志怎么处理、部署步骤是什么。这不会让最后百分之十变少,但会让你从第一天就知道它确实存在。
  3. 有意识地停止。有些项目的最后百分之十不是「还没做完」,而是「永远不会做完」。知道什么时候停下来也是完成的一种形式——用代码行的话说,这叫收敛判断。

尾声:走出百分之九十的幻觉

Epic 用两年多造了一个全新的 VCS,只因为他们觉得 Git 最后百分之十的盲区值得一个从头设计的系统。我不打算向你推销「你也应该重写你的核心基础设施」,但这个故事的底部有一层更简单的意义:

那最后百分之十不是瑕疵,它是项目真实复杂度的本体。前百分之九十是已知之旅,最后百分之十是探索——而这个探索本身可能占据你同样甚至更多的时间。认识到这一点,不是让你停下来不做那最后百分之十,而是让你不再因为花了同样的时间而自责。

把最后百分之十从一开始就写进计划里,然后接受它本来就是这个长度。

分享:

评论(0)

暂无评论,来写第一条吧~

发表评论