产研协同 – 探索低代码新模式

1. 产研协同 – 低代码如何打通上下游分享人 – 孙淘熔部门：HBG房产事业群-房产技术部-SAAS技术部日期：2022年12月06日 www.58.com

2. 自我介绍孙淘熔 58 房产事业部前端架构师 58 巧房、58爱房前端负责人擅长复杂SAAS系统的前方方向的开发工作

3. 背景及诉求方案设计演示进展与规划

4. PART 1 背景与诉求

5. 低代码应用场景 - 1 换装模式特点 • 模式相对固定 • 丰富选装物料常见于游戏换肤、商品展示、店铺装修、海报制作等

6. 低代码应用场景 - 2 中后台配置模式特点 • 模式相对固定 • 各种数据项配置常见于不直接面对客户的、固定模式的中后台系统

7. 第三种场景？以上两种场景的共性难度下降角色替换不太需要专业前端研发介入 • 选择性远大于复杂性 • 确定性远大于不确定性 • 模式与场景契合度非常高，即使有不契合部分，也是可以需求降级的是不是所有的场景都不需要前端开发人员？

8. 一则例子 7 5 4 1 6 2 3 表现特征 • 最开始就是一个普通列表 • 非标准化商品，未卜先知有难度 • 对于业务侧或产品而言，也没加特别复杂的需求 • 边际成本、精度问题、复杂度问题 • 这些改变与调整来源于客户诉求，不是可以随便降级的 • 能不能降级研发说了不算

9. 背景前端侧要如何提效？换装模式直接套用低代码模式可以吗？给非前端使用还有很多工作需要前端参与的工作仍然遇到工期紧，来不及做的情况给非前端使用中后台配置

10. 思考极端假设 n 当一个场景可以被标准化，那么门槛降低了，就不需要专业人员 n 一件事需要专业人员，意味着不太好标准化，定制化远高于简单配置矛盾专业人员的优势是处理复杂问题的能力传统低代码模式本质上是提高标准化，降低复杂度那么，专业人员在传统低代码模式下可能优势不大？

11. 痛点在有前端参与的项目中，采用低代码模式，遇到以下问题提效逻辑成本收益与业务的关系用了低代码感觉提效了，但好像又没有 😂

12. 痛点提效动机与提效结果的落差【拖拽 + 配置】一定比写代码来的高效嘛？【拖拽】对【 Ctrl + C / Ctrl + V 】，【配置】对【传参】，代码还能更细粒度抽象、复用提效能否贯彻软件整个生命周期？潜在的Hack是否会拖累效能低代码混入代码后，二次开发的效能会不会打折扣衡量效率的指标项是否明确？能否找出明确的可衡量项假设低代码效率高，两个低代码平台放一起，谁效率高呢？选A或选B是个问题

13. 痛点基础实施成本与知识体系成本基础设施成本项目框架要改？组件库要改造？Util类，第三方工具包不能用了？持续集成方式要换？开发习惯与知识体系成本对高级研发而言，一年后成为低代码专家，除了这套低代码以外啥都不会了

14. 痛点业务多样性与平台可维护性的冲突一定会遇到平台预置模式不能满足业务侧的场景。那么当遇到了这种场景平台优先还是业务优先？业务侧有细节有诉求，已有配置和钩子都实现不了，那平台配合改一下呗多个业务侧在同一块地方有不同细节诉求，那平台if else兼容一下呗多业务侧在同一块地方细节用冲突，那平台再用复杂逻辑兼容一下呗当业务方翻倍，很大概率会改不过来了，要么拒绝改，要么让业务方等兼容逻辑太多了，越来越难维护了，最终被业务拖成一个四不像

15. PART 2 方案

16. 思路效率提高的逻辑是什么？前端要的不是一味得追求降低复杂度与灵活度，这样等于放弃了优势能力；真正需求的是减少不必要的重复工作。怎么控制投入成本（基础设施+开发习惯+知识体系）？认识到附加成本的客观存在。如果基础设施、开发习惯，知识体系；可以不变，那就尽量保持不变，在提效方面，少做减法如何避免业务多样性与平台可维护性的冲突？不追求做大而全，涵盖所有功能的平台，其实也做不到；平台只提供兜底，把业务多样性还给业务侧

17. 切入点设计稿到前端还原设计稿是有可能自动化的作业模式产品出PRD 设计出交互稿前端前端写页面模版写页面交互前后端联调还原设计稿纯体力活、易出错实现与设计分离产品出PRD 设计出交互稿前端前端写页面模版写页面交互直连设计走查走查问题修复设计累、研发也累前后端联调设计走查走查问题修复

18. 基本思想代码低代码产品研发设计稿以结构化数据形式流转到下游产研协同发挥低代码的优势 - 降低作业门槛产品的设计稿能够成为代码的一部分职责分离研发侧保留编码在处理复杂逻辑优势不在需要关心产品设计项，减少工作

19. 设计核心设计与实现分离好处拒绝自动生成代码与人工代码混写 1. 低代码增效可以再全生命周期获得收益，迭代次数越多，增效越明显可视化编辑器额外代码产出线上代码 2. 一旦解耦，就可以实现重写或覆盖，获得极高的灵活度。系统灵活性是与代码的灵活性对齐的

20. 成本控制方案主次基础设施原来的框架、组件库、Util类新引入的框架开发习惯原来语法，参数新语法、新参数知识体系原来持续集成环境，发布体系没有要求成本低代码部分以组件形式接入，作为项目的一部分，而不是项目的主体

21. 附带收益应用面广存量项目上都可以使用存量页面上可以部分使用应用范围 ✖ 效能 🟰 综合收益

22. 把对业务控制权还给业务侧平台做了什么配置设计渲染引擎实现解释装配依赖输出可视化编辑平台拖拽项页面配置项预览服务业务相关性高的部件可视化编辑器

23. 把对业务控制权还给业务侧平台业务能力与业务侧共建平台服务业务方1 方案平台提供兜底，业务侧可以使用自己的部件业务方2 平台边界平台只维护核心能力，不关心业务差异化 ! ! ! ! ! ! 业务方N 组件库配置项渲染引擎解释部件预览服务可自定义

24. PART 3 演示

25. PART 4 进展与展望

26. 进展能用设计流程跑通小范围验证阶段，抛光细节从做功能转向设计review与再突破好用主动选择效能可量化

27. 规划场景覆盖度解决研发使用连贯度解决产品设计割裂线框稿工具产品化纯研发模式下研发侧能从模式中受益不求全覆盖共建与效能优先

28. 总结产研协同模式是为了平衡开发灵活性与生产效率的一次尝试特点不追求作业形式转换，而是通过自动化来减少不必要的劳动来提供作业效率。采用了设计与实现分离确保全生命周期有效。极低的副作用使其具备较高性价比。同时，在不牺牲实现灵活性与自由度的前提下，提供高度的开放性，可以使得业务侧在多维度上实现定制化适用场景必须有前端参与的项目，复杂性高于选择性的项目，常规代码与低代码混写的项目

29. 谢谢