code-review/ic_info_change.md

@@ -14,64 +14,49 @@
 4. 评审完成之后，落实待修改项，主要是缺陷和规范性
 ```
 
-### 整体感知
-```buildoutcfg
-1. 代码干净、简洁,好评
-2. 文档不全,不适合新手自主上手,一脸懵逼
-```
-
 ### 值得学习的地方
 ```buildoutcfg
-1. 
+1. 代码层次比较分明、每个方法具体做什么，比较清楚。
+2. 每个文件代码没有超过150行，每个方法代码量也没有过于冗长。
+3. start_requestss直接留了一个测试入口，处理方便。
 
 ```
 
-
 ### 代码的坏味道
 ```buildoutcfg  
-1. 无效代码
-
-   a、321行remain_cnt不会小于0，最小为0，当remain_cnt为0时就没有任务了，此时程序break，337行if语句冗余
-   
-   b、如果对于剩余任务数非必须知道，319行get_remain_task操作冗余，影响性能，不查询剩余数量，直接get_one_task，然后在337行做判断
-   
-   c、113行update_time后续没有用到不需要处理
-2. 重复代码
-
-   a、131行和138行功能重复，可以直接全部在131行替换
-   
-3. 异常处理
+1. 必要注释
 
-   a、所有的sql读写都没有进行异常处理，写sql时 操作应该用try catch包裹起来，出现异常时rollback
+   a、ChangeRequest请求，我以为是某一个维度，实际上是获取请求需要的一个关键参数
    
-4. 必要注释
+2、命名
+   a、ic_pc.py format_task_params  全是task_params
+   b、ic_pc.py init_task_result_mgr mgr可以写成manager, 两个Task为什么不连在一起写?
    
-   a、很多关键解析部分逻辑复杂，缺少必要注释
   
-5、命名
+3、存在疑问
+   a、index.py文件  yield from、return、yield   
+   b、太多if else 判断就显得代码特别乱， 是否可以抽取出方法处理。
+   c、detail_url.py parse_response方法, 2个yield,1个return
    
-   a、ic_pc.py 42行 format_task_params  全是task_params
+8. 不足
 
-   b、get_one_goods函数的作用是解析json 命名不够直抒胸意，可改为parse_goods
+   a、is_need_retry,方法整体上应该有一个返回
    
-   c、还有很多方法、变量的命名不够直抒胸意
+   b、items.py文件接近1000行代码了。
    
-6. bugs
+   c、single_request.py parse_response 响应正常，抽取成一个方法。 new_request里面可以抽取成2~3个方法
    
-   a、读取sql时 拼接 sql语句  有sql注入风险
+   d、添加readme.md,整体说明爬虫目的，快速启动以及部署等。
    
-7. 不足
+   e、pip freeze > requirements.txt   导出当前环境依赖包
    
-   a、这个类里面多种类型详细的操作  数据库操作、解析操作，这些操作可封装成单独的类，降低代码的耦合度 
+   f、index.py parse_response 顺序不太合理
    
-   b、处理并发不够完美，不同进程会拿到相同任务，解决办法使用队列，一个进程写任务，多个进程消费任务
 
 ```
 
 ### 规范性
 ```
-建议: <1>添加readme.md,整体说明爬虫目的，快速启动以及部署等。
-     <2>pip freeze > requirements.txt   导出当前环境依赖包
 ```
 
 ---