项目实践中的胶水层

自底向上和自顶向下

项目的层次结构设计，通常有两个方向。一个是自底向上，从具体到抽象，从业务的具体操作开始，向上进行。一个自顶向下，从抽象到具体，从高层对项目的应用逻辑开始，向下进行。

项目完全自顶向下，则存在应用逻辑所需的领域原语和真实的领域原语无法匹配的风险。

项目完全自底向上，则存在做了许多与应用逻辑无关的工作。

因此，工程中，二者兼备。用自顶向下的应用逻辑表达抽象，用自底向上思路来收集底层的领域原语。代码是自顶向下和自底向上综合的产物。项目中同时有自顶向下的自底向上的代码，这样就有连接二者的“胶水层”。 胶水层去匹配顶层的应用逻辑和底层的领域原语。

胶水层的胶水层

Unix中的经验教训：胶水层必须尽可能薄。

项目中的代码，如果既不属于应用逻辑，又不属于领域原语，那么代码除了会增加项目的复杂度，无其他用处。应用逻辑和领域原语，应当清晰分离。

现实项目往往没有做到清晰分离，就会出现在胶水层上加胶水层的情况。

工程师觉察到胶水层的存在以后，很容易围绕胶水层自身，叠床架屋，把胶水层组织为一个个中间层，这样就有了两个胶水层。胶水层越来越厚，项目陷入的焦油坑。

发布平台的胶水层

前端和终端的连接越来越紧密，终端的UI渲染使用了前端相近的设计。使用终端原生代码或JavaScript代码处理渲染逻辑，使用模版描述UI。前者相当于综合了前端的JavaScript和CSS，后者相当于HTML。

终端项目的通过CI的包，通常会拆分2个，一个用于处理业务逻辑，一个用于处理公共的依赖。前者称之为业务代码包，后者称之为vendor包。业务代码包更新频繁，不同的业务迭代所构建的业务代码包不同。而vendor包通常更新少，多一个业务代码包可以共用一个vendor包。

因此，终端需要获取业务代码包，以及所依赖的vendor包。后台考虑到终端复用vendor包，业务代码包所依赖的vendor包如果有重复，则去重。

为了发布的安全，正式发布需要按版本灰度。线上有包发布：业务代码包1和依赖的vendor包a，需要同时下发，已全量。随着迭代的进行，新业务代码包2和依赖的vendor包a，开始灰度10%。两次发布都共用了同一个vendor包a，一个全量100%，一个灰度了10%。

同一个vendor包a，有2个灰度的值。后台vendor包去重逻辑会依赖顺序，可能会导致问题，10%的放量会覆盖已全量的。

vendor的去重逻辑，既不是底层所需，同时也不是顶层的发布业务所需，属于胶水层。

为了修复问题，直接的思路是针对胶水层升级，去掉去重逻辑，或者vendor的灰度值统一为100%等围绕胶水层的方案。后续项目迭代，终端依赖越来越复杂，这个胶水层就会越来越厚。

这违背了“胶水层必须尽可能薄”。梳理终端的领域原语：发布灰度的是业务代码包，而不是vendor包。vendor包是业务代码包的依赖。

考虑自底向上的底层原语，后台控制业务代码包的灰度，再处理业务代码包依赖vendor即可，就无需考虑vendor包的去重逻辑。在“胶水层必须尽可能薄”的原则下，后续支持更复杂包依赖关系，后台也能胜任。

考虑自顶向下的应用逻辑，后台的关键是保障发布的新增的代码的安全，旧的代码包的安全性已然验证了。在此思路上，还可以演进出差量包，精准更新终端所需的代码。

平台在演进中，遇到不少的胶水层的胶水层，其中最为典型的是模版发布。数据从七彩石的kv迁移到table，从table迁移到平台数据库。预载接口的优化，从数据库IO的优化，到平台多个缓存方案。到当前正在紧急进行的模版支持批量发布等等。

透明法则

通常来说，平台对外要支持用户需求，对内要考虑平台自身的演进。后者非常重要，平台自身随业务逐步升级了，就能形成解决用户需求的框架，用户源源不断的需求，就可以在规范内框架解决。避免需求越做越多，且问题越来越多。由于临时紧急需求多，需求流程没有从整体上妥善处理，就挤占了平台升级的时间和空间。而平台没有形成解决问题的框架，用户就会有更多的需求提出，陷入需求焦油坑，同时平台因缺乏升级而质量堪忧。

模版发布，跨越了多个周期，多数是临时紧急需求，甚至在临时方案上升级的临时方案，工程中胶水层的胶水层。不仅有工程技术问题，还会引发项目管理问题，最显著的是平台自身的升级问题。

所谓的紧急需求，通常是上游平台有变更，没有充分考虑下游平台的成本，在下游平台硬着陆。上游没有准确感知下游平台的用户诉求和平台规划，下游平台没有准确了解上游平台的应用逻辑。而上游平台和下游平台必须要对接，项目管理的胶水层就出现了。

按照“胶水层必须尽可能薄”原则，沟通要透明。就不应存在所谓的上游和下游，所有平台都在整体流程中游，减少平台对接的胶水层。胶水层薄了，平台之间就透明了，迭代推进的事项，就能作为自顶向下的设计的一部分，具有长久的价值，而非临时的胶水层的价值。

平台之间应坚持透明法则，大家就能跨平台的理解不同的平台的领域原语和用户的诉求，就能自底向上共情，自顶向下统一方案，合作就能更顺畅，项目管理就更高效。

一则古代小幽默

有医者，自称善外科。一裨将阵回，中流矢，深入膜内，延使治。乃持并州剪，剪去矢管，跪而请谢。裨将曰：”镞在膜内者须亟治。”医曰：”此内科事，不意并责我。”

译文：有一个医生，自称精通外科。有一位副将从战场下来，被乱箭射中，深入肌肉里，请这个医生来治疗。于是这医生手持并州剪，剪掉了箭杆，跪在地上请求奖赏。副将说：”箭头还在皮肉里，必须赶紧治疗。”医生说：”取肉内的箭头是内科的事，没想到也一起要求我来治疗。”

无论医术，还是工程技术，还是项目管理，不可不引以为戒。