开发流程
一、原型评审流程
1. 初步审核（初审）
原型一出来，项目组就尽快安排初审。
前端、后端、测试都得参与，大家一起看看有没有逻辑漏洞、漏的场景、或者实现难度大的地方。
把问题集中列出来，反馈给原型设计的人。
2. 细化审核（细审）
原型根据初审意见改完后，立马再来一轮细审。
建议初审和细审最多隔两天，别拖，拖久了谁都忘了问题在哪儿。
细审通过后，原型就“锁死”了，开发就按这个走。
二、开发排期和估时
1. 统计口径：按小时来
所有任务估时一律按 小时 来算，别再写“几天”，太虚。
每个人每天工作时间按 8 小时算，方便统筹安排。
排期时不求绝对精确，但希望大家对自己的节奏有个数。
2. 排期怎么排
原型定下来之后，由项目经理/负责人牵头排期。
每个接口/功能要明确：
谁做的
大概要多久（小时）
要不要联调
📋 示例排期表
三、开发流程和习惯
1. 开始前
原型和业务先推理清楚，别拍脑袋上来就写。
有问题就说，问题可以早说，但不能事后才提。
项目过程中任何问题都欢迎提，但请尽量在前期或中期说清楚，别等上线才“突然想起来”。
2. 编码中
代码写清楚点、注释加上、规范遵守一下，别人也要看你代码。
有依赖的地方要提前沟通，别临上线才说“等别人接口”。
3. 提交前
提交 Git 之前请自测完：
正常流程 OK
异常场景 OK
边界值 OK
自测通过之后再发起合并请求，最好顺手贴一下测试截图。
四、工作节奏和时间管理
项目是按“周”为单位来推进的。
每周更新一下任务进度，形式可以灵活：
完成了啥
还差什么
哪块卡住了
没做完的，自己安排时间补上，别一拖拖一周。
排期和复盘统一用小时来统计，直观也好复查。
五、我们想要的氛围
不希望流程让人觉得“被管着”，所以我们更在意这几件事：
话要说在前头：提前说问题，大家才有时间处理
协作要坦诚：遇到难点直接讲，没人会因为你问问题而看轻你
氛围要松弛：认真做事，不代表压抑做事
希望大家在项目里不仅交付结果，也能有好体验。流程只是基础，我们靠的是配合。
切忌：业务梳理好再做排期和开发，不要拿到原型就写代码！！！
业务梳理到什么程度才开工？
理解业务需求，要做的是什么功能，要写什么接口。这需要一些理解，根据个人水平可以不特别细致但要做的功能要明确
需求中涉及到的表结构和字段，有什么调整或要新建什么表，要十分明确！
每个功能的逻辑：可以写伪代码梳理，可以提前建好请求响应封装类来梳理。要十分明确前端传什么数据过来，我们返回什么数据，根据原型图设置来初步确定。
在第三步中，如果有无法闭环的逻辑和不合理的设定，先和产品沟通，务必清晰整个逻辑。
提问产品/leader 的时候，总结每个模块的问题结合原型贴图/具体的问题【例如：代码的某一段/某个环节】，具体的指出哪个地方不懂
看原型-->熟悉业务逻辑-->思考需要建或修改什么表，有哪些字段-->写接口，制定请求响应封装类-->看逻辑能否闭环-->总结好问题问产品（先问产品，再问同事或leader）-->排期写代码
代码规范
1.1 避免单条sql语句循环 ： 批量查询在仓储层中sql实现，不能在业务逻辑中循环单条sql。
避免三张表以上的联合查询，分成多个sql执行
dal: 和数据库表对应的实体，严格使用do操作数据库【**增/改/删**】，实体entity和dto直接用于查询sql
1.2 判断空值规范使用函数，CollectionUtils.isEmpty()
1.3 避免模糊匹配 LIKE %X，尽量少用select * （给出具体字段有助于业务理解，也能提高性能，具体问题具体分析）
1.4 接口添加注释，方法按功能命名（例：getXXXByXXX）;service和repo层添加方法注释，对应的接口可以省略
1.5 增删改【操作数据库的行为】 用DO对象，查询等不涉及数据库字段值更改的用实体entity
1.6 类型转换entity-->do在仓储层做，service层只处理逻辑