这个是ads管理的项目,请在Issues中查看 一、优先级类:用于表示issue的紧要程度,包括 Add P0-优先级极高,请停下手头所有事情,即刻开始解决该问题 Add P1-优先级较高,希望可以优先安排,如没有更高的优先级,即刻开始解决该问题 Add P2-优先级一般,自行安排 Add P3-优先级较低,可以安排在下一个mileStone Add P4-优先级最低,有空时候完成即可 二、任务性质类:用于表示任务内容,包括 Add cBug-定义为bug,影响功能正常运行 Add cFeature-定义为新功能 Add cChore-定义为杂项,重构,支持,讨论在属于此类 Add cCustomerService-定义为客服反馈,需要进一步的定义其优先级和类别 Add cFeedback-定义为反馈,从BD来的信息,需要进一步的定义其优先级和分类 三、处理状态类:用于表示当前任务的处理状态,包括 Add sNew-新建状态,需要分配该issue给某人 Add sAssigned-被分配状态,已经分配给某人,需要该人进行确认 Add sAccepted-被接受状态,被指配的人接受了该issue Add sFixed-被修复状态,已经完成该issue Add sVerified-被确认状态,相关人员已经完成确认 Add sClosed-被关闭状态,该issue完成 随着技术人员的增多和业务系统的增长,原来自由的Unit test和Code Review流程逐渐无法满足我们的需求,所以在此初步规范下Unit test和Code Review的要求,从本周开始进行试运行。如果对此有疑问和意见,可以随时讨论,不断改进。 此邮件内容也放在wiki上:http://git.fm/ufp-xp/AdsEngDocs/wiki 目标:让开发流程更加顺畅,代码质量逐步提高,减少由代码bug造成的线上故障。 开发要求: 1、每个任务在github上有对应的Issue记录,优先级和分类参见:http://git.fm/ufp-xp/AdsEngDocs/blob/master/README 2、每个任务都有简单Design Doc,可以写在Issue里,也可以写在代码注释中。 3、避免在展示层(View/Controller)加入业务逻辑代码,逻辑都在Service/Logic层完成。 4、代码规范参见:http://git.fm/umeng/uhg/wiki/Coding-style Unit Test要求: 1、目前要求ads的UnitTest主要集中在Service/Logic层: a) 新功能Method覆盖率为100%。 b) 新逻辑的测试覆盖率为100%。 c) Unittest必需可以顺利运行通过。 2、测试代码在提交代码时一起进行Review; 3、后续考虑进行peer test(由其他人确认unittest是可以跑通的),以及daily build。 4、脚本类代码暂不做要求。 CodeReview流程: 1、在github上发起PullRequest,同时@Reviwer;对一些小需求可以自己作为reviewer,但要自己承担责任。 2、通过Reviewer需要在规定时间内, a) 小功能需要在24小时内完成,大功能要在48小时内完成。特殊情况下可以找其他人作为reviewer。 b) Reviewer可以代码Review、comment、Merge操作。 c) 此情形下不能自己通过PullRequest。 3、代码merge进Master分支后,通知OP人员进行上线操作。 4、Pull request的通过者对代码造成的bug承担部分责任。 Review组划分: 交换:zhanyinan、jianglei UFP:chenmosha、yanshuyuan adNetwork:wanghaiyun、jianglei 我做为所有项目Review的backup,另外不定期我们也会用投影仪做全组Review。