意见反馈与建议
后端/前端问题与规范：
进行需求评审，设计确定底层架构。
目前缺少内部架构设计，需补充开发架构文档
功能设计：目前对功能模块的描述较少，加大沟通成本。
对应开发对接需求方，开发需对功能进行理解并简单设计，还需对数据库进行设计，内部进行简单的评审，在开发阶段调试过程，遇到需求变更，积极应对沟通。对需求进行合理的沟通，如较重大的模块可合理延期至下期实现。
开发自测：在发布到测试环境前，开发需对模块进行单元测试，测试提供一份用例给予开发，标注优先级。未通过自测用例不允许发布到测试环境。
定义API文档，先确定文档字段。
补充异常常用状态码，异常状态时抛出提示。
数据库只增加不允许删除，数据库补充字段备注意义，表名，表里的字段（使用下划线进行连接），
数据库屏蔽删除的功能，用0/1代替APP版本缺少标识：开发/测试，区分环境
由钟含勇（后端）、陈晓晴（前端）对代码进行审核，发现问题截图发布到钉钉群指给相应的开发人员。
自动化更新数据库。
SQL语句脚本根据版本号进行自动化对比。
前端和产品设计沟通问题。
git代码commit具体内容执行：
提交前的comment内容需要按第2点里指定格式。
例如: 【修改原因】视频上传失败问题 【修改内容】注释image校验 【修改人】钟含勇 【检查人】钟含勇
新需求和bug修复，前台、后台代码可以自己从其他分支合入到develop开发分支。
先从feature_dev_v1.0分支拉取最新代码到本地开发分支，然后创建一个自己的分支，把代码提交到自己分支上。最后创建合并请求基准分支选择feature_dev_v1.0预发布分支，对比分支选择自己创建的分支。
在对应的项目里创建合并请求后，前端提交合并请求后指派给xqchen，后端提交合并请求后指派给zhonghanyong。
develop开发分支的代码会更新到开发环境上。
代码合入feature_dev_v1.0预发布分支会更新到外网预发布测试环境上。
确保feature_dev_v1.0预发布分支的代码没问题后，发布到正式环境前会把feature_dev_v1.0预发布分支的代码全量合入到master主干分支。
后端代码规范问题：IDEA里可以安装sonarLint插件用于扫描本地静态bug，安装Alibaba Guidance编码规约插件，规范代码格式，每周进行一次代码评审。
前端代码规范问题：Hbuilder X里需要安装ESLint插件用于检测编码规约，规范代码格式，每周进行一次代码评审。
需产品/项目协助问题：
产品补充需求文档：开发与测试时需要详细的需求文档进行辅助开发测试，文档要求细化，明确文档的流程。
如：文档更改记录，文档及时性。提前进行需求评审，产品讲解需求，开发测试进行理解，沟通进行沟通分析实现难度。
需求整改需合理进行：判断合理的时间范围，需求优先级，已开发的功能增加需求需要合理的进行分期和排期
禅道规范：功能节点细化需求增加记录到禅道。
整理出分工表，细化模块标注对应的前后端测试负责人。
根据需求内容合理排期上线时间，与开发/测试确认需要耗费的工作日周期后再决定上线的时间，合理安排工作。
需求变更：需求变更需通知相应的开发测试人员，并更新需求文档。
测试问题与规范：
禅道规范问题：
测试将bug提交到禅道：标注路径，细化描述，定位问题。
未解决的问题，bug解决最迟三天内修复回复，未修复问题给予合理解释，比较重大的问题可进行延期，且通知到相应人员。
功能上线后，将本期的测试用例发布到禅道保存。
测试编写完成测试用例后，需与相关人员，产品等进行简单的用例评审，如用例不通过，后续进行修改再与产品核对。
开发需提供API文档给予测试人员，需让测试了解开发设计。
涉及支付相关的模块，在正式环境需要进行一个支付相关的测试，需要和财务、运营人员沟通。
运维问题与规范：
数据库不同步会导致线上数据错误，需要后端与运维确定定义工具（最好是自动化的）
线上发布问题： 包含版本需求，需前后端负责人签字。
回滚机制（需运维确认），设置权重。
防火墙不必要的端口不进行开放， 控制并发量，对特定的IP进行封杀，从白名单到黑名单进行封杀。
Jenkins持续化构建集成。
禅道与钉钉、邮箱打通消息通知。
代码监控日志推送。
数据库里后期要屏蔽delete操作语句。
全局错误、异常需要通过邮箱、钉钉通知到对应的功能负责人。
前期替换补丁包前需要做好上个版本的包备份。
项目经理问题与规范：
更新版本发布，需要确认单，需要版本对应的负责人签名
SQL脚本执行，需要确认签字。
数据库备份机制（异地备份）。
代码回滚机制。（线程核心数对比）
灰度发布机制。
每天下午六点每个小组可以组织组内成员开一个小例会（简单沟通一下）。
后期需要落实bug问题修复复盘工作。
禅道任务分配规范：
按模块分配后，需要找到到对应的产品负责人确认。
根据和产品的沟通记录，把详细内容记录到禅道上。
根据对应的模块，可以自己建立小任务。
开发完成后，可以把任务指派给测试人员（需要标明备注）。
版本发布问题与规范：
前期(11月10日)每周二、周四发布版本。
后期按迭代发布，两周（半个月）发布一个稳定的小版本。四周（一个月）发布一个大版本。
按模块进行发布，如果当前模块影响范围比较大可以放后面的迭代发布。
紧急bug需要先发开发环境，然后发到外网预发布环境，最后发布到线上正式环境。
后期发布时，取到的分支代码需要打上tag标识用于区分包的版本，例如：版本号_当前日期。
新员工部门培训
对部门人员的认识，新员工对部门产品的一个操作文档。
每周五需要产品部门集体开一个会议介绍产品规划。
业务和产品培训。
组内对新员工的项目培训。
每个组的开发工具和开发文档可以放到共享文件里，便于新员工下载。
员工成长与培训
组内可以定期组织知识分享会议。
分享个人解决问题的处理方案。
部门内定期培训新知识与产品分享。
禅道使用培训。
部门组织代码评审会议。
