编程内功：业务逻辑抽象

用代码量衡量程序员的工作量大抵是世上最愚蠢的事了。

今天重构了一段年代久远的大约2000行的代码，目前剩下200行左右，这段代码的功用大致是这样的：

将一些数据，按照几个维度的规则填充到另一个表里面，数据和表里的数据可能是一对多的情况。

事例

规则有3个维度：一个优先级性质，数据类型，规则层次

老代码是如何组织的？

三个维度的规则下穷举所有情况，我看了一下数据库操作次数等性能层面较优秀，但可读性和维护性实在是差。

新的代码是如何组织的？

仔细看三个维度其实其中优先级性质，规则层次这两个用来负责校验这条数据是否要插入到表里，数据类型确定插入哪些字段，这样代码就分为两个部分，首先判断是否要插入，然后根据情况做数据的插入动作。

这样就较完美的达成了代码的小模块内的重用，并且能够较好的自解释其运行逻辑。

所以我们之后在实现一个feature之前是否会有一个以上的方案，是否会从性能，可读性等方面在心中比较每个方案的优缺点在动手实现呢？