闲鱼业务扩张中，研发团队对流程把控严格，但在页面管理上显得力不从心，这成为了显著的难题。业务团队强调页面管理的必要性，而研发团队则专注于产品构建和发布，这种分工导致多平台发布存在不同步现象，页面和配置错误频发，严重影响了用户的使用体验。
研发与业务的关注点差异
研发和发布阶段的工作主要由开发人员负责。以源码开发为例，他们主要关注页面的产品属性，而运营人员很少介入。在闲鱼，开发人员专注于研发过程中的构建等环节，而业务人员则更关心页面的实用性。若这些差异无法得到有效协调，研发成果将难以迅速转变为满足业务需求的产品。这好比两队人马各自用力，难以合力推动产品向更佳方向前进。
在具体的项目执行中，可能会因为此类分歧导致工作节奏的延误。比如，业务人员希望完成某个页面功能，然而开发人员受限于研发流程，无法立刻满足需求，进而影响了业务的进展速度。
研发模式的转变与影响
过去，应用构建的结果主要是HTML、JS和CSS，而现在则是XTPL、JS、CSS和Schema。这种新方式使得基于模板构建多页面实例成为可能，增强了应用的适应性。比如在导购和营销场合，可以实现一码多页的功能。不过，这种新的研发模式也带来了一些挑战。比如，在数据依赖上，运营人员选择完选品id后，还需再次请求商品数据，这增加了操作的复杂性。
在这种研发方式中，特别是一些对体验有较高要求的场合，比如关键产品页面，虽然SSR在性能上有所提升，但并不适用于所有情况。不同的技术路径在不同情境下各有优劣，研发时必须仔细考量。比如，某些业务可能会为了追求短期效率而采纳现成的方案，却可能忽视了长期性能的优化。
数据模型相关问题
在数据模型领域，对于商品和内容这类相对容易实现标准化的内容，通过接入数据网关可以提升性能。然而，在导购、营销等场景中，数据之间存在相互依赖。以选品id与商品数据的关系为例。此外，模块还需负责数据获取的流程，这导致数据和业务之间的耦合度较高。因此，许多功能模块虽然UI界面看起来一样，但数据处理的逻辑却各不相同。
在实际操作中，运用数据网关来改进数据模型的方法，其在不同业务环境下应用的难易程度各异。部分业务环境受现有架构所限，接入可能存在困难。另外，数据间的紧密联系使得后续的开发迭代一旦出现问题，往往会引发连锁反应。
轻量网关的应用
轻量网关能进行数据依赖分析等逻辑处理，通用数据模型下都能使用。比如在闲鱼平台上，它对商品、内容、用户等数据都有处理能力，但对单一产品模型就不适用了。这个方案对解决首屏数据加载速度问题有一定的帮助，并且在导购、营销等场景中进行了众多性能上的优化。
然而，该方案存在一定限制。因为其适用范围较广，所以在面对特定产品数据时，无法直接应用。这可能会使得在应对某些特殊业务场合时，缺少合适的工具。因此，可能需要另寻方法，或者对现有的轻量级网关方案进行改进。
魔鱼平台的作用
魔鱼构成了前端统一研发体系，它不仅助力H5的开发，还能支持端外小程序等业务的拓展，并提供多样化的模板选择。魔鱼平台使得运营人员能够直接在编辑器中操作，无需前端人员介入，即可实现模块资源的动态添加。这样的功能既保障了业务的迅速推进，又减轻了前端开发的工作负担。
业务增长带来压力，魔鱼平台可能遇到需求持续上升的挑战。为了适应更多业务种类，可能需要拓展和改进技术架构，这又意味着需要增加人力和资源的投入。
数据投放方案的统一
Schema描述模型与配置编辑器可被其他中后台系统采纳。此举将统一闲鱼的数据投放策略。统一后的数据投放策略有助于业务全面协调发展。比如，它能保证数据在各个系统间的一致性，降低因数据不一致而引发的问题。
在执行过程中，可能要对多个中后台系统进行调整和升级，这要求大家共同配合。若某个系统未能及时对接或出现故障，将可能延误整个数据投放计划的进度。
大家是否也有这样的感受，即解决闲鱼在研发和业务上遇到的问题，需要多个部门之间进行深入的配合？期待大家的点赞和转发，也欢迎在评论区分享您的观点。
