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

我一直在推迟发布我写的图书馆，因为它是我将公开发布的第一个图书馆。这里是我的顾虑：什么时候应该发布我的代码？

库不是完成这是一个非常实用的状态，我会说这是0.3版本，但是它仍然缺少一些功能，我想在一些点实现，并控制它们如何实现（意味着不合并某些实现）。
我害怕批评，我知道应该重新组织/重构一些东西，但是我很快就写了最初的类来适用于我正在开发的另一个项目。

那么什么时候发布是最佳时机？我应该把它放在github上，并在发布后解决问题？还是应该等到我重构并对我写的内容感到完全满意？

我看到的大多数类/库总是非常优雅的编写，但是在很早的版本阶段我还没有看到任何版本，初始版本中有很多类相当草率？

来源

2010-09-28 tplaner

很有可能没人会有兴趣去批评它。那里有太多的免费库。 – 2010-10-08 13:58:21

提前发布，经常发布。

只要其建设性，批评是一件好事。忽略仇敌，注意提交bug报告和评论的人们。

代码的内部结构很重要，但它更重要的是它可以用于其预期目的。一般而言，重构将改变代码在内部的工作方式，但不会影响其使用方式。相同的输入和输出。

来源

2010-09-28 14:32:04 Freiheit

你需要得到的东西中途有用的第一，然后别人就会说 “嘿，这几乎是为我工作”，并他们将获得参与该项目。

Linus Torvalds的
的Linux时代（2004-10-25）。

来源

2010-09-28 14:33:55

+1，很好找;） – Jimmy 2010-09-28 14:36:19

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

如果你这样做是为了指向一个简历，请将它做好（代码，不一定是功能完整）。想象一下未来的雇主在代码中查看它看起来像什么，而不是下载和运行代码。

来源

2010-09-28 14:34:20

无论您是否以不完整状态发布代码，始终值得拥有足够的文档以允许用户了解如何使用库....即使它只是API文档。确保将不完整的东西标记为TO DO - 它有助于维护目标完成任务列表，并让用户知道该功能/方法/任何未被遗忘的内容。

提供一组代码样式/标准文档（可能带有关于类关系的架构注释）允许其他开发人员更加轻松地贡献，并以增强库的方式而不是使其成为热门的意大利面代码。从不容易发布一个库，然后不得不重构，同时为已经接受并在生产环境中使用该库的用户保持向后兼容性。

编辑

不要怕批评......它会与领土。一些批评意见可能是建设性的（注意这一点）。会有很多其他人批评你的代码（无论他们的理由是什么），而没有建设性，或者只是取消你的工作。不同之处在于，您制作了这些商品，但他们可能从未贡献过任何操作系统产品/库。

用户希望您立即解决他们的问题，或为他们编写代码以使用您的库，或者只是说“不工作”而不解释其含义。你必须学会和24x7x365一起生活。

但有一段时间，有人会感谢你为他们节省工作时间或提供有用的东西......突然之间所有的压力和麻烦感觉是值得的。

来源

2010-09-28 14:41:14

这非常有见地，特别是在如何对待批评。是否应该预期在1.0版本之前保持向后兼容性？ – tplaner 2010-09-28 14:58:59

只要任何用户事先意识到这些变化，就可以打破向后兼容性...总是下载最新版本的用户倾向于期望成为测试人员（尽管事先知道它们在实际情况下是礼貌的） ...否则遵循Freiheit提到的“早期发布，经常发布”的公理：然后，您可以弃用旧的方法，在测试版/产品发布版中提前发布更改。尽可能确保公共方法输入和输出保持不变，但在不能提供的情况下提供预警。 – 2010-09-28 15:10:27

我读过一篇由Google的市政软件工程师Joshua Bloch撰写的文档，他谈论了很多关于最佳API设计的类型。基本上，一旦你释放它，它或多或少被设置。他说，

公共API是永远 - 一个机会得到它的权利

您可以检查出的幻灯片here。这绝对值得一读。我也有一个PDF格式的文件。让我知道你是否需要它。

来源

2010-09-28 15:01:53 Steve

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

回答

相关问题