改进和发布应用程序。 需要一些建议
上学期（2008 年 8 月 - 12 月）我和一些同学用 C++ 编写了一个应用程序。 没什么了不起的，它是 Sqlite3 的 ORM。 我们实现了一些东西，比如反射，让它工作起来，并将最终用户从丑陋的东西中解放出来。 就我个人而言，我认为我们做得很好，而且我们的 ORM 实际上对某人有用（尽管它是专门为 Sqlite3 编写的，但它很容易适应其他数据库）。
因此，我得出的结论是，它应该作为开源项目发布在某个地方（最有可能是 sourceforge）。 但是，由于这是一个学期项目，因此在这样做之前需要解决一些问题。 也就是说，它有一些应该修复的内存泄漏，并且可以重构代码的某些部分以使每个人将来的生活更轻松。
我想知道更有经验的 C++ 程序员对某些问题的看法：
- 是否值得重写某些部分 应用新技术（例如， 促进）。
- 我们的ORM是否应该适应最新的 C++标准？ 有什么好处吗 做这个？
- 我们如何知道我们的代码何时 准备好发布了吗？
- 这个 ORM 的可能性有多大 将会被遗忘在迷雾之中 互联网？ （即是否值得 出版超越个人荣誉 作为一名程序员？）
现在我想不出更多的问题，但我想阅读类似的经历。
编辑：我应该将我的代码+注释翻译成英文，对吗？ （自我提问）
提前致谢。
Last term (August - December 2008) me and some class mates wrote an application in C++. Nothing spectacular, it is an ORM for Sqlite3. We implemented some stuff like reflection to make it work and release the end user from the ugly stuff. Personally, i think we made a nice job, and that our ORM could actually be useful for someone (even though its writen specifically for Sqlite3, its easily adaptable for oter databases).
Consequently, i`ve come to the conclusion that it should be published somewhere (sourceforge most likely) as an open source project. But, as it was a term project, there are some things that need to be addresesed before doing that. Namely, it has some memory leaks that should be fixed, and some parts of the code could be refactored to make everyone´s life easier in the future.
I would like to know more experienced C++ programmers opinion on some issues:
- Is it worth rewriting some parts to
apply new techonologies (for example,
boost). - Should our ORM be adapted to latest
C++ standard? Is there any benefit in
doing this? - How will we know when our code is
ready for release? - What are the chances that this ORM
will be forgotten into the mists of
the internet? (i.e is it worth
publishing it beyond personal pride
as a programmer?)
Right now i can`t think of many more questions, but i would like to read on similar experiences.
EDIT: I should probably translate my code + comments to english right? (self question)
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我想我对你的特定问题“更有经验”。 我与他人共同开发了一种开源 Web 应用程序语言和 模板系统很像 Java 或 ASP 出现之前网页设计早期的 ColdFusion。 如果您有兴趣，您仍然可以在 http://www.steelblue.com/ 上看到它。 它仍在我开发时所在的公司使用，但我认为其他地方没有。
我发现，除非你已经建立了良好的联系并且人们正在关注你在做什么，否则让人们使用你的开源代码就像向某人出售你的封闭源代码一样困难。 你确实需要宣传你的项目，并且它应该有某种独特的销售主张，以区别于竞争对手。
所以，这就是不请自来的建议。 以下是针对您提出的问题的一些具体答案……当然，这纯粹是我的意见。
我不会重写任何代码，除非您有想要放入的功能。该功能可能与特定平台或编译器兼容。 它可能是支持新的数据库数据类型或更智能的索引或其他什么。 如果您打算在应用程序中投入一些更认真的工作，请考虑一个路线图，说明您在下一次迭代中可以实际完成的任务，以及哪些选择将使应用程序在周期结束时变得“最好”。
一旦代码可用于特定目的（任何目的），就将其发布。 有两个原因。 首先，现在可能有人想要它用于此目的。 如果不可用，他们会使用其他东西。 此外，如果它是开源的，他们可能会为该项目做出贡献。 其次，越早了解有多少人想要使用该代码就越好。 要么它会比您预期的更受欢迎，并且您可以对继续开发感到兴奋......或者......您会发现甚至没有人访问您的网页来查看您所拥有的内容。 无论哪种情况，最好尽早了解人们真正想要从您的项目中得到什么，这样您就可以在规划新版本时考虑到这一点。
关于“被遗忘在迷雾中”。 我认为大多数项目都是如此。 我不想成为一个沮丧的人，但是看看 Wikipedia，有 5 个足够流行的 C++ ORM 工具值得一提，而且它们都是开源的。 正如我上面所说，除非您可以将您的想法卖给人们，否则他们将采用另一个经过验证的开源解决方案。 要让某人选择您而不是他们，必须满足三件事： 1. 他们需要您拥有而其他人没有的功能。 2. 他们找到您的项目网站，它展示了您的代码的优越性。 3. 他们足够信任你的代码并愿意尝试一下。
另一方面，如果您长期从事此行业并希望继续发展，随着时间的推移，事情会变得更容易。 最终，该项目将涵盖所有基础知识，您可以开始开发其他解决方案中没有的新功能。 此外，您积极开发的时间越长，该项目就越值得信赖。 最后，您将获得更多的经验。 两年后，您将能够更好地说出您的努力将对改善项目产生最大影响。
最后的想法：如果你喜欢它，从中学习，并且它不妨碍你保持餐桌上的食物，那么你的时间就得到了很好的利用。
祝你好运！
-铝
I guess I am "more experienced" with regard to your particular question. I co-developed an open source web application language & template system a lot like ColdFusion back in the early days of web design before Java or ASP were around. You can still see it at http://www.steelblue.com/ if you are interested. It's still used at the company I was at when it was developed, but I don't think anywhere else.
What I found is that unless you are already well connected and people are watching what you are doing, getting people to use your open source code is just about as hard as selling somone your closed source program. You really need to advocate for your project and it should have some kind of unique selling proposition that distinguishes it from the compitition.
So, that's the unsolicited advice. Here are some specific answers to the questions you had...all purely my opinion, of course.
I wouldn't rewrite any code unless you have a featuer you want to put in. That feature might be compatibility with a specific platforms or compilers. It might be to support a new db datatype or smarter indicies or whatever. If you are going to put some more serious work into the applicaiton, think about a roadmap of what you can realistically accomplish in the next iteration and what choices will make the app the "most better" at the end of your cycle.
Release the code as soon as it is usable for a specific purpose, any purpose. Two reasons. First off, there might be someone who wants it for that purpose right now. If it's not available, they will use something else. Also, if it's open source, they might contribute back to the project. Second, the sooner you find out how much people want to use the code, the better. Either it will be more popular than you expect and you can get excited about continuing the development....or....you will find that no one is even visiting your web page to see what you've got. In either case, better to know sooner than later what people really want from your project so you can take that into account when planning new releases.
About the "forgotten into the mists." I think most projects are. I don't want to be a downer, but looking at Wikipedia, there were 5 C++ ORM tools popular enough to get mention and they were all open source. As I said above, unless you can sell your idea to people, they are going to go with another proven open source solution. For someone to choose you over them, three things have to happen: 1. They need a feature you have that the others don't. 2. They find your project web site and it demonstrates the superiority of your code. 3. They trust your code enough to give it a shot.
On the other hand, if you are in this for the long haul and want to continue development thigns get easier over time. Eventually the project will get all the basics covered and you can start developing those new featuers that aren't in the other solutions. Also, the longer you are in active development the more trustworthy the project will seem. Finally, you will get more experience in the nitch. 2 years from now you will be better positioned to say where your effort will have the most impact on bettering the project.
A final thought: If you are enjoying it, learning from it, and it's not getting in the way of you keeping food on the table, it's a good use of your time.
Good luck!
-Al
关于开源部分：
如果你真的想让它成为一个开源项目，你真的应该发布它，无论它的当前状态如何 - 完全工作和调试 - 或者半工作和充满内存泄漏。
只是，如果它的状态很糟糕，请确保记录下来，并给它一个合适的版本号（小于一？）。 然后其他人可能会查看您的代码、建议改进、加入您的团队等等......
Regarding the open source part:
If you really want to make it an open source project, you really should publish it regardless of it's current state - fully working and debugged - or half working and full of memory leaks.
Just, if it's state is bad, make sure to document it, and give it a suitable version number (less than one?). then others may view your code, suggest improving, join your team, etc...
我对此事的相当随意的想法（按照我认为最重要的顺序）：
就像Liran Orevi说的：如果你我们将尽早开源。 合理地记录下来，并花时间提供一份计划或希望未来改进的路线图（这些是对人们帮助你的邀请，所以请注意哪些是没有人在做的）。
SQLite 依赖于相当有限的基础。 也许您不希望您的工具需要更繁重的环境。 如果代码当前不是混乱且难以维护的，您可能希望避免使用 boost 和最新的装饰。 一旦您有了稳定版本（至少 1.0），您就可以开始考虑可以对版本 2 进行的改进。
大多数事情最终都会出现在天空中的大 /dev/null 中，并且只有一种方法可以找到答案......如果它发生在任何地方，你赢。 如果没有，这就是一项适度的投资，也许您在其中学到了一些东西。
My--rather random--thoughts on the matter (in the order I think is most important):
Like Liran Orevi said: if you're going open source release early. Document it reasonable well, and take the time to provide a road map of planned or hoped for future improvements (these are a invitation for people to help you, so note which ones have no one working on them).
SQLite relies on a fairly limited base. Maybe you don't want your tool to demand a much heavier environment. If the code in not currently a tangled and unmaintainable mess, you might want to avoid boost and newest frills. Once you have a stable release (1.0 at least) you can starting thinking about the improvements that can be made for version 2.
Most things end up in the big /dev/null in the sky, and there is only one way to find out... If it goes anywhere at all, you win. If it doesn't it was a modest investment, and maybe you learned something while you were at it.