规划办项目，根据书目爬取上述三个网站的相关数据，包括cnki分年度引用，论文类型，三大电商网站的评论数、评分，cnki学术评价和报纸评价数据。

此外本项目还有部分对原始数据的统计代码，刚刚开了个头。

代码写的比较随意，没什么注释。虽然今年重构了一次，但是耦合性还是很强的。

今年做这个项目的时候，大概理清了一个基本流程。这个是爬取流程：

1.标题、作者名格式化
2.拉取线上数据
3.匹配主、备标题作者
4.写表
5.人工核对数据准确性

主要是首先对标题名、作者名进行格式化，包括中英文标点转换，标题名称对冒号、双横线等进行截断，这个做法是为了保证爬虫的查全率。

对于一些实在奇葩的情况，采取在查询条件所在的excel表格里加入备用书名、备用作者名进行二次查询。这个需要一些人工处理，保留一个合适的备用标题。

通过以上两个方法，查准方面，目前在豆瓣，前300条（条数完全是感觉）的正确率几乎达到100%了，总体感觉在90%以上。

但是要注意到的是，需求方给的书名很有可能是不准的，甚至几乎一个字都不对。所以一定需要人工核对。今年来看，当当几乎所有的新书都能搜到，适用于核对。

资源文件是放在resources目录下的，但是因为这些文件不适宜上传，所以全部留在本地了。这个文件夹也没有上传。

爬虫的控制台输出可以作为log来进行核对时候的参考。我觉得这个设计有点机智，专门写个log文件，感觉有点大材小用。

具体的业务细节，如果真的有人会用这个爬虫直接问我就好了。

自己一个人做工程是有感想要说的。

####技术是解决问题的工具。

第一年写这个爬虫的时候，花的时间完全可以手动把所有数据搞完了，但是第二年明显感受到了自动化的好处。

####技术本身也会成为问题。

第一年写的代码，耦合就不用说了。

解决问题优先，大量重复逻辑
那时候还不知道Jsoup，很多用的正则，效果比较差
文件都是绝对路径，excel操作写死行列参数
主函数堆在一起，靠注释区分调用

今年其实花了一半时间来优化工程上的问题，比如分拆工具方法出来，加了一些注释，分拆主函数（以前都是写在一起，不用就注释掉的，以至于很多函数看不到调用位置被我误删），加单元测试等等。

伴随而来的剩下一半时间则是业务上的改进，比如花了很多时间在豆瓣爬虫上，优化查询方案，提高查准率。其实前边说的工程上的分拆都是从业务优化上来的。

####工具的使用是一门学问

就像刚才说的，技术本身成为问题，怎么解决技术问题就是一门学问了。在腾讯做前端的时候，见到大厂的工程代码，结构良好，并且做需求的时候要求尽量不留坑。与之对应的是那边的老代码，写的简直惨不忍睹，大概也是我这个原因，功能优先。

以前写代码都是为了写代码而写，意思是人家提需求，我来写，并且框架都有了，我只关注代码风格上一致的问题，只关注业务代码的细节问题。这一次是自己根据需求，写代码来简化工作，这种预先没有宏大的架构，没有良好的可扩展性预留，仅仅试探性的起步，按需的优化，对于理解软件工程的一些必然性是很有一些意义的。

一个好的工程师，应该是即便功能优先，即便有再多的即便，代码应该还是易懂的，可维护的。今年维护这个工程，最大的一个感悟其实是，要立即优化代码。人月神话里说不要提前优化代码，这一点前段时间在腾讯是有感悟的。但是立即优化这块，怎么说呢，反而不是什么高级**，只能说是一些感慨。维护工具是要浪费解决问题的时间的，但是工具良好的情况下，对未来的工作是有提升意义的。同时，我相信没有一个程序员会在完成工作之后，再重构代码。所以能够看到优化点及时优化，掌握工具维护和解决问题的平衡点，才是一个好的程序员的作风。

我相信这种解决问题的代码，必然是下一次做才会优化上一次的代码，所以可能要多次使用慢慢完善。下一步主要是生成各种报表的功能，这块对人工工作量的优化在一天左右，但是由于这一天一半都是最后一天，所以价值不小（血泪经验）。

期待它会变得更好。

联系方式 [email protected]