做一个渲染 Pass 时，对职责边界的一点体会

近期工作里，一个渲染效果的开发让我重新想了想职责边界。

做独立游戏时，经常需要把一整条链路接起来。效果怎么实现、配置怎么读、资源怎么加载，最后通常都由自己处理。时间久了，很容易形成一种习惯：既然这些代码共同服务于一个功能，就把它们收进同一个系统，对外提供尽量简单的入口。

这种做法有它的好处。调用方少操心，内部实现也容易统一调整。平时看架构，会比较在意模块是否完整、封装是否合理、以后能不能方便地维护。到了分工明确的大型项目里，却发现还得考虑另一件事：这些变化分别由谁负责。

配置和纹理，放在哪里加载？

这次做的是一个渲染 Pass，也就是渲染流程中负责某个效果的处理阶段。它需要配置和纹理作为输入。刚开始的想法很自然：把加载也封装进去，外面只管启用效果，系统自己准备数据，再完成渲染。

只从使用接口看，这样确实省事。外部不需要知道效果依赖哪些资源，也不用逐项传递。但结合项目的实际分工往下想，问题就出现了。配置和纹理的加载逻辑、加载接口由业务同学维护，渲染模块如果直接把这部分流程包进去，就会依赖他们负责的一套规则。

加载接口将来调整时，即使渲染算法一行没变，效果也可能受到影响。排查的人看到的是画面异常，却还需要进入渲染系统，才能发现问题发生在资源准备阶段。负责加载的人需要了解渲染内部的接入方式，负责渲染的人又得跟进业务侧的加载变化，两个模块的维护范围就这样交叠起来。

把后续维护的过程想一遍，就能看出，调用入口简洁，并不能说明整个协作过程也同样简洁。

在这个项目的分工下，更合适的接入方式是由业务侧按统一流程准备资源，渲染侧通过约定的接口接收配置和纹理，完成输入检查、参数转换与效果执行。配置从哪里来、什么时候加载，留在负责这套流程的模块里处理。

渲染系统仍然可以把内部实现封装得很好。只是封装到哪一层，要结合输入的来源和维护责任一起判断。

独立开发时，很多边界没有那么显眼。加载和渲染都由自己写，接口为什么长这样、资源什么时候可用，往往已经记在脑子里。遇到问题，顺着代码往下查就行，也不用先确认该找谁。

多人协作以后，这些默认知识需要变成明确的约定。一个模块能否长期维护，除了代码结构，还取决于修改时能否找到对应的负责人，影响范围能否说清，以及另一个模块能否在自己的职责内完成调整。

例如，业务侧需要修改资源获取方式，理想情况下只要继续满足渲染输入的约定，效果本身就可以保持稳定。渲染侧优化算法时，也应尽量让业务侧沿用已有的接入方式。这样的独立调整能力，本身就是架构值得追求的一部分。

所以，这次体会也让我对优雅有了更具体的理解。一个接口看起来很漂亮，但如果每次改动都要两个团队一起检查内部实现，它的维护成本仍然很高。多传一个明确的输入，有时反而能省掉许多隐含的知识和沟通。

当然，项目的分工也可能不合理，接口也可能确实需要重构。遇到这种情况，应该把依赖和成本提出来，一起确定新的归属。仅仅为了让手里的模块显得完整，就把别人维护的流程一并接管，后续责任容易变得含糊。

只说一句业务负责加载、渲染负责使用，其实还不够。真正接起来时，仍然会遇到许多具体问题。

纹理传进来时是否已经可用？配置允许在运行中更新吗？资源没有准备好时，效果是跳过这一帧，还是使用默认输入？业务侧准备释放纹理时，渲染侧是否仍有任务在使用它？这些问题都会影响接口该怎样设计。

其中，资源的使用期限尤其容易被忽略。把纹理传给渲染模块，不一定意味着转移所有权。渲染侧如果只是借用，就要约定借用持续多久，以及调用方什么时候可以释放。若涉及异步提交，还要区分 CPU 上的调用结束和 GPU 真正用完资源的时间。

效果内部创建的临时渲染目标，则属于另一类资源。它们如何分配、复用和回收，仍然需要由渲染实现负责。业务输入的加载归属和效果内部的 GPU 资源管理，可以有不同的边界。把它们都归成一句资源由别人负责，反而会漏掉自己的工作。

同样，接收到外部输入后，渲染侧也要做好必要的检查。纹理缺失、尺寸不符合要求或配置参数无效时，应当给出能定位问题的信息。只看到效果没有显示，和能确认哪项输入不满足约定，排查成本差得很远。

职责明确以后，自己的部分仍然需要完整地完成，特别是交接处的校验、失败行为和使用期限。

这个问题其实可以更早讨论。在评估一个效果需求时，除了列出算法和表现目标，还可以把输入准备、效果启用、运行中更新以及退出清理串起来看一遍。每个阶段由谁提供条件，谁消费结果，谁处理失败，都应该有一个明确的答案。

如果只按做出画面来估算工作量，资源接入和生命周期这些事情很容易留到开发中途。等到代码已经写进去，才发现双方理解的范围不同，调整就会更麻烦。

以后遇到类似需求，想先确认几个具体约定：业务侧提供什么，渲染侧保证什么，资源尚未就绪时怎样处理，结束使用时怎样通知。先把这些问题说清，再决定内部应该怎样封装，设计会更踏实一些。

跨模块的问题当然还需要一起解决。发现输入异常时，仍然可以协助定位，提出接口建议，甚至参与实现。只是这些工作最好有共同确认的归属，双方都知道哪些是长期职责，哪些是一次协作。

做独立项目时，很喜欢把功能从头到尾包起来的完整感。这次仍然想保留对架构和可维护性的要求，只是看设计时，会多想一步：另一个负责维护的人，能否在不熟悉整个系统的情况下完成自己的工作？如果接口能够让双方各自把事情做好，后续改动也有清楚的落点，这份设计就更值得留下。