ic_spider_data

评审目标

1. 实现方案的正确性
2. 代码的坏味道
3. 规范性

评审日期

2021-12-16

评审人

兰建凌，杨龙斌

被评审人

宋志鹏

参考链接

代码入口

流程

1. 被评审人需先整体描述需要解决的问题、解决流程 （被评审人讲解过程中，评审人可以记录问题，不要打断被评审者的思路）
2. 被评审人讲完，评审人和与会人员可以提问题
3. 评审人进行评审 （被评审者或者与会人员记录评审待改进的内容，有时并不是只针对被评审者，而是所有编码者）
4. 评审完成之后，落实待修改项，主要是缺陷和规范性

描述整体业务逻辑

针对从工商网站或app爬取的工商数据，
先通过check_and_clear模块整体做了校验和清洗，
再通过find_update_doc模块与mongoDB的存量数据的相同主体进行对比，以确认数据的更新或新增。
然后，通过dimensions对数据分16个维度信息分别进行清洗。
最后通过sync分维度入mongoDB库的对应结合，每个维度对应一个或多个集合。

值得学习的地方

1. 业务知识
2. 对于解析的结构比较清晰，处理数据的过程比较明了，易于维护

建议

可以改进的地方
- 文档：增加readme文档；
- 注释：丰富注释，尤其业务逻辑相关的注释；
- 初始化内容：数据库相关的初始化内容可放在init()函数里；
- 一些方法或函数的命名：three_key_elements（获取三要素是否齐全的信息，防止误更新）、worker()工商各维度信息的分发处理；
- find_update_doc 模块的check_same方法：方法太长了，数据处理逻辑可抽离成一个单独的方法；
- find_update_doc模块输出的日志信息的描述准确性。
- 股东的清洗过程太复杂了，是否可以用文档的方式写出解析过程，关键函数写出注释和测试数据
存在的问题
- check_and_clear模块：
  - 93行，若task_result is None，isdigit()报AttributeError；
  - 158行，company_code的处理未起作用；
- 重复代码
  - find_update_doc模块:
  - clean_main_field函数；
  - check_same方法与package_conditions方法；
- 无效代码
  - utils/last_change_date模块：13~14与20~23行，operations，illegals
- data_type类型没用上，没必要过每一个解析
- qy_partner_size与列表数量不一致直接返回？有可能去重之后就相等了，也有可能去重之后变少了。
- 具体到字段清洗的时候还是会受到爬虫结果的影响，是否应该用get的方式将所需值取出，而不是直接认为这个字典就是我需要的
有疑问的地方
- find_update_doc模块181行，业务上能否通过“company_name+address+establish_date”或“company_name+n_company_status+issue_date+lastupdatetime“实现?

改进落实

时间：

改进人：

监督人: