C++项目实践 --工程的组织

最近做了一个多人协作，规模也不小的C++项目，其中做了很多有价值的 实践，在此记录，以来说明C++项目需要关注的各方面的问题

工程的组织

当项目由团队共同开发，而非一人来完成时，工程的如何组织会成为一个重要问题;工程组织它是团队工作的基础，不能很好的解决这个问题，将使项目陷于 混乱。 而此问题的本质是，建立何种工程结构以保证，多人 并行多版本的有序开发 。而这个问题不是使用vs2008这种集成环境，能解决好。 在实践中，我的理解有以下几个方面的工作：

代码目录结构

代码目录结构，是代码内在大粒度逻辑结构的体现;

小的项目，根本不用关心这个问题，直接在在vs2008这样的ide里环境就可以搞定了。但当系统要解决的问题越来载大、越来越庞杂时。你要开始考 虑更合适的组织你的代码。分层，共公代码库都会出现,而这些都会在你的目录结构中体现。

目录结构，是一个逐步进化的过程;

目录很重要，但也不需要一开始，就本着假想的终级目标一次搞定。 这是错误的，因为更细粒度的目录结构的使用是有成本的。而以你自己假想的目标一定是错误的。所以还是目录结构还是随着实际需要来慢慢进化 吧。

版本管理

版本管理不仅仅为了防止代码的丢失

团队中，我们时常常把没有用过版本管理的同事来开玩笑，这不是说每天备份几次代码来防止丢失代码的方法不可取，而是版本管理不仅仅解决这个问题，而 且他还可能以：

• 记录你代码修改的历史，为后来找到代码变化的前因后果和中间状态。
• 帮助你建立与还原各种尝试性的代码环境
• 支持同时维护老版本的代码和新版本功能性的开发
• 提供多人并行开发引起的冲突解决机制

工具的选择： 易用、轻量级

如果没有共公的版本管理服务支持，自己用一个git 来管理代码也是非常好的选择。 另外，git 服务对于一个普通的linux用户来说，也是比较容易建立的。

编译组织

使用vs2008,来解决就编译，还需要过多的考虑么？   当有以下问题时，你将会头痛不止。

• 多个工程存在，你想让它晚上自动编译时，往持续集成方向努力时
• 当你想把原来一个模块库改一个名字或改所有的编译参数时
• 你想调整一下代码的目录结构时

当你忍受不了的时候，可以考虑一下boost-build , 当然新东西的引入是有成本的。 但学习一次，到处使用 的诱惑还是很大的