我在建造拥有 20,000 颗星星的雪堆过程中学到的 5 件事

更新： 第二部分已发布！

我叫弗雷德， Snowpack是我创建的。如果你还不熟悉它，Snowpack 是一款 Web 构建工具，它从根本上开启了“解绑式 Web 开发”的潮流，如今 Snowpack、Vite、SvelteKit 和其他现代开发工具都在利用这种潮流。

在这篇文章中，我想分享我在 Snowpack 从最初的提交发展到如今在 GitHub 上获得近 20,000 个 star 和超过 1,000,000 次下载的过程中学到的 5 件事。

本文面向所有对开源软件感兴趣的人。文中重点介绍的经验教训旨在帮助那些有兴趣创建自己的开源项目或为现有项目做出贡献的人。

这将是一个分为两部分的系列文章：在第一篇文章中，我将重点介绍从零开始创建 Snowpack 并找到第一批用户过程中汲取的经验教训。在第二篇文章中，我将重点介绍大规模维护一个流行的开源项目是什么样的体验。

背景

几年前，我启动了一个实验性的 JavaScript 项目，代号：Pika。它有一个可爱的蓝色小老鼠吉祥物，整体氛围轻松愉快，可以容纳许多小型实验性项目。它的统一使命可以概括为：“ESM 是一项很酷的新技术，让我们用它做更多的事情吧。”

Pika 的第一年可能是我人生中最有成效的一年。我创建了 @pika/pack（一个面向 npm 包作者的发布工具）、Pika CI（一个 GitHub Action，可以让你npm install或import()任何 GitHub PR 运行）、一个失败的浏览器内代码编辑器，以及一个后来发展成 Skypack 的下一代 JavaScript CDN 。

其中最引人注目的是 @pika/web，它允许你安装任何 npm 包并直接在浏览器中运行，无需打包工具（例如react -> /react.js：）。你可能更熟悉它的新名字：Snowpack。

以下是我在 Snowpack 从第一次提交到正式发布 v1.0 的过程中学到的五个经验教训，以及我们如何找到第一批用户。

第一课：从个人挫折感开始

Snowpack 最初是一个可以将任何 npm 包转换为可在浏览器中运行的单个 JavaScript 文件的工具。听起来很无聊，对吧？错！

这款小巧而简单的工具开启了一种全新的 Web 开发模式，如今被称为“非捆绑式 Web 开发”。非捆绑式开发引入了诸多特性，例如在开发过程中实现即时重新加载和近乎瞬时的启动速度，即使项目规模增长到 1000 个甚至 10000 多个文件，开发速度也不会下降。相比之下，传统的捆绑式开发环境至今仍普遍存在启动和重新加载需要数秒的情况。

Snowpack 的最初想法源于我工作中遇到的一个简单而个人的挫败感。当时我在 Google 的 Polymer 团队工作，参与开发了一些用于（现已弃用的）HTML Imports规范的替代构建工具。这些工具本身很棒，但它与 npm 的兼容性不佳，因此很少有人使用。

我最终离开了 Polymer 团队，但这个问题一直萦绕在我心头：为什么像 webpack 这样的打包工具会成为在浏览器中使用 npm 包的唯一途径？总得有办法解决 npm 包在浏览器中运行的问题，但非得把整个网站打包吗？Snowpack 就是我尝试寻找其他途径的尝试。

给开源维护者的教训：首先要为自己而开发。如果你对某些事情感到沮丧，其他开发者很可能也有同样的感受。要质疑一切。

第二课：快速行动，保持小规模

当你开发一个新项目时，你很少能预知哪些代码会长期有用，哪些代码最终会被删除。我的职业生涯中已经丢弃过不少代码，所以我明白，快速编写但略显混乱的代码有时也有其价值。当你开始一个新项目时，代码有点混乱是可以接受的。

Snowpack 内部几乎所有的复杂性都由 Rollup 处理。它实际上只是 Rollup 的一个封装，只会打包你的 npm 包，而不是整个网站。意识到 Snowpack 可以利用 Rollup 进行内部开发，为我节省了数周（甚至数月）的开发时间。

说实话，Snowpack在其大部分时间里都只有一支单列index.js纵队。

为了保证项目按计划进行，我专注于一个单一功能：“给我一个包名，我把它转换成 ESM 格式。”这对大多数 Web 开发人员来说太底层了。公平地说，Snowpack 直到 v2.0 版本添加了内置的开发服务器和构建命令后才真正获得广泛用户。但即使没有开发服务器，Snowpack v1.0 的小众定位也足以满足某些工具较少甚至完全不使用工具的 Web 开发人员的需求。

我的总体建议是尽快测试你的想法并制作出一个可运行的演示版本。实际上，这意味着四件事：

