GitLab

评审目标

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数据进集群）？

改进落实

时间：

改进人：

监督人: