PluginCodeEnhance v2.0.0 重构：少即是多

之前发布的代码折叠增强插件已经更新到 v1.1.6版本了，当时的想法很简单：把自己需要的、能加的功能都加上。

代码高亮、折叠、行号、复制按钮、标题栏、14 套主题 CSS，别人有的我也要有。当时觉得功能多总没错，想要什么就加什么。

但现在回头看，那是条弯路。

问题是怎么积累起来的

第一个问题是体积。

v1.1.6 的 JAR 包 66.59KB，看起来不大，但前端还要动态加载 Highlight.js 和 14 套主题 CSS，加起来实际资源有四百多 KB。

第二个问题是冲突。

有的主题自带了代码高亮，还没开关，启用插件后代码块高亮显示了两遍——主题一遍，插件一遍。我加了个冲突检测勉强能用，但知道这不是根本解决方案。Halo 主题太多了，每个主题的 CSS 变量、DOM 结构都不一样，不可能全部适配，老夫也无能为力啊 (;¬_¬)。

第三个问题是维护成本。

14 套 hljs 主题 CSS，每次 Highlight.js 更新我都要同步。行号、复制按钮、标题栏这些功能，单个看都不难，但要同时处理暗色模式、移动端、pjax 异步切换、不同主题兼容……边界情况越来越多，代码越来越难改，连 AI 的幻觉也越来越严重。

最让我烦恼的是，每次改一点功能，就要测一遍该功能在所有主题下是否正常。这不对。这也是我这段时间不怎么更新的原因之一，太费时间了。

第四个问题是专业性。

Halo 官方发布的代码高亮插件——Shiki 代码高亮，已经是大家必装的插件了。这让我意识到：高亮这个功能，应该由官方插件或者主题来提供，专业性来说，我拍马比不上。

做减法比做加法难

决定精简的时候，我问了自己一个问题：

代码高亮真的是我想要的码？其实一开始戳中我的爽点，只是代码折叠和长图折叠啊。

答案显然是否定的。

但真要动手砍掉的时候，我犹豫了很久，也挣扎调试了很久。现在要把它们砍掉，那种一个一个集成上去的感觉很难割舍。

后来想明白了：插件的价值不在于它是否存在，而在于它是否解决了我的问题。代码高亮已经有更专业的插件了，那么我就做好折叠吧。

于是做了个大手术：移除 Highlight.js、移除行号、移除复制按钮、移除标题栏，只保留代码折叠和长图折叠。

结果？JAR 包从 66.59KB 降到 13.4KB。前端资源从四百多 KB 降到十几 KB。JS 从六百行砍到两百七十行，CSS 从八百行砍到两百二十行。

但我没想到的是，砍功能比加功能难多了。

砍功能，砍的是“心理防线”

很多做产品的人，都喜欢加功能。

功能多看起来很厉害，显得有存在感。用户说想要这个功能，加；用户说想要那个功能，也加。版本越做越大，功能越加越多。每个人都觉得，功能多总没错。

但产品做久了会发现，加功能容易，删功能难。难的不在技术，在于心理。

• 承认过去的冗余：删功能意味着你要承认，之前加的某些功能是不必要的。没有人愿意承认自己花时间做的东西是没价值的。但你必须过这一关，否则你永远下不了手。

• 摆脱“万一用到”的陷阱：每次想删一个功能，心里就会冒出来：“这个功能虽然现在没人用，但以后万一有人用到怎么办？”。听起来很有大局观，但这是个绝对的陷阱。抱着“万一用到”心态的产品，最后都会变成一个功能堆砌但没人想用的杂货铺。

删功能还需要勇气，特别是删那些你花了大量时间做的功能。

有的时候，少就是多，这是最朴素的道理，但很多人做不到。

减法之后的结果

v2.0.0 更新后，我看了眼 Git 提交记录：29 个文件变更，删除了 3292 行代码，新增了 1091 行。净减少 2201 行。

这个数字让我感觉很好。不是因为 "少就是好"，而是因为每一个剩下的功能，我都清楚它为什么存在。

插件现在只做两件事：代码折叠和长图折叠。但这两件事，它做得很好：

• JAR 包小，加载快

• 无外部依赖，不冲突

• 代码少，好维护

我觉得，这就够了。

再一点开发感受

这次重构，让我想到了一个道理：加功能容易，减功能难。

做产品的时候，我们总想加功能，因为加功能感觉是在进步。但真正的勇气不是敢加功能，而是敢减功能。因为只有减掉不必要的功能，才能把必要的功能做到极致。

如果你也在做产品（不管是不是插件），我的建议是：每加一个功能，问问自己用户真的需要吗，这个功能值得维护吗。如果答案不明确，就别加。与其做一个功能全但难维护的产品，不如做一个功能少但好维护的产品。

共勉之 ~

版本更新

项目地址