意见反馈与建议

后端/前端问题与规范：

1. 进行需求评审，设计确定底层架构。
2. 目前缺少内部架构设计，需补充开发架构文档
3. 功能设计：目前对功能模块的描述较少，加大沟通成本。
4. 对应开发对接需求方，开发需对功能进行理解并简单设计，还需对数据库进行设计，内部进行简单的评审，在开发阶段调试过程，遇到需求变更，积极应对沟通。对需求进行合理的沟通，如较重大的模块可合理延期至下期实现。
5. 开发自测：在发布到测试环境前，开发需对模块进行单元测试，测试提供一份用例给予开发，标注优先级。未通过自测用例不允许发布到测试环境。
6. 定义API文档，先确定文档字段。
7. 补充异常常用状态码，异常状态时抛出提示。
8. 数据库只增加不允许删除，数据库补充字段备注意义，表名，表里的字段（使用下划线进行连接）， 数据库屏蔽删除的功能，用0/1代替
9. APP版本缺少标识：开发/测试，区分环境
10. 由钟含勇（后端）、陈晓晴（前端）对代码进行审核，发现问题截图发布到钉钉群指给相应的开发人员。
11. 自动化更新数据库。
12. SQL语句脚本根据版本号进行自动化对比。
13. 前端和产品设计沟通问题。

git代码commit具体内容执行：

1. 提交前的comment内容需要按第2点里指定格式。
2. 例如: 【修改原因】视频上传失败问题 【修改内容】注释image校验 【修改人】钟含勇 【检查人】钟含勇
3. 新需求和bug修复，前台、后台代码可以自己从其他分支合入到develop开发分支。
4. 先从feature_dev_v1.0分支拉取最新代码到本地开发分支，然后创建一个自己的分支，把代码提交到自己分支上。最后创建合并请求基准分支选择feature_dev_v1.0预发布分支，对比分支选择自己创建的分支。
5. 在对应的项目里创建合并请求后，前端提交合并请求后指派给xqchen，后端提交合并请求后指派给zhonghanyong。
6. develop开发分支的代码会更新到开发环境上。
7. 代码合入feature_dev_v1.0预发布分支会更新到外网预发布测试环境上。
8. 确保feature_dev_v1.0预发布分支的代码没问题后，发布到正式环境前会把feature_dev_v1.0预发布分支的代码全量合入到master主干分支。
9. 后端代码规范问题：IDEA里可以安装sonarLint插件用于扫描本地静态bug，安装Alibaba Guidance编码规约插件，规范代码格式，每周进行一次代码评审。
10. 前端代码规范问题：Hbuilder X里需要安装ESLint插件用于检测编码规约，规范代码格式，每周进行一次代码评审。

需产品/项目协助问题：

1. 产品补充需求文档：开发与测试时需要详细的需求文档进行辅助开发测试，文档要求细化，明确文档的流程。 如：文档更改记录，文档及时性。
2. 提前进行需求评审，产品讲解需求，开发测试进行理解，沟通进行沟通分析实现难度。
3. 需求整改需合理进行：判断合理的时间范围，需求优先级，已开发的功能增加需求需要合理的进行分期和排期
4. 禅道规范：功能节点细化需求增加记录到禅道。
5. 整理出分工表，细化模块标注对应的前后端测试负责人。
6. 根据需求内容合理排期上线时间，与开发/测试确认需要耗费的工作日周期后再决定上线的时间，合理安排工作。
7. 需求变更：需求变更需通知相应的开发测试人员，并更新需求文档。

测试问题与规范：

禅道规范问题：

1. 测试将bug提交到禅道：标注路径，细化描述，定位问题。
2. 未解决的问题，bug解决最迟三天内修复回复，未修复问题给予合理解释，比较重大的问题可进行延期，且通知到相应人员。
3. 功能上线后，将本期的测试用例发布到禅道保存。
4. 测试编写完成测试用例后，需与相关人员，产品等进行简单的用例评审，如用例不通过，后续进行修改再与产品核对。
5. 开发需提供API文档给予测试人员，需让测试了解开发设计。
6. 涉及支付相关的模块，在正式环境需要进行一个支付相关的测试，需要和财务、运营人员沟通。

运维问题与规范：

1. 数据库不同步会导致线上数据错误，需要后端与运维确定定义工具（最好是自动化的）
2. 线上发布问题： 包含版本需求，需前后端负责人签字。
3. 回滚机制（需运维确认），设置权重。
4. 防火墙不必要的端口不进行开放， 控制并发量，对特定的IP进行封杀，从白名单到黑名单进行封杀。
5. Jenkins持续化构建集成。
6. 禅道与钉钉、邮箱打通消息通知。
7. 代码监控日志推送。
8. 数据库里后期要屏蔽delete操作语句。
9. 全局错误、异常需要通过邮箱、钉钉通知到对应的功能负责人。
10. 前期替换补丁包前需要做好上个版本的包备份。

项目经理问题与规范：

1. 更新版本发布，需要确认单，需要版本对应的负责人签名
2. SQL脚本执行，需要确认签字。
3. 数据库备份机制（异地备份）。
4. 代码回滚机制。（线程核心数对比）
5. 灰度发布机制。
6. 每天下午六点每个小组可以组织组内成员开一个小例会（简单沟通一下）。
7. 后期需要落实bug问题修复复盘工作。

禅道任务分配规范：

1. 按模块分配后，需要找到到对应的产品负责人确认。
2. 根据和产品的沟通记录，把详细内容记录到禅道上。
3. 根据对应的模块，可以自己建立小任务。
4. 开发完成后，可以把任务指派给测试人员（需要标明备注）。

版本发布问题与规范：

1. 前期(11月10日)每周二、周四发布版本。
2. 后期按迭代发布，两周（半个月）发布一个稳定的小版本。四周（一个月）发布一个大版本。
3. 按模块进行发布，如果当前模块影响范围比较大可以放后面的迭代发布。
4. 紧急bug需要先发开发环境，然后发到外网预发布环境，最后发布到线上正式环境。
5. 后期发布时，取到的分支代码需要打上tag标识用于区分包的版本，例如：版本号_当前日期。

新员工部门培训

1. 对部门人员的认识，新员工对部门产品的一个操作文档。
2. 每周五需要产品部门集体开一个会议介绍产品规划。
3. 业务和产品培训。
4. 组内对新员工的项目培训。
5. 每个组的开发工具和开发文档可以放到共享文件里，便于新员工下载。
6. 更多可以参考：http://www.devhost.work 。

员工成长与培训

1. 组内可以定期组织知识分享会议。
2. 分享个人解决问题的处理方案。
3. 部门内定期培训新知识与产品分享。
4. 禅道使用培训。
5. 部门组织代码评审会议。