第13章 重构和优化

随着代码量的增加，软件系统的复杂程度会逐渐增加，从而导致软件系统的混乱程度（熵）增加。一旦软件系统混乱到一定程度，这个系统就会失控，难以修改和维护。这是软件开发中的熵增加定理。

原则上讲，一个软件系统应该是边开发边重构的。但是由于一些客观或主观原因，可能会出现“先实现功能再来重构”的情况。例如本书第10~12章所开发出来的问答系统，就属于这种情况。因此，本章将讲到如何对操作数据库的代码进行重构和优化，从而使得代码更加容易阅读和维护。



13.1  划分代码层次


13.1.1  寻找问题


1．寻找MongoUtil的问题

在前几章的代码中，所有操作MongoDB的代码都在MongoUtil.py文件中，所有操作Redis的代码都在RedisUtil.py文件中。但是在代码中，操作数据库的代码和部分业务代码杂糅在了一起，如图13-1所示。

在图13-1方框框住的两个方法——insert_answe（r  插入回答）和insert_question（插入问题）。这两个方法不应该属于MongoUtil.py。因为MongoUtil应该作为一个工具类，它在插入数据时，不需要关心插入的数据里有什么内容。而现在这两个方法，不仅写在了MongoUtil中，而且竟然还能知道“问题”的字段有  title、detail、author  和  ask_time。这就像一个快递员竟然知道他送的快递里面装了什么东西。显然这是不合理的。

2．寻找RedisUtil的问题

RedisUtil  的问题，除了操作数据的逻辑和业务逻辑杂糅外，还有  Key  直接写在了代码里，如图13-2所示。

图13-1  操作数据库的代码与业务代码杂糅

图13-2  Redis  Key直接写在代码里面

这种写法，在程序开发中的术语叫作“Hard  Code”。把Key写在操作Redis的类里面，就像快递上面不写地址，而快递员的脑袋里面却知道每个快递是送到什么地方的，这也是不合理的。



13.1.2  如何重构


一个合理的数据库操作模块，不需要知道具体的业务逻辑是什么。MongoDB的插入操作就只需要往MongoDB中添加数据而不需关心“添加的是什么数据”“具体有哪些字段”。在Redis操作Key时，具体要操作哪个Key，应该是从外面传进来，而不是直接写在模块里。因此，首先要实现真正的、纯粹的数据库操作模块。

1．重构MongoDB操作模块

原有的  MongoUtil.py  将会被拆分为  MongoLogic.py  和  MongoUtil.py。拆分后，  MongoLogic.py  保留原来的业务逻辑；MongoUtil.py只负责数据库操作相关的事项，不处理任何具体业务逻辑。

重构以后MongoUtil.py的代码如图13-3所示。

图13-3  重构以后的MongoUtil.py

2．重构Redis操作模块

原有的RedisUtil.py将会被拆分为RedisLogic.py和RedisUtil.py。拆分后，RedisLogic.py保留原来的业务逻辑；RedisUtil.py只负责Redis操作相关的事项，不处理任何具体业务逻辑。

重构以后RedisUtil.py的代码如图13-4所示。

图13-4  重构以后的RedisUtil.py的代码

3．重构其他部分的代码

问答网站其他地方的代码也需要做相应的重构，但由于和MongoDB及Redis的关系不大，因此本书略去。感兴趣的读者可以阅读本章对应的网站源代码。