黑客工坊揭密：原来他们是这样制作开源软件的

近几年来，市面上流行的开源软件越来越多，有的触目惊心，有的改动了世界，有的震惊了国家。在这些黑客工坊里，人们究竟是怎么制作出来的/p>

在这些黑客工坊里，有的做出来的软件很好很流行；有的做出来则很一般但是却也很流行；有的则做出来的很好但是不流行。这究竟是为什么呢/p>

在这篇文章里，我将揭密开源软件的制作流程，中间会插入丰富的示例。考虑到这个过程的复杂性，同时为了让读者能对这个过程一目了然。笔者花了半天，画了一张通俗易懂地开发流程图：

按我的习惯，都是以 MIT 协议来发布开源软件，CC-NC 协议来发布电子书。

发布 0.0.1

是的，当我们取好名字，选好了协议，我们就要发布 0.0.1 版本了。

我的意思是，我们要先抢下这个名字，即占坑。在占坑前，请深思，你真的会写好这个工具吗/p>

比如说，我们使用 Node.js 来写一个 MQTT 的包，那么直接用 MQTT 显然更容易被搜索到：Node.js MQTT。

不行的话，只能用 Mosquitto、Mosca 这种名字了。又或者 moMQTT、iMQTT 这种加上前缀的名字，对应于 Java 平台，就可以是 jMQTT。

4. 开始构建

如我在《全栈应用开发：精益实践》一书中所说，在我们编写软件之前，我们要先做技术选型与搭建开发环境。这里的技术选型就没有那么复杂，就只需要选择一个合适的语言。

选择合适的语言

选择合适的语言，只针对于某些有各种子集的语言，或者小版本间差异比较大的语言，如 Ruby。

不过，还有一个是语言版本的问题。在面向服务器的操作系统，都安装有 Python 环境，但是可能版本不一样。有的是 2.7 的，有的版本可能是 3.4。所以，对于使用 Python 语言的用户来说，还存在选择版本的问题。

如果是一个非 JavaScript 的软件，可能就不存在需要选语言了。如果是一个 JavaScript CLI（命令行）工具，也会有这样的问题，到底是使用编写 CoffeScript、TypeScript 还是 ES6 编写都是一个问题。

在编写 CLI 工具时，就需要了解是要针对某些用户而开发。如对于 Java 程序员来说，他们的电脑上可能没有 Node.js 环境，如果他们使用的是 macOS 电话，那么应该都是有 Ruby、Python环境。同样的，对于前端程序员来说，如果是 Windows 系统，那么也没有 Java、Python 和 Ruby、Go 环境，直接使用 JavaScript 语言就更容易了。

搭建构建 || 寻找模板

自己搭建一个完整的项目架子，是一个相当浪费时间的事情——特别是，我们第一次造轮子的时候。对于一些框架的插件、CLI 工具来说，可能官方直接提供了一个 Hello, World 模板。但是，有一些时候往往没有这么简单。要么找一个差不多的模板，再有针对于的修改；要么复制现有的架子，以我们的名称替换其中的名字。

当我造轮子的时候，我习惯在网上搜索相应的模板，比如说： 、  或者 。在没有合适的情况下，就是找一些使用 TypeScript 写的库，在那之上进行修改。

5. 编写原型：核心功能

核心功能，意味着，不做过多的错误处理——假设用户是按我们的预期行为进行的。依微软公司（Steve Ballmer）的经验，20% 的代码是在核心的逻辑上，而有超过 80% 的代码是在处理错误逻辑上。

所以，在那之前，请先完成核心的功能。它可以让你更快地发布早期的预览版，以早点接受市场的反馈。

构建开源与构建产品是类似的，能越早推出早期版本，就越有机会赢得市场；能不断地继续接受反馈并进行改进，就越能吸引忠实用户；能做好一些市场工作，也就越吸引更多用户。

6. 发布

如果这是我们第一次开发开源软件，那么我们应该先发布几个版本，来测试预期的过程是不是正常的。这个时候，就应该发布另外一个早期版本 0.1.0。从之前占坑的 0.0.1 到 0.1.0 之间，我们会做一些简单的开发，比如，验证一些基本的核心功能是不是好的、编写一个容易读懂的 README和一句话文案。

0.1.0 版本

0.1.0 意味着，我们拥有了一些基本的功能，并且框架本身是可以工作的。

比如说，你要做一个 Ruby 的 Gem 包，那么你的第一个版本是让包可以被调用。哪怕只是一个 Hello, World，它都能验证我们的模式是可以工作的。

如果你要实现的是一个 CLI 工具，那么你需要的就是安装之后，可以直接使用。比如说，最近我在写 Solla 的时候，在引入了 async 之后，就报错了：

这只是其中遇到的一个问题，如果问题过多的话，那么到时候调试起来就有些麻烦。

简化安装、使用

在设计发布流程的时候，我们也要注意框架本身的易用性。如我们开发一个库，那么用户只添加一个依赖就可以使用：

或者：

早先，为了支持不同的语言，还需要 ，后来把这个步骤变成了可选，即配置了一些默认的配置。于是，用户可以直接使用  创建。

麻烦一些的情况下，可能要多一两步：

如果整个安装的过程很复杂，那么使用者在使用的过程中就会放弃。

7. 迭代

好了，我们的早期几个版本都可以工作了，我们正常地走向迭代开发的过程：

特别是用户使用的是你的库，它能表明这个库相当地可靠。

1.0.0 版本

在完成了我们计划的主要功能之后，就可以发布我们的 1.0.0 版本。与版本号 0.5.5 相比来说，版本号 1.0.0 会给人更可靠的感觉。如果你喜欢的话，可以像 Oracle 一样直接发布 2.0 的版本，它与 1.0.0 版本相比，看上去更加可靠。

8. 自动化

接下来，就是对上面做的内容进行一系列的自动化。如自动化文档、自动化 CHANGELOG、持续集成 等等。

自动化 CHANGELOG

可以按 GitHub 上的 Conventional Changelog 来编写自己的提交信息：

就可以优雅地生成 CHANGELOG 了：

来源：Phodal