改进和发布应用程序。需要一些建议

时间:2023-01-16 19:09:29

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).

上个学期(2008年8月 - 12月)我和一些同学用C ++编写了一个应用程序。没什么了不起的,它是Sqlite3的ORM。我们实现了一些像反射这样的东西,使其工作,并从丑陋的东西中释放最终用户。就个人而言,我认为我们做得很好,而且我们的ORM实际上对某人有用(即使它专门针对Sqlite3,它很容易适应其他数据库)。

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.

因此,我得出的结论是它应该作为一个开源项目在某个地方发布(sourceforge最有可能)。但是,由于它是一个术语项目,因此在执行此操作之前需要对某些内容进行补充。也就是说,它有一些应该修复的内存泄漏,代码的某些部分可以重构,以使将来每个人的生活更轻松。

I would like to know more experienced C++ programmers opinion on some issues:

我想了解更多有经验的C ++程序员对某些问题的看法:

  • 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?
  • 我们的ORM应该适应最新的C ++标准吗?这样做有什么好处吗?

  • 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?)
  • 这个ORM被遗忘在互联网迷雾中的可能性有多大? (作为程序员,是否值得将其作为个人骄傲发布?)

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.

提前致谢。

3 个解决方案

#1


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.

我想我对你的特定问题“更有经验”。在Java或ASP出现之前,我在Web设计的早期共同开发了一个开源Web应用程序语言和模板系统,就像ColdFusion一样。如果您有兴趣,仍然可以在http://www.steelblue.com/上看到它。它仍然在我开发时所在的公司使用,但我不认为其他任何地方。

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.

我不会重写任何代码,除非你有一个想要放入的特色。该特性可能与特定平台或编译器兼容。它可能是支持新的db数据类型或更智能的指标或其他。如果您打算在应用程序中加入更严肃的工作,请考虑下一次迭代中您可以实际完成的路线图,以及在您的周期结束时哪些选择会使应用程序“更好”。

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.

关于“忘记入迷雾”。我想大多数项目都是。我不想成为一个沮丧的人,但是看看*,有5个C ++ ORM工具很受欢迎,可以提及它们都是开源的。正如我上面所说,除非你能将你的想法卖给别人,否则他们将会选择其他经过验证的开源解决方案。有人选择你,有三件事情要发生:1。他们需要你拥有的功能而其他功能则没有。 2.他们找到了您的项目网站,它展示了您的代码的优越性。他们相信你的代码足以让它有所帮助。

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.

另一方面,如果你长期处于这种状态并希望继续发展,那么随着时间的推移,这将变得更容易。最终,该项目将涵盖所有基础知识,您可以开始开发那些不在其他解决方案中的新特性。此外,您在积极开发中的时间越长,项目看起来就越可靠。最后,你将获得更多的经验。 2年后,您将更好地说明您的努力将对改善项目产生最大影响。

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

祝好运! -Al

#2


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...

如果你真的想让它成为一个开源项目,你真的应该发布它,无论它当前的状态 - 完全工作和调试 - 或半工作和充满内存泄漏。只是,如果状态不好,请确保记录它,并给它一个合适的版本号(少于一个?)。那么其他人可能会查看您的代码,建议改进,加入您的团队等...

#3


My--rather random--thoughts on the matter (in the order I think is most important):

我 - 相当随机 - 对此事的想法(按照我认为最重要的顺序):

  • How will we know when our code is ready for release?
  • 我们如何知道我们的代码何时可以发布?

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).

就像Liran Orevi所说:如果你早点准备开源。记录合理,并花时间提供计划或希望未来改进的路线图(这些是人们帮助你的邀请,所以请注意哪些人没有人工作)。

  • Is it worth rewriting some parts to apply new technologies (for example, boost).
  • 是否值得重写一些部分来应用新技术(例如,boost)。

  • Should our ORM be adapted to latest C++ standard? Is there any benefit in doing this?
  • 我们的ORM应该适应最新的C ++标准吗?这样做有什么好处吗?

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.

