toB如何优雅应对私有化客户定制需求
豆皮粉儿们，又见面了，今天这一期，由字节跳动数据平台的“心飞扬”，给大家带来toB产品私有化有关的最佳实践。
正文共： 3326字 7图
预计阅读时间： 9分钟
作者：心飞扬
背景
我们的智能BI系统与内部业务方合作以及toB过程中，遇到过很多定制化需求，举两个例子：
• 作为数据中台产品我们被100+的业务平台嵌入，在嵌入的场景下，经常需要对很多功能做隐藏，例如仪表盘的授权/编辑等入口• 不同的私有化客户使用的IM软件不一样，有的是企业微信，有的是钉钉，字节使用的是飞书，因此在截图订阅功能上就需要适配不同的消息发送渠道
在定制化需求数量不多的情况下，我们一般可以直接在代码中根据环境的不同 if...else 处理，就像一般处理开发环境和生产环境的差异一样。但当环境数量逐渐增多时，每增加一个环境就需要在有差异的业务逻辑中加入针对该环境的判断，破坏了业务模块的封装性，不符合开闭原则。并且代码中大量的环境判断逻辑会极大降低代码的可读性和可维护性。下面两张图展示了一个简单的定制化需求导致代码可读性变差的例子。
如何优雅应对个性化
如果不希望将个性化需求的处理和正常流程混合，可以将个性化需求放到另外一个分支处理并长期维护。不过你也应该感觉到了，这不是一个好主意，即使只有两个分支，每次修复公共问题都要同步到另一个分支就够麻烦了。随着个性化需求越来越多，团队需要维护越来越多的分支，会逐渐陷入「分支地狱」，拖慢整个团队的交付速度。
那么怎么样才能更优雅地支持个性化需求呢？个性化需求真的是个性化吗？如果我们将个性化需求当成业务模块本身就该具有的能力来理解，事情会有什么变化呢？
当个性化需求转换成了系统该具有的能力，那么在实现业务逻辑时，就不应该有环境的判断，将环境判断从模块内抽取到其他位置，业务模块将原本对环境的差异处理逻辑抽象成自身的特性，针对特性写不同逻辑，这样就隔离了易变的环境，保证业务模块代码的干净整洁，也能利于环境和特性配置的统一管理。
在将个性化需求转化为系统自身能力后，为了支持系统在不同客户环境下展现不同的逻辑，就需要一个特性配置系统。
特性配置
特性配置其实就是将软件的功能特性差异做成配置化，根据环境、租户等信息的不同生成不同的配置，产品的功能差异逻辑完全由特性配置来决定。
特性配置(Feature Flags 或者 Feature Toggles)在业界是很成熟的方案，它除了上一节中用于满足不同客户定制化需求之外，还有两个典型的应用场景：灰度发布与A/B 测试。
灰度发布
产品在一些重要功能上线时如果对全量用户生效，团队的压力是很大的，因为并不知道这些功能的效果到底好不好，而灰度发布可以很好的规避这种风险。比如可以选择一部分用户先投放新版本，在小范围内收集使用反馈并改进，然后逐渐增大功能投放，最终全量上线。对应到代码中，可以利用特性配置系统，判断用户是否属于灰度范围来控制输出的配置，达到灰度的效果。
A/B 测试
当产品（经理们）在某个功能的两个备选方案上苦于没有数据支撑而举棋不定时，A/B测试就派上用场了。将两种方案都上线，让用户使用并收集他们的反馈，以此判断哪一个版本的效果更好，最终将效果更好的版本全量上线。对应到代码中，仍然可以利用特性配置系统，结合A/B实验配置，判断用户命中的方案来输出特性配置。
理解配置
特性配置使系统拥有了一次发布多个代码路径并在运行时选择执行路径的能力。如前文所述，特性配置有着广泛的应用场景，但如果不加约束的使用，势必造成配置的泛滥，优雅也就无从谈起了。为了更好理解配置，这里根据配置的使用场景将配置分为四类，并从配置的生命周期和变更的频度两个维度来衡量它们。
配置分类
发布配置
发布配置指的是在基于主干分支的开发模型中，用于持续部署的一种配置，该类配置使得团队可以在特性尚未开发完时就将代码合入主干进入部署，只需要将该特性关闭即可；或者是某些功能已经开发完成，但因为市场等其他因素而不立即开放给客户使用，即特性发布与部署分离。发布配置的生命周期较短，变更频率也低，基本是随着版本发布一起变更。
实验配置
即A/B测试中使用的配置，系统中的每个用户都被分配到一个逻辑路径上，并且该逻辑路径在实验结束前是不变的。为了收集到足够的实验数据，实验配置的生命周期可能需要维持数小时之数周不等，这里生命周期取决于系统的流量情况，但不会太长，因为随着时间退役系统引入的变量越来越多，会降低实验的可信度。
运营配置
运营类配置用来控制系统在运营方面的表现，如灰度发布配置、针对不同私有化客户的特性配置等。运营配置一般通过在线修改配置生效，生命周期跨度比较大，从一周到数年不等。
授权配置
授权配置用来控制产品特性在特定用户上的表现，例如产品的某些高级功能仅对已付费的客户开启。授权配置随着用户购买行为而变更，因此动态性很高；一旦选择了用授权配置来控制特性仅针对付费用户开启，这类配置的生命周期将会非常的长，可能是数年之久。
配置对比
• 静态配置 vs 动态配置
根据配置的动态性可将配置分为两类：静态配置和动态配置，发布配置为静态配置，其余为动态配置。实现逻辑的复杂性随着配置的动态性提升而提升，静态配置一般只需将配置传递到逻辑决策点即可；动态配置则需要更复杂的逻辑，例如实验配置中，一般会依赖用户ID并结合某些算法来做实验决策。
• 长期配置 vs 短期配置
根据配置的生命周期长度也可将配置分为两类：长期配置和短期配置，运营配置、授权配置数据长期配置，发布配置、实验配置属于短期配置。生命周期对我们如何使用配置有较大影响，对于短期配置，由于不久就将被移除，可以通过简单的 if-else 来使用配置；而对于长期的如运营配置，我们并不希望 if-else 充斥在各个地方，因此需要更合理的方式来使用配置，例如采用策略模式。
实践技巧
配置系统无疑是一项非常有用的技术，但也给系统带来了新的复杂度，有一些技巧可以让事情变得更简单一点。
• 配置决策逻辑和配置使用逻辑分离
有一个用户反馈功能，该功能在系统被嵌入场景下需要隐藏，因此有一个功能开关，示例代码：
if (!config.isEmbed) { loadFeedbackAndShow(options) }在以上示例代码中，配置决策逻辑（如果是嵌入环境，则不加载反馈SDK并显示入口）与配置使用没有分离，带来两个问题：1）如果决策条件变更，如某些客户环境也不启用反馈，会让决策逻辑膨胀，影响业务代码阅读；2）如果相关决策逻辑在多个地方维护，需要更新多次。
将决策逻辑和配置使用逻辑分离后：
// config definition{ enableFeedback: env.isEmbed || forbiddenFeedbackClients.includes(currentClient)}// config usageif (config.enableFeedback) { loadFeedbackAndShow(options) }决策逻辑只需在一个地方维护，使用逻辑也更加清晰。
• 暴露配置
我们经常会将代码的版本在构建时注入代码并通过某些方式暴露出来，这样开发者、QA或者运营就能获取当前产品的代码版本信息。同样的，对于特性配置也需要利用类似的手段暴露给相关方，获取当前系统的特性配置对于理解当前系统表现非常重要。
• 限制配置数量
特性配置一旦引入系统中，配置数量会膨胀的很快，因为添加一个配置实在太简单了。但特性配置是有维护成本的，它不仅给系统添加了条件逻辑，还增加了一层抽象，同时还增加了测试的复杂度。防止配置泛滥是很有必要的，有一些小技巧：1）及时清理无效配置；2）给配置增加过期时间；3）给配置总量设置限制，达到限制时先清理一些配置。
最后
回到本文标题，在优雅应对私有化客户需求这件事上，除了利用好配置系统做差异性管理之外，在产品上应尽量提供标品功能而非个性化功能，了解客户个性化需求背后的本质需求，内化为产品的标准能力。
福利
特意为大家准备了以下礼物进行抽奖：
《前端开发必知必会：从工程核心到前沿实战》3 本
诠释前端工程化实现细节
解密Babel、Deno、WebAssembly、Docker等前端融合
本书共5 章。第1、2 章系统介绍前端工程化的核心知识，包括Babel 7、ES 规范、Deno 开发入门、脚手架、自动化部署、Nginx、Jest 测试、Webpack 5、Vite、Rollup、Parcel 等。第3、4 章着重介绍前端架构的核心思想，包括前端核心模块的6 种常用设计模式、V8 引擎、宏任务与微任务、异步加载规范和函数式编程等。第5 章通过实战详细介绍如何从0 开发微前端和WebAssembly，帮助前端人员开拓视野。
本书系统介绍了前端开发的工程核心及前沿实战。相信无论是初级开发人员，还是具有丰富经验的中高级开发人员都能从本书中找到需要的内容，都能从阅读本书中有所收获。
那么如何获奖呢？
获奖分为以下3步
•第1步：关注本公众号「豆皮范儿」•第2步：转发本文到朋友圈并截图。•第3步：在本公众号「豆皮范儿」下回复你的截图
抽奖和领取奖品等其他事项：
• 「豆皮范儿」公众号后台回复「加群」，• 会在粉丝群公开抽奖过程，抽奖结果会单独发文章出来。
The End
如果你觉得这篇文章对你有帮助，有启发，我想请你帮我2个小忙：
1、点个「在看」，让更多的人也能看到这篇文章内容；
2、关注公众号「豆皮范儿」，公众号后台回复「加群」 加入我们一起学习；
关注公众号的福利持续更新，公众号后台送学习资料：
1、豆皮范儿后台回复「vis」，还可以获取更多可视化免费学习资料。
2、豆皮范儿后台回复「webgl」，还可以获取webgl免费学习资料。
3、豆皮范儿后台回复「算法」，还可以获取算法的学习资料。
4、豆皮范儿后台回复「招聘」，获取各种内推。
字节跳动数据平台前端团队，在公司内负责大数据相关产品的研发。我们在前端技术上保持着非常强的热情，除了数据产品相关的研发外，在数据可视化、海量数据处理优化、web excel、WebIDE、私有化部署、工程工具都方面都有很多的探索和积累，有兴趣可以与我们联系。
更多精彩文章，欢迎关注 “豆皮范儿”
点个赞，证明你还爱我