(拟)研发中心软件设计流程与规范
-
需求分析规划整理
- 后端需参与，以便确认用户的第一需求
有时候一个简单的需求经过多方传递之后，会失真，导致多花力气。
- 后端需参与，以便确认用户的第一需求
-
版面设计（内部初审&用户终审）
-
建模&mockAPI（推荐EoLinker）[1]
-
建模至关重要，无论是前端还是后端亦或是数据，没有建模或者不合理的建模会影响整个团队的开发效率
- 数据库建模（此模式适用于多后端开发） 如图：
- 数据库建模让开发不再纠结于字段定义
- 数据库建模让开发不再纠结于字段定义
- 实体类建模（此模式通用于各种开发，简单高效快速，适合敏捷和迭代）
通过代码生成器构建一套后端代码，同时生成数据库，支持导出数据库到EoLinker或Doc文档
- 数据库建模（此模式适用于多后端开发） 如图：
-
mockAPI——连接前后端开发的桥梁，真正把前后端从各自的自测中解放出来，提高沟通效率。
mockAPI不仅定义了前端请求URL，而且也定义了后端的模块分组、功能分组等，方面快速构建团队生产体系和前后端的生产目标
-
-
任务规划
将软件研发的工作拆分，利用甘特、燃尽或其他的辅助工具管理软件的研发周期，方便及时的对项目状态进行调整
- 思维导图让参与者快速了解项目
- 任务管理让开发者了解项目的开发节点，合理安排自己的时间
- 思维导图让参与者快速了解项目
-
代码框架选型&代码编写
- JavaDoc MVC极速开发模板JavaDoc
- 代码规范（基础）
- 命名规范
- 数据库
- 表名、字段名称使用全小写蛇形命名
- Java
- 包名、字段名、方法名使用小驼峰命名
- class interface enum等使用大驼峰命名
- 基本常量请封装到interface中使用全大写蛇形命名，避免使用static
- 组合常量请封装到enum中使用全大写蛇形命名
- 数据库
- MVC的分层规范
- controller只负责页面跳转和数据传递，尽可能不要把过多的业务逻辑掺杂至此
- service是具体业务逻辑，由controller调用执行具体逻辑（数据库各种操作的有机结合）
- dao是数据库操作的抽响映射，不做赘述
- 注释规范
请参照JavaDoc协议规范，对于重要的逻辑部分和功能务必做到行行注释，以确保此项目任何人可接手。关于JavaDoc规范，请参看上述模板，此模版也是急速开发模版，足够精简。
- 命名规范
-
前后端联合开发标准化规范样例
HTTP_API
- url
- /模块名称/功能名称/操作名称
- 请求方式
- Rest风格
- 查询操作GET方法，URL传参
- 添加操作POST方法，JSON传参
- 删除操作DELETE方法，url传参
- 修改操作PUT方法，JSON传参
- 简易风格（推荐使用）
- 查询删除操作GET方法，URL传参
- 保存修改操作POST方法，JSON传参
- Rest风格
- 请求头
- Access-Token: 单点登录认证
- 请求体
- 参看请求方式
- 利用工具构建统一的请求格式
- 响应头
- 暂无
- 响应体
- JSON格式
- 利用工具构建统一的请求格式
以此规范为前后端开发的标准，前后端开发只需要对接此文档即可
- 详情参看 [1]
- url
-
构建一体化的测试环境
- 根据项目的具体情况可以针对不同等级的业务做不同的测试
- 单元测试、白盒测试
- 黑盒测试、集成测试（必要）
- 对拍测试（健壮性稳定性测试）
- 后端测试功能
- 前后联测
- 后端API快速测试 详情参看 [[1]][[1]]
- 根据项目的具体情况可以针对不同等级的业务做不同的测试
-
代码管理、版本控制与发布（推荐Git）
- 多人协作开发
- 分支管理模式
- 任何人不允许在主分支上开发
- 各自维护各自分支
- 功能代码合并请PULL REQUEST
- review审核模式
- 在分支上提交的代码需要有人审核通过之后才能进入分支
- 代码审核
- 测试审核
- 在分支上提交的代码需要有人审核通过之后才能进入分支
- 分支管理模式
- 代码注释习惯
- 可参考标准JavaDoc
- 关键业务逻辑行行注释
- 多人协作开发
