用于设置 Visual Studio/C++ 的资源开发环境
自从转向数据库开发以来，大约 15 年里我没有做过太多“前端”开发。我计划开始使用 C++ 开发一个个人项目，因为我已经有了 MSDN，所以我可能最终会在 Visual Studio 2010 中完成它。我正在考虑最终使用 Subversion 作为版本控制系统。当然，我希望尽快启动并运行，但我也希望避免因组织不良的项目环境而陷入任何陷阱。
所以，我的问题是，是否有任何好的资源和常见的最佳实践来建立开发环境？我正在思考如果需要的话在哪里将解决方案分解为多个项目，如何设置单元测试过程，组织资源，目录等。
是否有任何我应该确保拥有的很棒的附加组件从一开始就设定了？
大多数教程只有一个简单的项目，输入您的代码并单击“构建”即可看到您的新应用程序显示“Hello World！”。
这将是一个带有多个 DLL 的 Windows 应用程序（无 Web 开发），因此不需要部署到 Web 服务器类型的过程。
大多数情况下，我只是想确保我不会错过任何重大的事情，然后因此必须进行广泛的重构。
谢谢！
I haven't done much "front-end" development in about 15 years since moving to database development. I'm planning to start work on a personal project using C++ and since I already have MSDN I'll probably end up doing it in Visual Studio 2010. I'm thinking about using Subversion as a version control system eventually. Of course, I'd like to get up and running as quickly as I can, but I'd also like to avoid any pitfalls from a poorly organized project environment.
So, my question is, are there any good resources with common best practices for setting up a development environment? I'm thinking along the lines of where to break down a solution into multiple projects if necessary, how to set up a unit testing process, organizing resources, directories, etc.
Are there any great add-ons that I should make sure I have set up from the start?
Most tutorials just have one simple project, type in your code and click on build to see that your new application says, "Hello World!".
This will be a Windows application with several DLLs as well (no web development), so there doesn't need to be a deploy to a web server kind of process.
Mostly I just want to make sure that I don't miss anything big and then have to extensively refactor because of it.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我也希望这个问题有一个好的答案。我所做的就是对其进行设置，以便每个解决方案都引用 $(SolutionDir)\build 目录来包含和库。这样，每个依赖于其他项目的项目都可以访问它们，并且版本不会竞争。然后有构建后命令将标头和 .lib 文件打包到“分发”文件夹中。我使用 CC.net 在签入时构建每个包。当我们决定更新一个依赖项目时，我们将其“发布”给自己，这需要手动标记，手动将 current.zip 复制到发布区域并为其提供版本号，然后将其复制到依赖项的项目的 /build 中升级。
除了最后的手动过程之外，一切都运行得很好。我真的很想摆脱它，但似乎做不到。阅读 ACM 中有关“持续发布”的文章，如果能实现该文章就太好了，但目前还没有。我不断告诉自己我会做一个。
如果我在 Windows 文件系统中使用“连接”，我可以将“分发”链接到“构建”，然后构建一个辅助解决方案，其中包括相互依赖来构建产品的所有项目。当我这样做时，虽然它鼓励开发人员使用它进行积极的开发，但这阻碍了 TDD 和正确的发布。
I would also like a good answer to this question. What I've done is set it up so that each solution makes reference to a $(SolutionDir)\build directory for includes and libraries. That way each project that has dependencies on other projects can access them and versions won't compete. Then there are post-build commands to package up headers and .lib files into a "distribution" folder. I use CC.net to build each package on checkin. When we decide to update a dependency project we "release" it to ourselves, which requires manual tagging, manual copying current.zip into a releases area and giving it a version number, and copying that into the /build of the projects that depend on the upgrade.
Everything works pretty great except this manual process at the end. I'd really love to get rid of it but can't seem to. Read an article from ACM about "Continuous Release" that would be really nice to have an implementation of but there isn't any. I keep telling myself I'll make one.
If I use "junctions" in the windows filesystem I can link "distribute" to "build" and then build a secondary solution that includes all the projects that are dependent on each other to build a product. When I did that though it encouraged developers to use it for active development, which discouraged TDD and proper releasing.