关于配置化的再思考（软件领域中的资源配置）配置化配置管理

资源配置是指资源的稀缺性决定了任何一个社会都必须通过一定的方式把有限的资源合理分配到社会的各个领域中去，以实现资源的最佳利用，即用最少的资源耗费，生产出最适用的商品和劳务，获取最佳的效益。 --- 百度百科

大概两年前，由于团队业务发展需要，笔者曾参与过一个深度配置化的软件系统的开发工作，期间对配置化进行了一次思考（软件系统中的配置文件）。机缘巧合，近期重构系统某些业务模块对『配置化』这个问题又有了新的困惑，于是开始反思之前的认知：配置文件真的不应该加入软件行为吗？

文章图片

【关于配置化的再思考（软件领域中的资源配置）】软件是业务的机器化表达，假设软件的行为（也即业务逻辑）是由代码与配置文件的内容组成，那么二者的组成结构应是怎样的呢？在『软件系统中的配置文件』一文中的观点是：软件应以代码为主（控制行为），配置文件为辅（控制参数），且配置文件不应包含业务行为的定义。果真如此吗？
在回答这个问题之前，先抛开技术思维，试图用经济学领域的概念来理解一下。
将文章开头的引言转换为软件领域中的词汇，可以得到如下表述：

资源配置是指资源的稀缺性决定了任何一个组织都必须通过一定的方式把有限的资源合理分配到组织的各个流程中去，以实现资源的最佳利用，即用最少的资源耗费，产出最实用的软件产品，获取最佳的效益。

除了机器（服务器相关）之外，软件领域中的资源就是人：销售、运营、产品、开发、测试等角色。
如果说组织的目标是各角色人力资源的合理配置以达到组织的效益最大化（各在其位，各司其职），那么组织的发展历程则是各角色人力资源配置化的变迁过程。
假设有一款软件产品它无限发展，经历了从代码定义一切到极限配置化的全过程，如下光谱图：

文章图片

软件开发初期：所有业务逻辑都写在代码里 - 业务实现完全由开发人员完成。
软件开发中期：将一些可能变动的参数放到配置文件中，以快速应对商业变化 - 业务实现的一小部分由开发人员完成转移到了产品&运营人员。
软件成熟期：业务已相对稳定，抽象出经常变化的部分封装成模块并形成规则引擎 - 业务实现由开发人员与产品&运营人员共同完成。
系统重构：业务进一步发展，系统重构升级，将业务核心逻辑抽象成可以通过DSL来表达，开发人员负责建设DSL，产品&运营人员使用DSL完成业务实现，提高组织产出效率 - 业务实现绝大部分由产品&运营人员完成。
低代码平台：业务进一步发展，组织扩张人员规模，DSL使用门槛太高，人员边际效率降低，这与高速变幻的商业环境不相匹配，于是一部分开发人员从建设DSL改为建设低代码平台，最终产品&运营人员以及销售等各角色通过简单操作平台软件（如拖拖拽拽一些控件）完成业务的实现 - 业务实现绝大部分由产品&运营人员完成，少部分由销售人员完成。
无码编程：业务处于市场垄断，商业智能出现，开发人员已构建出生产代码的机器，开发人员转为产品&运营，即开发人员通过『拖拖拽拽』生成代码，产品&运营转为销售，此时公司只有两类角色：生产软件的人员（开发）与兜售软件的人员（销售）。

组织不断发展，角色分工不断细化，复杂度不断转移，资源总是会去到最适合它的地方。
当然，以上是理想状态，大部分现实场景中经常会有资源错配的现象发生。但如果把软件配置化理解为组织内资源配置的合理过程，那么无论当前配置化多么过度它都合理。
所以，思考的角度不是『配置文件中是否可以加入业务行为』，而是『这种改变是否有利于组织内部的资源配置』。
本文首发微信公众号：yablog 欢迎扫码关注