使用配置进行你的开发
在开发中,我很经常的将很多功能设置成可配置的,这里不仅仅说的是应急的开关,而是包括了一些文本在内的信息。这篇文章也就是说说为什么我要这么做,以及这么做到底有什么好处。
从最简单的说起:配置开关
最简单,大家也最常用的是在后台配置一些开关,这些开关不用发布,只需要轻轻一点就能切换某些功能的状态,这也是大家通常会做的「基于配置」的开发的处理,毕竟发版的时间实在太漫长了,因此大部分后端都有有意识的将一些开关放在后台而不是开发写的配置文件中。
如果你用一些开源的博客或者论坛的话就会发现这一点尤其明显,毕竟它的受众相比广大工程师而言更加复杂,所以为了好用也会将一些设置放在后台作为开关出现。
配置还能干什么呢
上面说到的开关是一个最典型的用例,更重要的是,我们可能会发现,在一些程序中,配置甚至用于配置文案——这相当于我们在程序中使用常量去替代某些 Magic Number。
我们设想这样一个场景:今天老板想了一个表单,拍脑袋临时决定需要一些额外的用户信息:
- 用户名
- 手机号
- 邮箱
明天又觉得,这个似乎不太够,我还想要一个用户的学校信息。
后来,又觉得,诶,可能毕业时间、工作年限啥的也要一些比较好——这样,你就至少需要消耗三次发布。
假设一次发布流程需要半小时(Review 的人工成本就不计算了),在这三天里,你花了 1.5 个小时来等待新的版本发布。(甚至还涉及到了数据库变更)
对于这种需求不明确,或者需求可能会无限扩展的时候,把需求变更寄托于一次次的发布似乎并不合理,实际上,我们大可以把这部分抽成一个个配置块,表结构也可以建立的更加灵活(这是我非常喜欢做的事情):
name | slug | description | type |
---|---|---|---|
毕业时间 | graduation | 用户的毕业时间 如 2020 | int |
之后,前后端只要根据这样的规则进行渲染,而不用管有多少个字段了(当然,如果有特殊的校验需求,那么可能你还是需要挨个走发布流程的,或者扩充 type 的类型)
当然,后端是这样,前端也是这样,这一思路被广泛的应用于页面生成器中,当你选中一个控件并且拖动到页面中,不正是定义了一个 ${type}
类型的组件,而剩下的可视化配置则是其他信息吗?
文案约吗
上面说了 form 中的应用,还有一个比较典型的用例是文案,当然,这比较多见于前端,比如我们的免责声明页面,满满的都是字,但如果改一句话要发布一次,很明显就不合理,那么大部分人可能都会想到用配置去做这件事情,像发一篇文章那样去处理我们的文案。
还有呢
后端可以用配置去控制开关,那么前端可不可以呢?答案是可以的。
这里需要强调一点,我们所谓的配置,并不一定是把配置做在后端,做在数据库里,强依赖后端服务其实是一种不太好(服务器万一挂了呢)或者说浪费资源的做法,对于前端的诸如上文的配置,通常我们可以存储在 OSS 之类的文件存储服务中(当然你后端想这么做也可以)。从流量的角度,OSS+CDN 肯定要更加便宜(才不是这个理由呢)。
前端有时也会有功能的开关需求,比如说我新上线一个功能,但是担心这个功能会出现一些比较严重的问题,或者改动了核心部分的代码,这个时候,配置中心就变得非常有用了,预处理获取配置,根据配置决定是否启用新的功能。——当然,前提是,这不是一项极端要求加载速度的业务。
如同我们上文所说的,也能看到,OSS+CDN 在加载上肯定也比后端有优势,但是这并不能弥补加载配置期间其实是阻塞了后续流程执行的缺点,因此在引入配置前,需要考虑这一点。
总结
又拖稿半个月水了一篇,个人认为配置是一项非常有用的东西,在基础设施上也应该有一定的优先级,如果你的项目还没有这样类似的东西,或许这是一个非常好的 KPI idea。
植入部分
如果您觉得文章不错,可以通过赞助支持我。
如果您不希望打赏,也可以通过关闭广告屏蔽插件的形式帮助网站运作。