1. 利用现有工具！如果可以节省时间，可以 fork 一个类似的开源项目，或者在内部使用现有的工具。
2. 写一些乱糟糟的代码吧！在项目初期，你可能并不完全清楚自己要构建的是什么。过早重构有时甚至比根本不重构更糟糕，所以尽可能长时间地保持代码的灵活性。
3. 控制项目范围！不要开发半成品、半成品的功能。相反，要专注于把一件事做到极致。
4. 别写测试！在把宝贵的空闲时间花在编写测试上之前，先确认你开发的东西确实有用。没有什么比为最终根本用不上的东西编写测试更糟糕的了。

我知道我的某些观点可能会引起争议。“不测试？简直是亵渎神明！” 我只能说，这种策略在多个热门项目和无数无人问津、最终失败的项目中都取得了成功。

这种“快速行动”建议的明显缺点在于它无法长期持续。快速行动意味着背负技术债务，如果你的项目成功了，你迟早都需要偿还这些债务。一旦有用户喜欢你的产品，你就应该开始重新调整优先级，优先考虑稳定性、重构和测试。更多内容将在下一篇文章中讨论。

偿还技术债务可能很漫长。但也有好的一面：如果你的项目最终没能成功，那恭喜你！你没有浪费时间去测试一些没人想要的东西 :)

给开源维护者的教训：编写混乱的代码，保持项目范围小，在你确定自己正在构建有用的东西之前，跳过任何不必要的工作。

第三课：快速修复

你刚刚收到了第一份错误报告。糟糕，有人试用了你的项目，结果出错了！但重要的是，他们足够关心，会告诉你这个问题。

在一个新的开源项目中，你能做的最好的事情之一就是第一时间修复收到的错误报告。随着项目的发展，优先修复错误会变得越来越难，所以趁现在还能快速行动的时候，一定要好好珍惜这段时光。

Sebastian McKenzie（《巴别塔》、《毛线传说》以及现在的《罗马》的创作者）很好地总结了这一理论：

Babel 成功的原因之一在于我能快速修复 bug 并发布新版本。我通常会在收到 bug 报告后的几分钟内发布新版本。这在早期用户普及率较低的时候至关重要。能够快速解决用户遇到的问题，往往能让他们更乐意使用 Babel，即使他们遇到了 bug。——塞巴斯蒂安·麦肯齐，罗马

给开源维护者的启示：你的第一批用户至关重要。务必优先解决他们的问题。

第四课：练习讲好故事

开发者似乎总是对市场营销感到不自在。但遗憾的是，如果你想让人们使用你的项目，最终还是需要向他们宣传。即使是自然而然、病毒式传播的口碑营销，背后也往往有啦啦队在默默付出。

首先，不妨将你的项目分享给朋友或同事，听听他们的想法。即使第一天没能登上 Hacker News 的首页也没关系，你现在需要的只是早期反馈，或许还能找到你的第一批用户。

当你准备与更多人分享你的项目时，有几种方法可以选择。一种常见的做法是，随着时间的推移，以短小精悍的视觉形式讲述你的故事。塞巴斯蒂安就是这样在罗马项目发布前近两年时间里不断营造热度的。马克·达格利什也曾用这种方法在推特上成功推广过香草精。

你也可以发挥创意，做一些独一无二的事情。本·霍姆斯就玩得不亦乐乎，他为自己的全新项目Slinkity在白板前录制宣传视频。

在谈到 Snowpack 时，我决定用一篇长篇博文来讲述我们的故事。这篇文章花了我不少时间，但也让我们有足够的空间来真正解释这个项目的“初衷”。我认为我们必须让情感与我们改变互联网的宏伟目标建立联系。尽管这只是一篇博文，但它发布后引起了巨大反响，并在接下来的一年中被广泛转发和引用。

给开源项目维护者的启示：推广你的作品。找到一种适合你和你的项目的叙事方式。

第五课：忽略喷子，倾听用户的声音

如果你的作品被发布到 Hacker News 上，就要做好被喷的准备。

如果你足够幸运，就能分辨出无知的批评和建设性的批评。忽略那些无知的言论（也就是喷子），但如果可以的话，认真听取建设性的反馈。如果有人真诚地花时间尝试理解你的项目，那么他们的反馈通常会很有价值，只要你能发现这一点。

一种常见的建设性批评是，当有人明明努力想理解你的作品，却仍然误解了其中的一些关键部分时。你很容易就骂对方笨然后置之不理，但请记住，清晰的沟通是你的责任。当有人误解你的作品时，通常意味着你的README文件、文档或整体叙述方式在某些方面还有改进的空间。

给开源维护者的教训：喷子总会喷，别理他们。学会识别善意的、建设性的批评。

主要结论：支持你的早期用户

如果你要启动一个新的开源项目，最好的做法就是确保你的前10位用户满意。以上所有经验教训实际上都是为了找到并以某种方式支持这些早期用户。如果你善待他们，那么你已经创造出了有意义的东西。

如果这一切听起来工作量太大，请记住开源软件没有规则，它的目的是为了带来乐趣。为自己或小众群体开发完全没问题，在这种情况下，您可以忽略大部分建议。