code-review/qcc融合.md

+## 评审目标
+
+```buildoutcfg
+1. 实现方案的正确性
+2. 代码的坏味道
+3. 规范性
+```
+
+### 评审日期
+
+```
+2021-01-20
+```
+
+### 评审人
+
+```
+李子健，刘治强
+```
+
+### 被评审人
+
+```
+王鹏举
+```
+
+### 参考链接
+
+- [代码入口](http://192.168.109.110/granite/project-gravel/-/tree/develop_equity_penetration_cleaning/app_equity_penetration/udms/qcc_clean_v2)
+
+### 流程
+
+```buildoutcfg
+1. 被评审人需先整体描述需要解决的问题、解决流程 （被评审人讲解过程中，评审人可以记录问题，不要打断被评审者的思路）
+2. 被评审人讲完，评审人和与会人员可以提问题
+3. 评审人进行评审 （被评审者或者与会人员记录评审待改进的内容，有时并不是只针对被评审者，而是所有编码者）
+4. 评审完成之后，落实待修改项，主要是缺陷和规范性
+```
+
+### 描述整体业务逻辑
+```buildoutcfg
+针对从qcc爬取的数据，
+先通过check_and_clear模块整体做了校验和清洗，
+再通过find_update_doc模块与mongoDB的存量数据的相同主体进行对比，以确认数据的更新或新增。
+然后，通过dimensions对数据分16个维度信息分别进行清洗。
+最后通过sync分维度入mongoDB库的对应结合，每个维度对应一个或多个集合。
+```
+
+### 值得学习的地方
+
+```buildoutcfg
+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“实现?
+      
+  
+---
+
+### 改进落实
+
+```buildoutcfg
+时间：
+
+改进人：
+
+监督人:
+```
\ No newline at end of file