我是如何在 72 小时内复刻 ClubHouse 的
大家好，我是白宦成（@bestony），前几天在 B 站直播写 ClubHouse 复刻版的开发者。
黑客松 ClubHouse
1.192.90.183
乍一看以为是 fork 了 clickhouse
曰者、 [Chrome 91.0|GNU/Linux]
2021-04-21T17:04:12.000
大家好，我是白宦成（@bestony），前几天在 B 站直播写 ClubHouse 复刻版的开发者。
![](/data/attachment/album/202102/06/221421x7en2g2qgzcoff2g.jpg)


大家好，我是白宦成（@bestony），前几天在 B 站直播写 [ClubHouse 复刻版](https://github.com/bestony/neshouse)的开发者。当然，除了这个身份，在真实生活中，我还是 Linux 中国开源社区的技术负责人，负责开发我们自己的自用工具和平台。


作为一个 indiehacker（自诩的），我想和大家一起来复盘一下，这一次的直播活动和意料之外的爆火。


### 为什么要做 NESHouse


![](/data/attachment/album/202102/06/115418ypdtnz073bvsb733.png)


我其实想到复刻 ClubHouse 的时间是非常早的，我是在 2 月 1 日拿到了 ClubHouse 的邀请码，在试玩了一段时间以后，就觉得这个软件还不错，理念很有意思，但并没有太在意，放在了一边。可到了晚上，因为知道 Elon Musk 要来做分享，作为一个比较欣赏他的人，我自然不能错过，但遗憾的是，当我打开 ClubHouse 的时候，已经有太多的人涌入这个 App，几乎无法使用，总是不停的卡顿。


这时让我产生了怀疑：**这个东西到底有多少的工作量？为什么这么容易性能卡顿？**


结合实际的使用发现，有些时候，我可以正常聊天，但是却会报错，可以发现**问题不在语音服务，而是在 ClubHouse 自身的业务能力不足以支撑超过预期的访问量**。


我上一份工作是在一家云计算企业工作，所以相对来说，对云计算产品有一定的了解。在我看来，这样的一个产品的增量，很难把现有的云计算产品的服务容量打穿，你能想象 ClubHouse 把 AWS、GCP、Azure 等云服务厂商打穿么？


我觉得，要么是开发者的大规模服务的架构经验不足，虽然用了云，但是没设计好，无法充分适应弹性；要么是开发者没有对超过预判的访问量做的预案不足。


这就让我思考，**我能否复刻一个 ClubHouse？用一些更加具有弹性的服务？给大家打个样？** 云计算是好，但用起来也要姿势对，才能不出问题。


### 72 小时复刻一个 ClubHouse，是一个什么概念？


既然要复刻项目，自然要做的不能和碰瓷的一样（这里鄙视几家碰瓷的 App，拿很久之前写的具备了语音聊天的 App，来碰瓷 ClubHouse）。


但我又不希望在这个事情上花费太多的事情，我还有很多更重要的事情要做，所以我选择了 72 小时。48 小时或 24 小时是一般的黑客松的时间长度，但我确实又不熟悉这个项目，所以用 72 小时比较稳妥。


于是便立了一个 Flag ，说**我要在 72 小时内，复刻一个 ClubHouse**。立了个 Flag，说干就干。关于这 72 小时，我希望可以强调两点，也希望这两点能够帮助到你。


![](/data/attachment/album/202102/06/115419em0lwpq9fqfg40zq.png)


#### 1. 明确自己要做的和不要做的


我的时间和精力以及资源都有限，所以并不是什么东西我都能要的。比如在做复刻的时候，考虑到我如果开发原生的 App 或者小程序，就需要提交审核。那我就不能选择做 App，不然 72 小时到了，审核还没过，就食言了。也是出于审核的考虑，**我最终选择了使用 Web 的方式来开发 NESHouse**。


而到了具体的功能特性层面，受限于 Web 和 App 的机制不同，我很难要求用户必须做什么样的操作，也很难确保 App 响应什么样的功能，因此，我对于 ClubHouse 的功能进行了一些删减，邀请上台之类的功能，我就选择性的先不做，将重点放在更加重要的功能中。


**在开发黑客松项目的时候，一定要先想清楚自己要什么，不要什么，这样才能确保自己在给定的时间内完成自己的工作。不然大概率会发现时间马上要截止，但核心功能还没有研发完成。**


#### 2. 选择一些新的、以后可能会用到的技术


在这次项目开发的时候，我选择的前端技术栈并非我过去惯用的 React、Vue ，而是一个相对小众 JS 框架的 Alpine.js。


选择 Alpine.js 的原因很简单，我后续需要在其它的项目上使用这个框架，但我此刻确实也不熟悉。**如果我在这 72 小时里把这个工具用了一遍，如果评估觉得不错，我就可以在后续的项目中使用，如果这次我用的不太好，那我损失的也只有 72 小时，比在正式项目中使用的损失成本要低很多**。


而在另外的两个服务，选择起来就简单多了：


* LeanCloud 的云服务我使用了很多年，使用体验也很不错，而且他们这种 Serverless 云服务，可以让我在开发 [NESHouse](https://github.com/bestony/neshouse) 的时候，免于去写很重的部署和基础逻辑，更加专注在业务逻辑上。
* 音频服务我则选择了国内用户比较多，开发起来也比较方面的声网，声网的 API 比较简单， NESHouse 中的声网音频接入只用 4 行代码就实现了。


除此之外，便是使用了 NES.css 这样的 CSS 框架，来让这个项目更加的有趣，更加的 Funny。


**对于开发黑客松项目的时候，可以想想自己能否接受这一次的失败，如果可以接受自己的失败，不妨将这次黑客松看做是一次玩的机会，玩一玩新的技术，就算失败了，也不过是损失给定的时间。但如果你在工作项目中出现了问题，损失可就大了。**


### 总结


72 个小时的复刻对于我来说不算难，实际上我也只花了 55 个小时就复刻成功了。但更难的，是如何让一个开源项目持续的成长下去，持续的获得用户、获得关注。


最后，大家感兴趣的话，可以移步复刻这个[项目](https://github.com/bestony/neshouse)，看看你能不能做一个自己的 ClubHouse： <https://github.com/bestony/neshouse> 。