SQLite依赖于相当有限的基础。也许你不希望你的工具要求更重的环境。如果代码目前没有纠结和不可维护的混乱,你可能想避免提升和最新的装饰。一旦获得稳定版本(至少1.0),您就可以开始考虑可以对版本2进行的改进。

  • 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?)
  • 这个ORM被遗忘在互联网迷雾中的可能性有多大? (作为程序员,是否值得将其作为个人骄傲发布?)

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.

大多数事情最终都在天空中的大/ dev / null中,并且只有一种方法可以找到...如果它在任何地方都有,那么你就赢了。如果不是,这是一项适度的投资,也许你在学习的过程中学到了一些东西。

#1


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.

我想我对你的特定问题“更有经验”。在Java或ASP出现之前,我在Web设计的早期共同开发了一个开源Web应用程序语言和模板系统,就像ColdFusion一样。如果您有兴趣,仍然可以在http://www.steelblue.com/上看到它。它仍然在我开发时所在的公司使用,但我不认为其他任何地方。

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.

我不会重写任何代码,除非你有一个想要放入的特色。该特性可能与特定平台或编译器兼容。它可能是支持新的db数据类型或更智能的指标或其他。如果您打算在应用程序中加入更严肃的工作,请考虑下一次迭代中您可以实际完成的路线图,以及在您的周期结束时哪些选择会使应用程序“更好”。

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.

关于“忘记入迷雾”。我想大多数项目都是。我不想成为一个沮丧的人,但是看看*,有5个C ++ ORM工具很受欢迎,可以提及它们都是开源的。正如我上面所说,除非你能将你的想法卖给别人,否则他们将会选择其他经过验证的开源解决方案。有人选择你,有三件事情要发生:1。他们需要你拥有的功能而其他功能则没有。 2.他们找到了您的项目网站,它展示了您的代码的优越性。他们相信你的代码足以让它有所帮助。

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.

另一方面,如果你长期处于这种状态并希望继续发展,那么随着时间的推移,这将变得更容易。最终,该项目将涵盖所有基础知识,您可以开始开发那些不在其他解决方案中的新特性。此外,您在积极开发中的时间越长,项目看起来就越可靠。最后,你将获得更多的经验。 2年后,您将更好地说明您的努力将对改善项目产生最大影响。

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

祝好运! -Al

#2


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...

如果你真的想让它成为一个开源项目,你真的应该发布它,无论它当前的状态 - 完全工作和调试 - 或半工作和充满内存泄漏。只是,如果状态不好,请确保记录它,并给它一个合适的版本号(少于一个?)。那么其他人可能会查看您的代码,建议改进,加入您的团队等...

#3


My--rather random--thoughts on the matter (in the order I think is most important):

我 - 相当随机 - 对此事的想法(按照我认为最重要的顺序):

  • How will we know when our code is ready for release?
  • 我们如何知道我们的代码何时可以发布?

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).

就像Liran Orevi所说:如果你早点准备开源。记录合理,并花时间提供计划或希望未来改进的路线图(这些是人们帮助你的邀请,所以请注意哪些人没有人工作)。

  • Is it worth rewriting some parts to apply new technologies (for example, boost).
  • 是否值得重写一些部分来应用新技术(例如,boost)。

  • Should our ORM be adapted to latest C++ standard? Is there any benefit in doing this?
  • 我们的ORM应该适应最新的C ++标准吗?这样做有什么好处吗?

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.

SQLite依赖于相当有限的基础。也许你不希望你的工具要求更重的环境。如果代码目前没有纠结和不可维护的混乱,你可能想避免提升和最新的装饰。一旦获得稳定版本(至少1.0),您就可以开始考虑可以对版本2进行的改进。

  • 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?)
  • 这个ORM被遗忘在互联网迷雾中的可能性有多大? (作为程序员,是否值得将其作为个人骄傲发布?)

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.

大多数事情最终都在天空中的大/ dev / null中,并且只有一种方法可以找到...如果它在任何地方都有,那么你就赢了。如果不是,这是一项适度的投资,也许你在学习的过程中学到了一些东西。