这篇文章不是我自己写的,是从51CTO博客那边转过来的,觉得挺不错的,又怕以后网址失效了,所以决定转过来,让大家也学习学习。
转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://yaocoder.blog.51cto.com/2668309/789687
大型项目往往需要比较多的人员参与,如果轻视管理协调,工具的规范,代码规范,版本发布规范......那么项目一定会逐步陷入失控的境地。
下面是我经历过的而且认为的一个比较理想的项目规范:
>开发模式
敏捷开发,选择敏捷,是因为我认为敏捷的核心理念之中,“沟通”正好可以解决项目由于参与人员太多的协调问题,对于项目通常有需求讨论会,设计评审会,节点总结和计划会,相关人员都必须参与,这样大家都会在了解目标的情况下去完成工作,避免因交流不畅带来的偏离目标的情况。“迭代”大项目不可能一蹴而就,应该先搭好框架,然后逐渐丰富需求和功能;
>组合模式
结对编程(不是传统意义上的结对)请参见我之前的文章《结对编程其实可以变变?》
http://yaocoder.blog.51cto.com/2668309/773045
>工具的规范:
项目管理工具:JIRA(类似于禅道的项目管理工具)但是我感觉他更好用,功能也更齐全;
知识库:WIKI(使用的是trac中的wiki功能),想想维基百科的用处吧,这相当于针对当前项目的一个知识库,在这里大家可以自己完善有关项目的知识,技术,小技巧,分享给大家,每个人都有权编辑访问;
源码控制:SVN,很难想象还有不引入源码控制的项目;
自动构建:hudson,对于一个大项目光构建时间也得大半天,你还要手工构建吗?
>项目布局
参照开源项目的项目布局;
![](https://i-blog.csdnimg.cn/blog_migrate/cfc5608b8def1aff49a4c6e5652af4fe.png)
>代码的规范
单元测试:C++选用Google Test(简单易用),java选用JUnit;
代码规范:C++选用的
Google C++代码规范,Java采用标准规范;
注释规范:采用
doxygen,方便你生成文档;
日志规范:程序的运行日志在定位错误方面的作用之大我想大家都明白,用log4X(c,c++,java);
代码评审:如果你的代码里含有破窗口,你必须得修好,不会让你搞砸整个代码的;
>测试跟进:
需要质量管理部门随着迭代开发也进行
迭代的测试和回归测试