最近做了一个多人协作,规模也不小的C++项目,其中做了很多有价值的 实践,在此记录,以来说明C++项目需要关注的各方面的问题
工程的组织
当项目由团队共同开发,而非一人来完成时,工程的如何组织会成为一个重要问题;工程组织它是团队工作的基础,不能很好的解决这个问题,将使项目陷于 混乱。 而此问题的本质是,建立何种工程结构以保证,多人 并行多版本的有序开发 。而这个问题不是使用vs2008这种集成环境,能解决好。 在实践中,我的理解有以下几个方面的工作:
代码目录结构
代码目录结构,是代码内在大粒度逻辑结构的体现;
小的项目,根本不用关心这个问题,直接在在vs2008这样的ide里环境就可以搞定了。但当系统要解决的问题越来载大、越来越庞杂时。你要开始考 虑更合适的组织你的代码。分层,共公代码库都会出现,而这些都会在你的目录结构中体现。
目录结构,是一个逐步进化的过程;
目录很重要,但也不需要一开始,就本着假想的终级目标一次搞定。 这是错误的,因为更细粒度的目录结构的使用是有成本的。而以你自己假想的目标一定是错误的。所以还是目录结构还是随着实际需要来慢慢进化 吧。
版本管理
版本管理不仅仅为了防止代码的丢失
团队中,我们时常常把没有用过版本管理的同事来开玩笑,这不是说每天备份几次代码来防止丢失代码的方法不可取,而是版本管理不仅仅解决这个问题,而 且他还可能以:
- 记录你代码修改的历史,为后来找到代码变化的前因后果和中间状态。
- 帮助你建立与还原各种尝试性的代码环境
- 支持同时维护老版本的代码和新版本功能性的开发
- 提供多人并行开发引起的冲突解决机制
工具的选择: 易用、轻量级
如果没有共公的版本管理服务支持,自己用一个git 来管理代码也是非常好的选择。 另外,git 服务对于一个普通的linux用户来说,也是比较容易建立的。
编译组织
使用vs2008,来解决就编译,还需要过多的考虑么? 当有以下问题时,你将会头痛不止。
- 多个工程存在,你想让它晚上自动编译时,往持续集成方向努力时
- 当你想把原来一个模块库改一个名字或改所有的编译参数时
- 你想调整一下代码的目录结构时
当你忍受不了的时候,可以考虑一下boost-build , 当然新东西的引入是有成本的。 但学习一次,到处使用 的诱惑还是很大的