"对于不重要的事情，就当没发生" -- by 我自己
这一个commit的代码，运行起来和上一个commit几乎没有什么不同，但是代码结构发生了比较大的改变。我的编程哲学之一就是不要过早的设计，至少不要在什么都没有的情况下就设计，因为很容易进入只讨论没啥进展的圈子之中。而我个人觉得，在你能糊出一个可以跑的程序之后，你觉得功能上也差不多就这样了，再开始就现有代码进行设计。不仅相当于检查了一遍试卷，而且还可以让你设计的至少更贴近于功能吧。我是一个TDD的绝对支持者，虽然在写这个的时候我没有TDD，无他，因为懒。但是如果给钱，我觉得支持TDD，因为人类对于错误的管理绝对是处于不超过2核的状态，发现不了错误是很正常的，在这个方面，靠程序比人靠谱。
重新设计或者重新构造一下代码第一步我觉得应该是看看代码中重复出现的代码，把这些提取成为函数，这是程序员的基本修养之一。我的几年经验告诉我，重复的代码不会对别人造成麻烦，只会给自己挖下很多坑。
而在这个代码中，重复的最多的就是构造BeautifulSoup类型的代码了。传入header，url，构造BeautifulSoup对象，虽然在后面寻找需要元素的部分略有不同，但是前面几乎没有任何差别，所以这就成为了第一个要变成一个函数的选取对象。另外一个一眼就能看穿的就是处理json字符串的部分了，在代码中，目前只有两个地方要处理json字符串，一个是获取价格，一个是获取好评率。虽然只有两个，但是俗话说有了2次就非常容易有n次，所以这就是我的第二个选择。于是我准备写两个函数GetBSObject和GetJson。函数本身很简单，就是把之前的代码放到一起了，但是提取成函数，你会发现有个很大的便利就是不用再写那么多遍的异常处理了。
前面我说过，异常在爬虫程序这种需要长时间而又要和情况很多的网络相结合的程序中特别的常见。说句站在程序员角度看起来是很吹牛逼的话，你的爬虫程序可能没有bug，但是一定会有异常情况。而如何处理这些异常我觉得挺哲学的，我能想到或者遇到的分这么几种情况。
- 不管，只是由catch块吞掉异常。
- 将异常输出到特定文件中，以后访问。
- 将异常抛出，在最外面的地方一并交给用户处理。
而我，作为一个觉得几粒老鼠屎坏不了一条河的水的支持者，加上人性本懒，果断而又坚决的采取第一种方法。在现代的网络环境中，长时间网络问题几乎不存在，几次没有采集到的数据，对海量数据影响有限。退一万步说，如果出现了长时间的网络异常，或者频繁的网络异常，那么输出到log中的海量数据也不会真的对改善程序有啥帮助。你最大可能会做的，是换个稳定的网络环境。而其余的程序本身逻辑导致的异常，大概率在爬虫程序中会导致数据明显不符合常理，一眼就能看出来。
虽然我嘴上这么说，但是在这两个函数中，一个我采取了输出错误信息到控制台的方法，一个我采用了pass，也就是忽略这个信息的方法。其实我的这个写的并不是很好，比如说在json那个函数中，我使用了finally，也就是无论在什么情况下，都要返回一个结果，哪怕是空字符串。而在后面正式处理的程序中，不得不又采用一个try catch而且貌似还在except中给出了一个疑似错误值的方法。原因是因为，我写到这里忘了考虑这个地方，但是commit已经commit进去了，所以，如果有兴趣的话，可以修改一下这里。
这个一个commit还有一个改动就是我把前几个commit中，在最后遍历字典信息然后输出改成了直接逐行输出，原因我在前面也提到过。对于我们这个程序，没有啥后续数据处理的，采用这种方式会更有交互感。如果你执行前面的程序，你会发现你要过很长时间才有输出，不仅让人怀疑自己的程序到底有没有出错，而且这种长时间没有任何交互的程序实在是不用户友好的典范。而采用简单的print，可以很方便的运用重定向，将输出输出到某个文件中。其实我觉得在没有数据库参与的情况下，这种情况就够用了。
这一个commit在代码上真的没啥可说的，我还是硬扯了那么多，这就是水平不够废话来凑。既然都凑了这么多废话，我想在最后再扯扯我对程序里异常处理的看法。异常是大部分语言中绕不开的话题，但是加入异常处理，至少在最直观上，你会发现代码变复杂了，可读性也差了。更不要说在运行时代码为了异常处理而膨胀的大小了。但是，又有很多人告诉你，在程序代码里不写异常处理貌似不是一个成熟程序员的做法。但是，垃圾的异常处理会吞掉程序的错误，很容易让程序在发生了问题之后根本不知道发生了什么。在C++里这种事情发生的简直就是用家常便饭来形容，所以go语言，没有异常，只有错误，我觉得逻辑上真的挺好。而我一般的做法是，如果这个程序是给别人使用的库，那么我会处理异常然后抛出，这样可以让第三方知道，我的库有问题了。而如果是本身的一个程序，我大多数情况下真的是在发生问题的时候让程序崩掉，毕竟，掩盖问题并不能解决问题，暴露问题才可以。