GitLab

评审目标

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

评审日期

2022-04-21

评审人

蒋家升，杨龙斌

被评审人

刘东洋

参考链接

• 代码入口

流程

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

描述整体业务逻辑

建议

jjs_advise

---

值得学习的地方

1. 为团队引入了基于aiohttp，协程的异步爬虫框架，相比scrapy消耗资源更少，扩展性更好。但是文档相对较少，解决问题和入门的成本有增加。
2. `SpiderRequest`类对(POST,GET)请求做了封装。
3. 解析部分做的很统一,`Manger`里面注册了`parser_register`,由选择器和解析器共同组成,基于`jsonpath`和`xpath`的解析,解析的方法一目了然，并且具有良好的扩展性
3. 类的定义很清晰，多个爬虫之间的隔离很明确，整体结构已读，但是调用流程嵌套太多

建议

• main.py程序入口

  • 入口部分主要解析的命令行参数，然后启动一个爬虫实例，可以尝试用click代替这部分，更为直观
  • 目前一个命令行只能启动一个爬虫，如果爬虫数量多是否难以维护。

• 任务相关的一些问题

  • Manager.run 任务失败后会重新将任务放到redis,直到redis为空才会结束任务。
  • 失败后应记录下失败原因，失败的次数要有限制。

• 关于这个爬虫框架相关的建议

  • 可复用性不好，假设我要用这个框架来开发新的项目，我希望只写，获取任务的方法，请求方法，解析放法，以及他们的回调关系，并且定义这些的地方不要太分散
  • 希望异步的请求可以跟业务相关的编码分开，就是编码的最好是同步的，可以通过代码很清晰的读出流程，不要有太多和太多次的方法的传递。run_func,parser_func
  • 多定义一些变量，少一些函数的参数传递
  • 与团队现有的流程可以进行一定程度的融合，并且解析部分其实很容易出错的，这个框架也没看到一个定义期望结果和检验结果的模块

改进落实

时间：

改进人：

监督人: