【程序思考】前后处理这种西瓜

引

一个好的西瓜，可以被分割成小西瓜，具有一定可扩展性，且一眼就能被看出来是西瓜。

一个好程序设计，就是个好西瓜。

文

前后处理的全称是对数据的前处理(也说预处理)，数据处理与数据后处理。

在数据分析的一些领域，这种划分模式很常见。前处理往往是数据清洗，后处理则是转换成想要的形式。

在web中应用中，也很类似，前处理包含SQL取数，筛选，和一些空值处理。

后处理则包含包含两种，一种会修改数据，转换形式，一种不会修改数据，比如监控，日志。


最开始，这种模式工作的很好，产品提了一些新的需求，比如对某个特殊逻辑的监控，新的排序策略，都可以很快的就实现，无侵入(不改变旧代码)，而且是可插拔的(删除无副作用)。

那段时间，跟产品打交道是个很享受的过程。

产品：“这你能把xx情况下的数据埋点出来吗？”
我：“可以，下午就给你搞定。”
产品：“这么快！？我想要xx执行用这种yy策略，好改吗？”
我：“可以，筛选时加个评估器组件就行。挺快就能实现。”
产品：“棒啊，领导还想看这种策略改动后的效果，你能把xx数据yy维度的最大值也记录做对比吗？”
我：“呃。。这里有数据在系统外，拿redis应该可以很快做。。”
产品：“太好了，那接下来还有xxx”
我：“。。。”

后来我再也不敢说xxx能很快实现了。

故事到这里需要转折，我应该要说些我因为这样的模式吃了些苦头。
但很遗憾，这种模式后来工作的也很好，有些同事也用了这种模式。

但是，我感觉有些不太好，用书里的话说是，嗅到了坏代码的味道。

好吧，其实没有那么高级，只是我看同事代码发现有点费劲。当然，他看我代码也觉得有点费劲。虽然我们在互相友好的解释后，都能理解对方的代码。但需要去解释，不就有一点坏西瓜的味道了吗。

难理解的原因是我和同事的任务类型不同，都是定时任务，但我的重点在批量执行，而他的重点在定时执行。在预处理阶段，批量执行的要点是筛选与排序，而定时执行的要点是及时执行与预估下次时间。于是同样是叫预处理，但我和同事的业务逻辑完全不同，甚至线程数都不同。

这里就是问题的关键了，前后处理这种形式，在web业务里，并不具有统一的任务需求。在数据分析中，这种形式是类似的，但在web业务中，就相差很大了。在最初考虑中，我把web业务当成sql取数，清洗数据，处理数据这一过程。但这种抽象模式对于web业务来说太泛泛了，和很多实际需求并不匹配，所以导致了我和同事虽然都叫前处理和后处理，但实际功能差距很大。

所以我们知道了，第一个问题就是不够一目了然。有人也许会反驳说，一目了然是命名的问题，你在给类命名时加上相应的业务描述词不就好了吗？比如排序预处理、筛选预处理。确实，命名一定程度上可以改善代码可读性。但是关键问题不在于文字与作用匹配，而在于结构与业务需求匹配。就像写高考作文，一个错别字固然不好，但跑题了才是最致命的。一个西瓜被写成了西爪不致命，但被写成西红柿就不太合适了。

为了进一步说明业务需求与前后处理的不匹配问题，这里我想给我找个对方辩手，就是当时写这个程序的我。我当时把它分成前中后处理的另一个理由，是因为它们的执行速度要求不一致，在实现上，不走同一个线程。预处理sql拉到的数扔在队列之中，处理和后处理从队列取数去执行。预处理要很快的执行，处理和后处理要慢慢的执行，所以就如此拆分了。

听上去没什么问题啊，排序和筛选要求快，实际处理要求慢，正适合分成预处理和后处理。但这存在一个目标倒置的问题，我们不再是根据业务需求去进行抽象，而是根据代码技术实现去进行抽象。就像一个西瓜，你可以做成西瓜汁，也可以做成西瓜沙拉，还可以做成糖醋西瓜。顾客想要西瓜汁，然后你跟顾客说“不行，榨汁机坏了，沙拉太麻烦了，你只能吃糖醋西瓜了。”，唰的把糖醋西瓜塞他嘴里了。

上面说的有点夸张了，需求导向和技术导向其实更多时候是个取舍问题。毕竟没有实际的代码实现，东西都做不出来。“我快渴死了，能给我杯西瓜汁吗？什么！？只有糖醋西瓜，好吧，好吧。”

前后处理是一个方便的技术选择，很快就能代码实现，而且具备一定的扩展性，十分的优秀。尤其是在产品自己都搞不清会有怎样的扩展需求和变动时，然后又急匆匆的让你赶紧把功能实现了。没时间讨论需求，没时间设计结构，没时间去学榨汁机怎么用。这时候，这种模式无疑是个合适的选择。

“把西瓜丢进去按下开关就可以了？什么？机器炸了？文档上没说要给西瓜去皮啊！”

就像全局变量有时候是个无敌的解决方案。

技术选型要更多考虑因素。我在学校时给教研室师兄写过C语言的小车控制程序，当时用宏函数实现过一个观察者模式。如果你想用某个传感器，你只需要把这个传感器的c文件拷贝进去然后include就行，如果你想使用传感器的数据，你就注册一个对该传感器的观察者就行。但后来，在师兄的抗议下，我全部改成了全局变量。嘛，至少最后程序工作的也挺好。

南方的豆腐脑是甜的，北方的豆腐脑是咸的。所以说不定糖醋西瓜在某些地方也很有卖点哦。

但衡量技术的好坏，标准就是需求。

就像我师兄，他不需要优雅，只需要全局变量。

回到前后处理这一块，它在数据分析上，是个很不错的方式。很多预处理还有通用性，比如清洗或者填数，而且是那个领域比较常见的模式，别人一看就懂。

但在web业务中，并不一定合适，首先，就是身边的人并不经常这么用，会给他们阅读代码带来一些麻烦。更重要的是，它隐藏了业务特征，没有了明显的主次。

好用，但是不够好。

最后我想说，写代码一个很有趣的地方就是去设计。

很多时候我们都是凭借经验去设计，因为经验最安全。但有的时候，根据需求特征，在保证产品的前提下，去尝试一些新的设计模式，可能会更加有趣，顺利的话产品还能更好。虽然这并不见得能让你工资上涨，而且可能会耗费你更多时间做个无用功。但是能拓展你的思路，这次不行的方案下次另一个场景可能就合适了，你的经验会扩展，读源码会更清晰。读源码或是读技术博客不是为了单纯去读懂它好用它，而是会借助它的设计思路，想着把它放自己那项目上好不好用。吃别人家西瓜时，把瓜子也偷了，留了自己搞，岂不美哉。