Open source 我应该什么时候发布代码？

我一直在推迟发布我写的一个库，因为这是我将公开发布的第一个库。以下是我关注的问题：

该库还不完整，它处于非常可用的状态，我可以说它是0.3版，但是它仍然缺少一些功能，我希望在某个时候实现这些功能，并控制它们的实现方式（意味着不合并其他实现）

我害怕批评，我知道有一些事情需要重新组织/重构，但我很快编写了初始类，以便为我正在进行的另一个项目提供功能

那么什么时候是发布的最佳时间？我是否应该在github上发布它并在发布后处理这些问题？或者我应该等到我重构并对我所写的感到完全满意时再做

---

我看到的大多数类/库的编写都非常优雅，但我在早期发布阶段没有看到任何类，很多类在初始发布时是否相当松散？

早期发布，经常发布

批评是一件好事，只要它具有建设性。忽略仇恨者，关注那些提交bug报告和评论的人

代码的内部结构很重要，但如果它能达到预期的目的，则更为重要。通常，重构会改变代码内部的工作方式，但不会影响代码的使用方式。相同的输入和输出

你需要半途而废 先有用，然后别人会说 “嘿，这对我来说几乎奏效了”，然后 他们将参与这个项目

Linus Torvalds

---

Linux时代（2004-10-25）。

这取决于你为什么这么做。如果它是为了提供一些有用的东西，它是有用的，并且有其他图书馆没有的好处，那么就去做吧。只需列出状态和接下来的内容

---

如果你这样做是为了在简历上指出问题，那就把它做好（代码，不一定功能齐全）。想象一下，未来的雇主不下载和运行代码，而是四处查看代码的外观。

无论您是否在不完整的状态下发布代码，都值得拥有足够的文档，让用户了解如何使用库。。。。即使只是API文档。确保所有未完成的任务都标记为待办事项-这有助于维护待完成任务的目标列表，并让用户知道功能/方法/任何东西都没有被忘记

提供一组代码样式/标准文档（可能带有关于类关系的体系结构注释）允许其他开发人员更容易地贡献，并且以一种增强库的方式，而不是让库成为一堆杂乱无章的代码。发布一个库，然后进行重构，同时为已经在生产环境中使用该库的用户保持向后兼容性，这绝非易事

编辑

不要害怕批评。。。它与领土相适应。 一些批评可能是建设性的（注意这一点）。 会有很多人批评你的代码（无论出于何种原因）而没有建设性，或者只是贬低你的工作。不同的是，您已经生产了这些产品，它们可能从未为任何操作系统产品/库做出过贡献

用户希望您立即修复他们的问题，或者编写代码让他们使用您的库，或者简单地说“它不工作”，而不解释它们的意思。你必须学会适应这种全天候的生活方式

---

但是偶尔，有人会感谢你为他们节省了工作时间，或者提供了一些有用的东西。。。突然间，所有的压力和麻烦都变得有价值了。

我读到了谷歌首席软件工程师约书亚·布洛赫的一篇文档，其中谈到了很多关于最佳API设计类型的内容。基本上，一旦你释放了它，它就或多或少地被设置好了。他说

公共API永远是—一个正确的机会

---

你可以看看幻灯片。这绝对值得一读。我也有它的PDF文档；如果您需要，请告诉我。

这篇文章很有见解，特别是在如何处理批评方面。在1.0版本之前，您是否应该保持向后兼容性？只要任何用户提前知道更改，您就可以不必中断向后兼容性。。。总是下载最新版本的用户倾向于期望成为测试人员（尽管在实际情况下提前让他们知道是礼貌的）。。。否则，请遵循Freiheit提到的“尽早发布，经常发布”的原则：然后，您可以弃用旧方法，以便在测试版/生产版中提前考虑更改。始终尝试确保公共方法的输入和输出尽可能保持不变，但在不能保持不变的地方提供预先警告。很可能没有人会有足够的兴趣批评它。有太多的免费图书馆。