|
|
## 评审目标
|
|
|
1. 实现方案的正确性
|
|
|
2. 代码的会味道
|
|
|
3. 规范性
|
|
|
|
|
|
### 流程
|
|
|
1. 被评审人需先整体描述需要解决的问题、解决流程 (被评审人讲解过程中,评审人可以记录问题,不要打断被评审者的思路)
|
|
|
2. 被评审人讲完,评审人和与会人员可以提问题
|
|
|
3. 评审人进行评审 (被评审者或者与会人员记录评审待改进的内容,有时并不是只针对被评审者,而是所有编码者)
|
|
|
4. 评审完成之后,落实待修改项,主要是缺陷和规范性
|
|
|
|
|
|
### 代码的坏味道
|
|
|
1. 无效代码
|
|
|
|
|
|
a、321行remain_cnt不会小于0,最小为0,当remain_cnt为0时就没有任务了,此时程序break,337行if语句冗余
|
|
|
|
|
|
b、如果对于剩余任务数非必须知道,319行get_remain_task操作冗余,影响性能,不查询剩余数量,直接get_one_task,然后在337行做判断
|
|
|
|
|
|
2. 重复代码
|
|
|
|
|
|
a、131行和138行功能重复,可以直接全部在131行替换
|
|
|
|
|
|
3. 异常处理
|
|
|
|
|
|
a、所有的sql读写都没有进行异常处理,写sql时 操作应该用try catch包裹起来,出现异常时rollback
|
|
|
|
|
|
b、当出现解析
|
|
|
|
|
|
4. 必要注释
|
|
|
|
|
|
a、很多关键解析部分逻辑复杂,缺少必要注释
|
|
|
|
|
|
5、命名
|
|
|
|
|
|
a、从类名来看不知道这个类的作用
|
|
|
|
|
|
b、get_one_goods函数的作用是解析json 命名不够直抒胸意,可改为parse_goods
|
|
|
|
|
|
c、还有 方法、变量的命名不够直抒胸意
|
|
|
|
|
|
6. bugs
|
|
|
|
|
|
a、读取sql时 拼接 sql语句 有sql注入风险
|
|
|
|
|
|
7. 不足
|
|
|
|
|
|
a、这个类里面多种类型详细的操作 数据库操作、解析操作,这些操作可封装成单独的类,降低代码的耦合度
|
|
|
|
|
|
b、处理并发不够完美,不同进程会拿到相同任务,解决办法使用队列,一个进程写任务,多个进程消费任务
|
|
|
|
|
|
|
|
|
|
|
|
### 规范性
|
|
|
1. 缺少项目文档 (app_environ_protection_grade/readme.md)
|
|
|
2. data_pump配置文件,缺少流程必要注释说明, 缺少profile (方便随时测试、复现)
|
|
|
|
|
|
---
|
|
|
|
|
|
### 改进落实
|
|
|
缺陷:
|
|
|
|
|
|
规范性:
|
|
|
|
|
|
时间:
|
|
|
|
|
|
负责人: |
|
|
\ No newline at end of file |