开发和上库流程规范
开发要遵守以下流程规范。
-
需求澄清和串讲
确定要做该需求后，首先要明确该需求的迭代时间，开发流程需要严格遵守我们的迭代时间，参加该需求的需求澄清以及串讲（我们会安排相应会议）。需求澄清可由DE完成（对齐输入以及流程图），需求串讲需要开发者来完成，串讲时需要准备设计文档和测试用例（有文档模版，可以跟SE或者DE联系拿到）。
-
UT
为了保证后面的开发者修改你的代码时不会影响你的功能，或者能够感知这次修改的影响，比如算法实现、字段变更等，需要在上库的同时添加UT。 UT的编写可以参考已经上库的其他用例，建议四段式命名：test_{目标方法名}should{预期结果}when{分支条件}given{输入参数}，可以灵活使用mock方式构造虚拟返回。
-
资料编写
目前，如果新增一个分析能力，需要在操作步骤的第2小节的“--mode参数说明”中添加对应参数的说明，简洁说明该分析能力的作用以及输入输出。 另外，需要在recipe结果和cluster_analysis.db交付件表结构说明中添加表结构说明，明确输入输出。可以详细说明你的分析能力的主要场景、用途甚至是算法原理，保证用户知道这个分析能力的能做什么，对调优有什么帮助。（参考freq_analysis的说明）
-
CI
正常商发需求合入master分支；预研需求合入pre-research分支；poc需求合入poc分支。 提了PR之后，可以评论compile，触发线上CI，会跑cleancode和冒烟，只有全绿，才可以发起代码检视。PR合入需要lgtm标签和approve标签（群里有相应的committer可以加标签）。
-
代码检视
代码上库，需要经过检视，可以将链接发到msprof-analyze代码检视群，说明该PR的标题，然后@相关人进行检视。修改完检视意见后再次@commiter，合代码。 为了让结果可信以及方便其他开发或者测试使用这个分析能力，需要编写测试用例并提供自验报告作为凭证。 注：cluster_analysis.db里面的表格，统一遵守表名大驼峰，列名小驼峰的命名规则。