评审目标
1. 实现方案的正确性
2. 代码的坏味道
3. 规范性
评审日期
2022-04-28
评审人
李子健，刘治强
被评审人
王潘玉
参考链接
流程
1. 被评审人需先整体描述需要解决的问题、解决流程 （被评审人讲解过程中，评审人可以记录问题，不要打断被评审者的思路）
2. 被评审人讲完，评审人和与会人员可以提问题
3. 评审人进行评审 （被评审者或者与会人员记录评审待改进的内容，有时并不是只针对被评审者，而是所有编码者）
4. 评审完成之后，落实待修改项，主要是缺陷和规范性
描述整体业务逻辑
值得学习的地方
1. readme文档比较详细，清晰展示了整个代码逻辑，能完成业务需求
建议
- 可以改进的地方
- 几乎每个函数都使用try，catch捕获异常，是否会忽略由代码本身造成的错误。对于重复带入使用的函数可以用装饰器。
- 不需要那么多yaml文件，功能类似相同的可以放到一起。
- if datas.get('q_r_img_url') is not None 等同于 if datas.get('q_r_img_url')。
- company_wechat_clean模块中的return data多余。
- 配置文件的job_id没改，不方便排查问题。
- wechat_yhc_initial_pic_upload.yml 读mysql没有设置offset，可能导致数据中断。
- 中间表是否需要两个，没有字段冲突能否只使用一个中间表。
- picture_download_result.pic中定义了一些未使用的类如PicPatent，可以删掉。
- 图片下载功能是否有必要单独一个程序（更新mysql表时提交图片下载任务）？
- 图片下载sql reader中下载不到对应图片的任务重复提交，累积提交，占用资源
- 中间表起到的作用是什么（我理解的是保留数据源，为何会在test库下）？
- 是否有必要做中间表（直接读文件是否更好？，且程序意外down后以时间作为offset可能存在数据丢失）？
- 是否有必要做mysql中间表（若只为保留数据源，hive上建对应表load数据进集群）？
改进落实
时间：
2022-04-28
改进人：
王潘玉
监督人:
刘治强
王 潘玉