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

Question

我一直在推迟发布我写的图书馆，因为它是我将公开发布的第一个图书馆。以下是我的担忧：

1. 库不是完成它处于一个非常有用的状态，我说它是0.3版本，但是它仍然缺少一些我希望在某些时候实现的功能，并控制它们的实现方式（意味着不合并某些实现）。
2. 我害怕批评，我知道有一些事情应该重新组织/重构，但我很快就写了初级课程，以便为我正在进行的另一个项目起作用。

那么什么时候是发布的最佳时机？我应该把它放在github上并在发布后处理问题吗？或者我应该等到我重构并对我所写的内容感到完全满意？

我看到的大多数类/库总是写得非常优雅，但是我没有在很早的发布阶段看到过，很多课程在初次发布时相当邋？？

Answer 1

提前发布，经常发布。

批评是一件好事，只要它具有建设性。忽略仇敌，注意那些提交错误报告和评论的人。

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

Answer 2

  

你需要中途得到一些东西   首先是有用的，然后其他人会说   “嘿，这几乎对我有用”，而且   他们将参与该项目。

Linus Torvalds
Linux Times（2004-10-25）。

Answer 3

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

如果您这样做是为了指向简历，请将其保持良好状态（代码，不一定是功能完整）。想象一下，未来的雇主会围绕代码查看它的外观，而不是下载和运行代码。

Answer 4

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

提供一组代码样式/标准文档（可能具有关于类关系的架构说明）允许其他开发人员更容易做出贡献，并且以增强库的方式而不是使其成为意大利面条代码的热点。发布一个库，然后不得不重构，同时保持已经占用并在生产环境中使用该库的用户的向后兼容性，这绝非易事。

修改

不要害怕批评......它与领土相关。 一些批评可能是建设性的（注意这一点）。 会有很多其他人批评你的代码（无论他们的原因），而不是建设性的，或者只是将你的工作分开。不同的是，你已经生产了这些产品，它们可能从未对任何OS产品/库做出过贡献。

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

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

Answer 5

我阅读了Google的一位软件工程师Joshua Bloch的文档，该文档讨论了最佳API设计类型。基本上，一旦你发布它，它或多或少设置。他说

  

公共API是永远的 - 一次机会正确

您可以查看幻灯片here。这绝对值得一读。我也有PDF文件;如果你需要，请告诉我。