实习日记 2015年1月19日（重构之路）

实习日记

今天为了优化日志记录系统，重构了公司后台的代码。

公司的商品有如下状态：

• 待审查 新获取的商品的状态。
• 入库 待审查或淘汰的商品可以被入库。
• 淘汰 待审查或入库后未被选为精品的商品可以被淘汰。
• 精品 入库的商品可以被选入精品库，同时会添加推荐语。

简要讲一下涉及到的三个数据库映射类：

• 商品类映射了数据库中的商品记录，在获取到商品时即会新建记录，同时设置状态为待审查。
• 库管类是为后台管理而产生的，在商品被审查时（入库或淘汰）会新建（因为商品只是待审查的话就没有库管记录）或更新记录，其中同时还记录有审核人员的信息。
• 精品类记录了商品、推荐语及其撰写人等信息，用于推荐入精品库时做记录。

原本代码逻辑如下：

• 入库、淘汰两个操作调用了商品类自身的方法来修改状态，并在库管类里做记录。
• 选入精品库因为涉及到推荐语等，直接调用了精品类的类方法新建一个精品类，同时直接修改商品的状态

现在改为如下逻辑：

• 首先重写商品类自身的修改状态的方法，使其不再只对库管类服务。
• 在库管类中新加入create_or_update方法，新建或更新库管记录时调用商品类修改状态的方法。
• 修改精品类的update方法和create方法，不再强制修改状态，而是调用商品类修改状态的方法。

该重构优点如下：
1. 修改状态统一都会调用商品类的方法，便于日志记录。
2. 因为产生状态变更的根源不再是商品类本身的方法，所以可以分操作类型来判断获取到的新状态是否合法，降低数据出错率（比如过去可以直接从待审核变成精品）。
3. 商品类的设置状态方法具有高度的可复用性，为以后的新功能做出了准备。