开发评审流程.md

仓库原则：

代码成功合并到master分支，才有条件标识审核环节完成、测试完成，项目闭环，未合并到master分支，项目不能结项

master分支需要管理员评审后才能进行合并

管理员分配：

adt/adt_os仓库改动评审： 李奇、何为民

aithinker_dev_sdk仓库改动评审：软件部经理

仓库代码开发评审流程：

创建分支：

仓库默认分支master是保护分支，开发者无法直接将本地的代码直接提交到master分支，需要在本地建立独立分支进行开发，开发完成后推送独立分支到Coding仓库

代码开发：

应用层代码目录:application
应用层代码目录:仅能调用adt/adt_os仓库里面的抽象层接口，不得直接调用os层sdk的底层接口；如果接口不满足，可以提接口需求

抽象层代码目录：adt
抽象层代码目录：屏蔽不同芯片厂商底层SDK的差异，供上层接口调用；接口的迭代需要软件部进行评估，应用开发部可以根据开发场景提接口需求

推送检查：

本地代码推送前CheckList：

	@ 需要使用./pre_commit.sh 脚本进行代码格式化，确保代码风格的一致性
	@ 新增接口，需要对接口进行规范注释（参考doxygen代码注释规范）
	@ 仅提交改动的文件，非必须文件不要提交到仓库，非必须不能改变原文件的权限（代码存储在window的注意）
	@ application应用代码，仅调用了adt/adt_os仓库的抽象层接口，未直接调用底层os的接口/变量/宏定义等

本地代码推送后：
	@ 重新将分支下载下来，确保提交到仓库的代码与本地一致，可编译；如果评审阶段发现仓库代码不能运行，会进行扣分

推送分支：

将开发完毕的本地代码，提交到Coding分支

合并请求：

通过Coding平台，将开发分支合并到master分支，要求按以下进行详细描述：

改动的目的
改动了哪些文件
改动的接口有哪些，为何要进行改动；改动之后是否已评估影响

合并评审：

代码合并评审CheckList	评审建议	评审结果
合并请求描述清晰、工整，描述内容与实际修改内容是否一致
代码能够成功编译
是否仅提交必要的改动文件
代码风格是否符合规范，是否使用./pre_commit.sh脚本进行代码格式化
adt/adt_os 目录，是否有新增接口，接口是否已全部注释，注释是否统一使用英文，能否正确生成API文档
application目录，是否仅调用了抽象层接口/变量，确认未直接调用底层SDK接口、第三方接口
代码是否引用了第三方技术，评估是否存在侵权风险
需要修改底层SDK的配置、代码库等，统一通过补丁的方式进行添加，补丁制作是否合理、可用
，，，
，，，
，，，