前言
配置灵活是陷阱
配置测试是关键
配置体验是灵魂
最后
什么是“配置”？百度百科上是这样描述的：“配”——把缺少的补足；“置”——设立。“配置”就是把缺少的补足并且设置好，这是一种从广义角度上的解释，而在不同的专业领域中，“配置”还有着其独特含义。
在系统研发领域中，“配置”通常会被理解为那些不需要经过程序编写、系统部署、甚至功能测试，就能快速调整程序处理方式的一种操作。它不但能够简化冗长的系统变更流程，还能让暂时无法确定的事项稍后再做决定。由此可见，“配置”已经在系统研发领域中起着举足轻重的作用，甚至有些组织都已将系统配置的灵活性，作为评判系统先进性的标准之一。听上去似乎没有问题，但凡事得把握一个度，否则可能会引发一场灾难。你是否经常听到过这种声音——“这些功能通过配置就可以实现”。嗯，非常之先进，但我想这恐怕只是用来欺骗外行的把戏而已，这些配置工作不但极其复杂，而且还难以理解。依我来看，那可能并不是配置，而是货真价实的高级编程！
对于优秀的设计人员来说，当拿到一份业务需求时，他们不仅要有拆解功能点的能力，更要有洞察扩展点的能力，这些能力能够增加系统的前瞻性，为系统迭代预留扩展空间，还可间接提高研发交付效率，从而让技术有机会领先业务“半个身位”。不过，掌握这些能力并不是件容易的事，稍不留神就会走火入魔。我见过某些经验老道的设计人员，他们为了追求极致的扩展性，会在业务需求的基础上添砖加瓦，对其进行多重抽象+封装，并将它们提炼为配置，还时不时会对别人宣称其功能配置的灵活性。原本简洁单一的功能，经过他们妙手一挥，转眼间升级为一个功能复杂度和配置困难度也上升了N个台阶的“强大”功能。虽说，在功能上仍然可以满足业务期望，但换来的却是高昂的理解成本及高危的配置风险，其隐蔽性足以让它们成为名副其实的陷阱。更可悲的是，这些陷阱并没有被开发人员所遏制，所谓“既设计，则实现”，有些开发人员只会将自己扮演为一名搬砖工人，并完全按照图纸的设计内容进行盖楼，导致那些享受着配置灵活性的使用者们，在完全不知情的情况下，已埋下了引发生产故障的种子。
想必大家都知道，任何功能在开发完成后，都需要经过测试才可以发布到产线。那么使用已发布的功能进行配置，是否还需要进行测试，估计绝大多数的同学都会认为配置也属于功能的一部分，已经在测试环境验证过了，没有必要再次验证，不会存在问题。但真的如此吗，你可以尝试统计下近年来，因配置问题所引发的产线故障有多少，你会惊奇的发现，它绝对不占少数，而为什么会造成这种现象，主要有两个原因，一是认为配置不是编程，不需要进行测试，二是认为任何功能的测试，都可以在测试环境验证。假如你也这样认为，那估计你也经历过因配置问题所引发的产线故障，如果你还未经历过，那产线故障可能离你已经不远了。造成这样认为的原因，还是由于对配置和编程的定义存在理解混淆，那它们是否有区分标准呢，至今为止我都还没有找到。有人认为修改商品库存是配置，而有人认为创建营销活动才是配置，答案五花八门，但你会发现它们都有共性——不用编写代码的都是配置。你无法否定也无法肯定，但没关系，你并不用纠结是配置还是编程，而更应该关注的是，它们是否都应该被测试。在我的认知世界里，不管是通过配置还是编程，只要是被创造出来的全新事物，就应该被测试，如果因客观因素无法在测试环境进行测试，那就必须在生产环境进行测试。因为创造都存在着不确定性，而测试就是为了发现不确定性，所以说配置测试是关键。
配置本身也是一种功能，它同样讲究客户体验。不佳的配置体验，不但会影响使用者的配置效率，错失业务运营的最佳时机，还会导致使用者配置错误，引发产线故障，造成经济损失。所以说优质的配置体验，是检验配置型功能好坏的核心标准。前文有提到过，配置和编程同样都具备创造性，但它们所处的操作环境并不相同。当你在编程时，你完全可以借助优秀的IDE集成开发工具，搭配上强大的开发插件，辅助你及时发现代码语法错误，甚至还能为你完成代码自动补全。但请你回想一下，你所开发过的配置型功能中，是否也拥有类似的辅助能力？恐怕是输入配置信息超长后没有任何提示，但提交后返回一堆无法让人理解的错误信息，或是对输入配置信息没有格式校验，导致功能运行时因获取错误配置信息而出现系统异常。这还不算什么，我还见过更反人类的配置操作。例如：当需要在输入框中输入多个词语时，需要使用者在中间手动补充“逗号”，或是无法在已配置过排序的记录中插入新记录，必须先将尾部记录删除，然后添加新记录，最后再将刚才删除的记录恢复回来。是不是觉得很夸张，其实这都只是凤毛麟角，只有想不到的，没有做不到的。当你身处在这样恶劣的操作环境下，配置不出错可能都有点对不起那位开发人员。因此，缺乏体验的配置就好比失去了灵魂，它将无法提供安全的创造环境及激发使用者的创造灵感。
作为一名从事技术工作的你，每天的工作必然离不开“配置”和“编程”，它们有相似点也有不同点，你不必非得对它们进行区分，而是可以将它们视为是一种组合，所谓“配置化编程”可能就是这种组合最好的呈现，我相信它可能会成为一种更高级的编程语言。
作者简介：信用卡业务领域摸爬滚打10余年，做过运维、干过开发、带过团队，现主要活跃在系统架构演进、通用组件研发、AI产品孵化等领域。
BFE开源项目相关文章：
欢迎关注“BFE开源项目”微信公众号，获得本项目的更多信息。谢谢！