上层决定还是下层决定, 这是一个哲学选择

在产品的开发中, 从来不会是只有一种逻辑结构的helloword形式的程序, 总是会发生一些复合型的逻辑结构, 并且结构的交错非常严重. 比如, 在我们的产品中需要轮询对一批数据进行更新, 全部更新完成再根据从服务端得到的所有更新结果进行界面的刷新. 这其实是个非常简单的逻辑, 但确实已经产生了一定的逻辑交错了. 比如轮询的过程一定是回调的, 那么这个回调本身会破坏整体的逻辑, 如果我们需要这个轮询工作按照次序进行, 那它的逻辑设计就相对比较复杂了.
为了解决这种问题, 我们引入了另外一个问题, 那就是逻辑的决策层是谁, 是由上层选择还是下层选择, 所谓上层选择, 就是封装尽可能简单, 然后到最后一层的时候, 将主要逻辑实现. 下层选择, 那就是小功能尽可能的包含足够完备的逻辑, 到了最后一层的时候, 几乎就是简单的顺序调用就解决问题.
这两种选择, 其实是一个哲学问题, 包括在社会环境下就有这样的问题, 那就是足够复杂的判断, 由民众选择, 还是由精英选择, 一般上, 由民众选择就是民众自己对当前环境下的逻辑判断的足够准确, 然后将信息汇报给决策层, 再由决策层执行, 另外一种, 则是民众只提供自己基本的信息输出, 由精英阶层对民众的状态进行分析, 然后决策并执行. 可以将一种状态设定为民主, 一种状态假定为集权.
对民主还是集权, 我们没有讨论的资本, 引入这个话题, 只是来确定一个需求判断, 那就是民主和集权的需求是如何产生的, 从而可以作为借鉴, 判断我们在代码中的逻辑选择, 是什么样的需求决定我们将逻辑设定在上层执行还是下层执行. 集权的产生, 主要源自民众无法自我决策, 缺乏对整体环境的认知, 所以, 必须由中央提供最后的决策, 而民主的产生, 则是源自民众认知集体提升, 市场经济开始发达, 所以中央的集中决策反而对民众有害.
我们的代码中也有这样的问题, 不过次序倒过来了, 初学者, 更习惯于大核心, 而且必须是逻辑完备的核心, 组装成各个独立的模块, 从而实现了足够简单的逻辑依存. 但随着开发知识的深入, 就会知道, 哪怕是有足够多的第三方包, 我们的逻辑其实上都不会完全完备, 这时候, 就要开始追求小核心, 由最上层去决定逻辑的路线. 就拿最开始的时候提出的例子来说, 对一批数据进行更新, 然后刷新界面, 下层决定的做法最好的办法是直接有一个第三方库, 提供一个批量更新功能, 开发者直接调用即可, 虽然库内部逻辑足够大, 但是, 上层开发者非常简单, 直接调用即可. 次等的做法是封装一个带回调的单个请求, 然后设定一个状态值, 等批量调用之后, 修改这个状态值, 引发一次界面刷新工作. 但是, 如果到了上层决策的做法, 思路就完全想法, 可能就是直接封装一个直接调用服务端的功能, 等待返回值. 然后, 在最上层的时候, 开启一个线程, 批量调用所有功能, 调用完成之后, 再回到主线程执行刷新功能, 这样做相对比较复杂, 但是, 带来的结果是逻辑本身反而变得清晰, 但同时, 也带来一个后果, 那就是上层的工作量变得非常大.
具体是选择上层决定还是下层决定, 在代码中, 更多时候是按照需求来, 但是, 不可否定的是, 代码开发中的逻辑设计, 其实也是一个哲学选择的过程.

发表评论

电子邮件地址不会被公开。 必填项已用*标注