1. 项目开始前组织培训
使用的工具和技术, 如git, log4net, Resharper, Redmine, NAnt等
项目编码规范
项目使用的框架和设计培训
2. 每日构建
每日构建要能够自动化执行。
覆盖以下内容来保证项目质量:
单元测试的代码覆盖率达到90%,每日构建能够成功通过
所有代码运行过程, log4net可跟踪
通过自动化的验收测试
每天使用NAnt做每日构建,运行单元测试,代码质量检查,代码重复检查,安装包制作和发布
3. 关于测试数据
在项目开始时,着手准备建立和维护一套数据库结构和测试数据,测试数据要达到以下要求:
测试数据应当全员用一套,可以方便的导入和恢复到初始状态
测试的数据库结构和数据要有版本管理
测试数据应当用相对有意义的数据,比如User Name 不能用asdfasdfas这种, 而用Peter, Jim等。
当bug发生时,如果可以通过补充特例的测试数据达到覆盖bug的效果,应当补全这部分测试数据
4. 每日的站会和分享
组织项目成员站会,关注项目block issue
成为站会的组织者而不是领导者,发挥集体成员的主动性来解决问题和分享经验。
分享的内容与重要,大小无关。可能只是发现了一个更好的Api的使用,一个变量命名不好的错误等。
让团队成为一个自主的,自我提高和修正错误的团队。
5. 关于知识分享工具
团队中不断建立的规范、知识、用户需求等,需要有种方式记录和传播。以避免进入新的成员时,只能依靠经验和记忆等不可靠手段来传递的方式。
推荐使用Wiki
6. 关于项目中使用的第三方API或控件
使用第三方API或控件时, 任何对商业使用收费,或者免费但不开源的,都需要得到客户的认可和同意付费
团队需要考虑第三方API或控件的稳定性,和可维护性,避免开源项目暂停或者停止维护等问题
如果是和客户的技术团队合作,即使使用开源和免费的,也需要得到对方的同意。
开发人员规范:
添加注释
1. 类注释
类的注释,需要描述类的功能、依赖和如何使用
2. 代码注释
复杂的逻辑应当添加注释
3.使用Region
使用关键字region注释使代码更加整洁
4.全局变量注释
每个全局变量需要写注释
5. 程序流程变化注释
switch, if, while 等条件判断地方必须写注释
6. public方法注释
public的方法体中的代码,需要写好详尽的注释
编码规范
1. 单行代码宽度不能超过150, 单个.cs文件长度不能超过600行. if, while, for, switch等的嵌套必须<=3
2. 少定义委托,多使用Event, Func, Action 和 Predicate
3. 对于public的函数, 不要太长,可以分拆成多个private方法减少代码长度.
4. 变量命名
4.1 控件的名称,不允许是button1, textbox1这种无意义的名字
4.2.使用能读懂的命名(尽量使用全名)
4.3 Event等delegate的命名
Event的命名要体现出事件, 如...Changed, 体现发生了什么,而不是告诉要做什么
bad: publicEventHandler ExtendOrderDetails;这里直接告诉别人做什么
good: public Action<bool> OrderTrackTypeChangedToOther; 这里只是告诉别人发生了什么
5. 关于注释的代码
如果注释的代码具有通用性,就提取到公共类中
如果一些代码确定没有用处,注释的代码最好删除掉(如果不确定, 暂时保留,也不要超过2天)
不要担心, 可能由于需求改动,又会改回原来的代码,因为:
* 可以通过SVN获取
* 我认为敏捷的一个重要思想是,小步快(稳)走, 关注当前。 所以不要为未来不确定的东西支付成本
保留注释代码一般用于:
1. 为了调试作用,暂时注释代码
2. 一些关键的配置代码, 比如IsLive变量用来判断当前系统是否上线, 可能会有
IsLive = True;
//IsLive = False;
单元测试
1.尽量在项目中覆盖单元测试,依据项目不同,团队可以制定自己的标准(如代码覆盖率等)
2.修复bug前,先写单元测试覆盖bug, 然后再fix bug
类
1.单一职责
业务逻辑类中不要包含界面相关代码
切实保证这个类中的代码,和类的名字(定义)一致。
只告知外界本类内部发生的事情,不要直接发指令让外界做什么。例子: 类中的delegate, event, 是用来告诉类内部发生了什么,不要指导外界做什么。
尽量隐藏类内部的实现细节。比如MS的File类,包含操作文件的方法实现,但是外界不需要知道具体如何实现的。
2.类应当尽量依赖其它小的类,依赖的其它的类应该尽量放到构造函数中
假如有一个拧螺丝的功能类,只需要一个扳手就能解决问题,那么不要让这个类依赖于一个工具箱
3.减少依赖于类, 应当更多的依赖于接口
把上面的扳手类抽象成一个接口,让拧螺丝的功能类依赖于接口
4.尽量少的使用全局变量
全局变量需要写好注释,解释全局变量的作用
全局变量不要在类中的私有方法中使用