项目经验

发布时间:2016-12-8 0:20:01 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"项目经验",主要涉及到项目经验方面的内容,对于项目经验感兴趣的同学可以参考一下。

1. 项目开始前组织培训 使用的工具和技术, 如git, log4net, Resharper, Redmine, NAnt等 项目编码规范 项目使用的框架和设计培训2. 每日构建每日构建要能够自动化执行。覆盖以下内容来保证项目质量: 单元测试的代码覆盖率达到90%,每日构建能够成功通过 所有代码运行过程, log4net可跟踪 通过自动化的验收测试 每天使用NAnt做每日构建,运行单元测试,代码质量检查,代码重复检查,安装包制作和发布3. 关于测试数据在项目开始时,着手准备建立和维护一套数据库结构和测试数据,测试数据要达到以下要求: 测试数据应当全员用一套,可以方便的导入和恢复到初始状态 测试的数据库结构和数据要有版本管理 测试数据应当用相对有意义的数据,比如User Name 不能用asdfasdfas这种, 而用Peter, Jim等。 当bug发生时,如果可以通过补充特例的测试数据达到覆盖bug的效果,应当补全这部分测试数据4. 每日的站会和分享组织项目成员站会,关注项目block issue成为站会的组织者而不是领导者,发挥集体成员的主动性来解决问题和分享经验。分享的内容与重要,大小无关。可能只是发现了一个更好的Api的使用,一个变量命名不好的错误等。让团队成为一个自主的,自我提高和修正错误的团队。5. 关于知识分享工具团队中不断建立的规范、知识、用户需求等,需要有种方式记录和传播。以避免进入新的成员时,只能依靠经验和记忆等不可靠手段来传递的方式。推荐使用Wiki6. 关于项目中使用的第三方API或控件使用第三方API或控件时, 任何对商业使用收费,或者免费但不开源的,都需要得到客户的认可和同意付费团队需要考虑第三方API或控件的稳定性,和可维护性,避免开源项目暂停或者停止维护等问题如果是和客户的技术团队合作,即使使用开源和免费的,也需要得到对方的同意。 开发人员规范: 添加注释1. 类注释类的注释,需要描述类的功能、依赖和如何使用2. 代码注释复杂的逻辑应当添加注释3.使用Region使用关键字region注释使代码更加整洁4.全局变量注释每个全局变量需要写注释5. 程序流程变化注释switch, if, while 等条件判断地方必须写注释6. public方法注释public的方法体中的代码,需要写好详尽的注释 编码规范1. 单行代码宽度不能超过150, 单个.cs文件长度不能超过600行. if, while, for, switch等的嵌套必须<=32. 少定义委托,多使用Event, Func, Action 和 Predicate3. 对于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.尽量少的使用全局变量全局变量需要写好注释,解释全局变量的作用全局变量不要在类中的私有方法中使用

上一篇:项目经理预成长
下一篇:网页打印设置

相关文章

关键词: 项目经验

相关评论