Criticism is a good thing as long as its constructive. Ignore the haters, pay attention to the folks filing bug reports and commenting.
The internal structure of the code matters, but it matters more if it works for its intended purpose. In general, refactoring will change how code works internally but will not affect how it is used. Same inputs and outputs.
It depends on why you are doing this. If it's to provide something useful and it's useful and has benefits that no other library has, then go for it. Just list the status and what's coming next.
If you are doing this to point to on a resume, get it in good shape (the code, not necessarily feature complete). Imagine a future employer poking around the code to see what it looks like, not downloading and running the code.
Whether you release the code in an incomplete state or not, it's always worthwhile having enough documentation to allow users to understand how to use the library.... even if it's only API docs. Make sure that anything incomplete is tagged as TO DO - it helps to maintain a target list of tasks to complete, and lets users know that the feature/method/whatever hasn't been forgotten.
Providing a set of code style/standard documents (perhaps with architectural notes on class relationships) allows other developers to contribute more readily, and in a manner that enhances the library rather than making it a hotch-potch of spaghetti code. It's never easy releasing a library, then having to refactor, while maintaining backward compatibility for users who have already taken up and are using that library in a production setting.
EDIT
Don't be afraid of criticism... it goes with the territory. Some critcism can be constructive (take heed of that). There'll be plenty of other people who criticise your code (for whatever their reason) without being constructive, or who just denegrate your work. The difference is, you've produced the goods, they probably haven't ever contributed to any OS product/library.
Users expect you to fix their problems immediately, or to write their code for them to use your library, or simply say "it doesn't work" without any explanation of what they mean. You have to learn to live with that 24x7x365.
But just once in a while, somebody will thank you for saving them hours of work, or for providing something useful... and suddenly all the stress and hassle feels worthwhile.
I read a document by Joshua Bloch, a pricipal software engineer at Google that talked a lot about the best type of API design. Basically, once you release it, it is more or less set. He says
Public APIs are forever - one chance to get it right
You can check out the slides here. It's definitely worth reading. I have a PDF of it as well; let me know if you need it.
发布评论
评论（5）
尽早发布，经常发布。
批评只要是建设性的，就是一件好事。忽略那些讨厌的人，注意那些提交错误报告和评论的人。
代码的内部结构很重要，但如果它能达到预期的目的，那就更重要了。一般来说，重构会改变代码内部的工作方式，但不会影响其使用方式。相同的输入和输出。
Release early, release often.
Criticism is a good thing as long as its constructive. Ignore the haters, pay attention to the folks filing bug reports and commenting.
The internal structure of the code matters, but it matters more if it works for its intended purpose. In general, refactoring will change how code works internally but will not affect how it is used. Same inputs and outputs.
莱纳斯·托瓦尔兹
Linux 时报 (2004-10-25)。
Linus Torvalds
Linux Times (2004-10-25).
这取决于你为什么这样做。如果它是为了提供一些有用的东西，并且它很有用，并且具有其他库所没有的好处，那么就去做吧。只需列出状态和接下来会发生什么。
如果您这样做是为了在简历上指出，请使其保持良好状态（代码，不一定功能完整）。想象一下，未来的雇主会浏览代码以查看其外观，而不是下载并运行代码。
It depends on why you are doing this. If it's to provide something useful and it's useful and has benefits that no other library has, then go for it. Just list the status and what's coming next.
If you are doing this to point to on a resume, get it in good shape (the code, not necessarily feature complete). Imagine a future employer poking around the code to see what it looks like, not downloading and running the code.
无论您是否以不完整的状态发布代码，拥有足够的文档来让用户了解如何使用该库总是值得的……即使它只是 API 文档。确保任何未完成的事情都被标记为待办事项 - 它有助于维护要完成的任务目标列表，并让用户知道该功能/方法/任何内容都没有被忘记。
提供一组代码样式/标准文档（可能带有有关类关系的体系结构注释）允许其他开发人员更容易地做出贡献，并且以增强库的方式而不是使其成为意大利面条代码的大杂烩。发布一个库，然后必须重构，同时为已经在生产环境中使用该库的用户保持向后兼容性，这绝非易事。
编辑
不要害怕批评......它与领域相适应。
一些批评可能是建设性的（请注意这一点）。
会有很多人批评你的代码（无论出于什么原因），但没有建设性，或者只是贬低你的工作。不同之处在于，您已经生产了产品，它们可能从未为任何操作系统产品/库做出过贡献。
用户希望您立即解决他们的问题，或者为他们编写代码以使用您的库，或者只是说“它不起作用”而不解释其含义。你必须学会忍受 24x7x365。
但偶尔，有人会感谢你节省了他们的工作时间，或者为他们提供了一些有用的东西……突然间，所有的压力和麻烦都变得值得了。
Whether you release the code in an incomplete state or not, it's always worthwhile having enough documentation to allow users to understand how to use the library.... even if it's only API docs. Make sure that anything incomplete is tagged as TO DO - it helps to maintain a target list of tasks to complete, and lets users know that the feature/method/whatever hasn't been forgotten.
Providing a set of code style/standard documents (perhaps with architectural notes on class relationships) allows other developers to contribute more readily, and in a manner that enhances the library rather than making it a hotch-potch of spaghetti code. It's never easy releasing a library, then having to refactor, while maintaining backward compatibility for users who have already taken up and are using that library in a production setting.
EDIT
Don't be afraid of criticism... it goes with the territory.
Some critcism can be constructive (take heed of that).
There'll be plenty of other people who criticise your code (for whatever their reason) without being constructive, or who just denegrate your work. The difference is, you've produced the goods, they probably haven't ever contributed to any OS product/library.
Users expect you to fix their problems immediately, or to write their code for them to use your library, or simply say "it doesn't work" without any explanation of what they mean. You have to learn to live with that 24x7x365.
But just once in a while, somebody will thank you for saving them hours of work, or for providing something useful... and suddenly all the stress and hassle feels worthwhile.
我阅读了 Google 首席软件工程师 Joshua Bloch 撰写的一份文档，其中详细讨论了 API 设计的最佳类型。基本上，一旦你释放了它，它或多或少就已经确定了。他说
您可以查看幻灯片 此处。这绝对值得一读。我也有一份 PDF 文件；如果您需要，请告诉我。
I read a document by Joshua Bloch, a pricipal software engineer at Google that talked a lot about the best type of API design. Basically, once you release it, it is more or less set. He says
You can check out the slides here. It's definitely worth reading. I have a PDF of it as well; let me know if you need it.