Chris Matts 发起了一个讨论，提出如下问题:
在过去三年，我用过的最强大的技术莫过于延迟代码模式（latent code patterns，简称 lcp）。我刚做完一个项目，其中每个功能特性都是可以配置的，也就是说再也不会出现某个修复或特性必须等待另一个正在测试的特性。我们将重点放在快速有效的回归测试之上。尽管经常有重要版本发布，但我们只有一个分支的代码，因此不会遇到代码合并问题。还有人使用延迟代码模式么？我希望听到别人的做法，因为只有遇到问题的实践者才能做出最为出色的创新。
lcp 模式带出另一个问题，就是围绕着测试的在制品（work in progress）限制。大家有什么想法么？
这样看来，Chris 所提到的，就是说他们的团队有能力随意打开或关闭各种功能特性，即使是正在开发中的特性。这不会阻碍团队根据需要发布软件的能力，因为特性可以根据需要关闭。Chirs 后来说：这种做法背后的想法，就是要在作出所有的设计决策时提出这样一个问题：
这种设计方法能否对外做出承诺？
David Roussel 与 Chris 同在一个团队，他阐述了团队实施该方法的一些详细技术细节。在后面的讨论中，他总结了其他人采纳类似解决方案的几种不同方式：
我认为有很多种方式都能起到同样效果，但是重点在于要认识到：在发布之前的最后一分钟，我们必须做到可以调整发布版本的功能优先级，而且要能在不产生新的代码分支的前提下做到这一点。其他的都是细节问题了，但这些细节很有趣。 其他人怎么解决这个问题？目前有人提到：
- 依赖注入，还要做到在构建时可以变更依赖
- 依赖注入，还要做到基于配置变更依赖
- 采取简单的老式配置方式，使用 if 语句
- 针对每个特性做分支
- command 文档、command 模式
- 基于数据库的 command 式配置（得给该方法起个好名字）
Joshua Kerievsky 补充了下面的解决方法：
David，我们有时会把 Command 加入到仍处于在制状态的产品中，没用用户能看见它们，而我们可以通过 URL 执行。也许能叫“延迟 Command”？ 我不确定你上面的列表是否包括隐藏菜单项。
这种设计技巧（你愿意叫架构也可以）可不新鲜。实际上，它要比敏捷软件开发出现得早，而且在面向对象和模式社区中扎根已久。而它所能满足的需求，比如像 Chris 的问题：
这种设计方法能否对外做出承诺？
却是全新的。
暂无签名
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论