房产运营活动的开发演进过程

【直播预告】昇腾 × 大模型：如何让 AI “跑得快” 又 “用得好”？

目

录

1.背景

2.传统开发

3.开发提效方案

4.低代码平台（积木系统）

5.未来规划

6.作者介绍

背景

为了更好的吸引流量并提升产品指标，针对各种节日及租房流量高峰期，房产每年共有几十场运营活动，包含租房、公寓、商业地产等不同业务，这些运营活动项目花费大量的人力物力资源投入。

尤其房产部门每年有两次比较大的运营活动，春节后复工时期及七月毕业生走向社会时期，是租房的两大高峰期，因此每年的这两个时期都需要组织大型运营活动。那么运营活动有哪些特点呢？

都有明确主题，与节日或实时热点相结合
时效性较强，必须按预定时间点上线，上线时间不超过两周
大型活动涉及多端多业务，流程线比较长
裂变能力强，足够吸引人

针对运营活动以上这些特点，就要求项目开发过程中，要注意以下几点：

主题多样，UI设计变化多
与实时热点结合的活动页面，开发上线足够快，这就限制了只能是H5页面
大型活动整体流程需依赖其他部门业务，多部门协作关系要全面考虑
玩法多样，需要各种小游戏引流

房产技术部在多次运营活动的开发过程中，我们也在不断探索新的方式与方法，持续完善并优化项目流程，以此来提升运营活动项目的开发效率。下表中是我们从18年到22年春运活动的项目参与人员及工时统计：

从表中我们可以看出前期随着双端业务的扩展及活动复杂性的增加，活动投入资源随之增长，而从21年改为积木搭建开始，我们的开发逐渐提效，而且效果显著。

整个提效过程也并非次活动中进行的，而是一个不断的探索积累过程。我们的探索过程主要经历了三个过程：传统开发、开发提效、低代码平台。

传统开发

2.1 开发流程

从2017年底到2019底这两年，我们基本都在使用传统的开发模式–流水线型。

比如18年底那次活动，为了能更好的协同开发、联调及测试，大约十五六人的团队集中在一个大的会议室中封闭，从开发到上线差不多一个半个月的时间，而且临近上线阶段经常需要加班解决bug。

由于当时的人力资源比较少，而业务需求又比较多，做项目过程中存在的一些问题只能找一些最快解决方案而非最优方案。这就导致一个恶性循环：人少时间紧问题多，做完没时间总结优化，下次重复解决这些问题。

2.2 存在问题

经过两次大的春运活动，我们已经发现传统开发模式中存在的一些问题，严重阻碍了开发效率，这些问题有流程方面的，有开发联调方面的，也有数据统计埋点方面的，还有不同端展示同页面的多端问题。

流程问题
传统开发模式的流水线型开发流程，在单页面项目或流程节点单人负责时具有很好的优势，可以保证流程按顺序无缝衔接，但对于多页面项目或流程节点多人负责时，就有明显的问题
开发联调问题
由于运营活动并非联系项目，中间可能会间隔两三个月才会进行下次大的活动，而且大部分开发测试人员都是按业务来划分的，这就导致不同业务无法复用代码
埋点问题
同页面要发送多种类型埋点的问题比较复杂。无论是开发，还是测试，都会在埋点上耗费特别多的时间。由于安居客平台并入业务时已经有自己完善的埋点体系，为了便于不同端的流量统计，同一活动页在不同端投放需要发送各自平台内的埋点。
多端问题
18年房产部门的运营活动还主要是58端进行运营，包括58M端和58APP，随着业务的扩展，到了19年运营活动投放又新增了安居客APP及M端，这就导致同样的事件在不同端需做多种兼容处理。

开发提效方案

从2020年开始，我们的团队人员快速增长，使我们有精力可以思考之前项目中存在的问题，并开始着手解决。这个阶段我们在运营活动之后也做了大量工作，为运营活动的开发提效赋能。主要通过以下几种方案。

3.1 流程优化

对于多页面的大型运营活动，我们优化了整体开发流程，将最主要页面的依赖交付放在前边，依次交付其他页面，这样各节点人员可以并行进行，整个开发过程会大大缩短。

优化后流程如下图：

3.2 统一埋点方案

针对运营活动中的多端埋点问题，我收集了前端组不同项目的埋点需求，整理了单类型埋点发送流程的八个步骤：

要提升多类型埋点发送过程的开发效率，首先要从前端开发人员的步骤入手：

首先要解决对于平台及环境的自动识别问题，同时需要一个埋点分发层根据环境及配置动态加载对应类型埋点SDK文件；
其次要解决埋点与业务耦合严重，埋点难维护的问题，需要将埋点配置及业务埋点数据与业务代码分离开；
想要保持业务代码的整洁以及开发人员的学习成本，还需要对不同类型埋点的初始化和发送方法进行统一；
另外要解决埋点测试耗时问题与测试环境埋点正确性验证问题，还需要一个线上页面，可以根据埋点配置文件自动生成。

基于以上几点思考，多类型埋点接入方案整体设计如下图所示。

统一埋点方案具有以下优点：

埋点解耦。
将埋点文件与业务解耦，不仅能提升埋点可维护性，还方便统一埋点格式
埋点插件
封装平台判断方法，并根据配置灵活引入相应sdk，提供统一发送方法
埋点数据测试
提供埋点测试页，可直接上传埋点配置文件，一键发送测试埋点正确性

3.3 多端差异抹平

随着多端业务越来越多，业务及数据的融合统一也在逐渐进行着。多端问题不仅在运营活动中需要处理，对其他的日常业务也有影响。比如登陆问题、跳转问题。因此将多端中的同类操作差异抹平，就成了必须解决的问题。

我们开发了Flib插件来抹平不同平台的方法差异，它具有以下功能特点：

提供了34种不同的方法适配不同端的操作
提供了像getQueryParams，getCookie等常用工具类方法
提供了平台及设备的常用判断方法
封装了埋点插件，灵活配置埋点发送

Flib插件的使用有两种方式：npm包或js链接，因此前端所有项目内都可以轻松使用它。

npm i -D  @fang/optimus//或<script type="text/javascript" src="//j1.58cdn.com.cn/frs/fanglib/optimus/1.0.41/index.js"></script>

目前，Flib插件已被房产部门绝大多数项目引入使用，成为了房产前端不可或缺的基础工具类插件。

3.4 通用能力复用

传统的开发模式中，模版是放在后端的，这导致每次联调时模版有些调整需要前端找后端来改，增加了联调成本。随着技术的发展，node作为模版层放在前端管理成为了更好的开发模式选择。但node作为模版中间层有很多问题需要解决：

登录鉴权
用户信息获取
设备信息获取
日志及埋点监控

针对这些问题，我们打通了scf及radis的node调用方式，统一开发了@fang/icp中间件解决登录鉴权及获取用户信息及设备信息等问题，开发了@fang/wmonitor、@fang/flog解决埋点及日志问题。

通用能力的打通为接下来的低代码平台打下了良好的基础。

低代码系统（积木系统）

房产部门每年还会有很多小的运营专题页，每次都需要单独开发，每个专题页面开发联调测试也需要差不多两周的时间。还有一些纯静态页面需求，仅需要一些图片及文案展示，但也需要开发人员一两天时间去开发上线。

为了解放这部分页面的开发，希望能通过拖拉拽组件的方式就可以生成页面，像小时候玩积木一样，因此我们将我们的低代码平台命名为积木系统。但要完成积木系统的建设，需要两大组成部分：组件库与页面编辑平台。

4.1 组件库

页面编辑平台依赖组件库的各类组件，而组件的开发需要满足以下要求：

独立功能开发，组件间耦合度要低；
组件开发要便捷，因此需要一个组件开发脚手架；
为方便组件配置，需统一提供配置类型；
灵活发布，版本可控；

首先我们开发了一套脚手架工具ftoy-cli，将组件的开发与发布过程简化到最低。

# 积木cli 安装npm i @ftoy/ftoy-cli -g
# 积木组件创建ftoy create
# 本地开发调试ftoy dev
# 组件buildftoy build
# 发布测试组件ftoy release -t
# 发布正式组件ftoy release

组件开发过程，还需要一些统一的工具，如接口请求方法及数据监听方法等，我们同样开发了@ftoy/core来提供这些能力。

另外组件在编辑平台内需满足可视化配置能力，因此组件开发过程中的配置config文件需要进行统一格式，我们使用@ftoy/config来规范配置字段。@ftoy/config共提供了13种不同类型来满足开发中的配置需要。

这些配置规范是配置平台内的可视化的基础，我们根据这些规范提供了方面快捷的配置界面。

虽然组件的开发与发布过程用几个命令就可以轻松实现，但组件库的丰富程度决定了积木平台可以完成何种页面需求。那么组件库是否组件越多越好呢？答案是否定的。假如给出100个甚至更多组件，如何能选择出自己所要，那将是一个非常困难的事。而且各业务相关的组件差异也很大，租房的房源组件就无法使用到二手房中。

因此我们将组件库分为基础组件及业务组件两类。基础组件包含容器组件、图片组件、按钮组件、文字组件、音视频组件等，业务组件可以由各业务自由开发创建。

为方便使用者了解组件功能及如何配置，我们还将基础组件的使用方法写入文档，便于其他使用者参考。

4.2 页面编辑平台

页面编辑平台主要有以下功能：组件列表、页面视图、编辑区域。编辑平台的建设主要有以下问题需解决：

页面配置过程，所见即所得的视图
组件版本控制
测试与线上隔离
一键预览与上线

解决方案

编辑页面使用vue框架，展示区域内容根据页面组件数据data渲染，配置过程变更页面数据data既可直接影响展示区域
组件根据版本加载不同js，组件引入时名称与版本号组合为组件名
测试页面使用独立路由，测试过程不影响线上
保存时已将整体配置保存打包到数据库，动态路由保证页面访问

积木系统上线后，能1小时内完成专题列表及静态页的页面开发，极大得提升了静态页面与专题页的开发效率。

还有些需求，需要用到之前编辑页面的部分组件或整个页面组件。对于这样的需求，我们开发了组件模版和页面模版功能，用户可以保存一组组件为模版，也可以保存整个页面为模版，这样就可以轻松在其他页面使用这些模版。

那像毕业季/春运这样的大型运营活动能否在积木内创建呢？还需解决以下问题：

页面与组件、组件与组件间的通信问题？

由于组件相互独立开发，要想组件之间相互通信，那就需要建立一种事件监听与事件触发的机制，还需要保证所有组件事件监听在事件触发之前。

组件间的嵌套组合问题？

要保证组件间的组合千变万化，必须保证组件直接能够相互嵌套配置。

与UI制定规则，抽离通用设计模块？

假如设计时没有一定规则，那我们样式上就没任何东西可以复用

与后端制定接口规范，保证模块数据接口格式？

要保证组件能够一次开发多次使用，那组件内的数据字段必须保证不会变动

解决通信问题

js本身就提供了事件监听与触发机制，不过需封装不同浏览器的兼容方法
根据每个事件key建立查询表及数据缓存，如监听key时已有缓存数据则直接触发

解决组件间的嵌套问题

建立可嵌套容器组件，其他组件可通过容器组件自由组合

解决UI与接口规范

与UI沟通，将常用房源展示模块、优惠券模块、任务模块、奖品领取等常用模块制定UI规范，保证一些背景及文字的可配置
与后端沟通，为常用模块订单独接口，将大的页面数据解耦，可以节省双方共同的开发及联调时间

以上问题的解决，使得我们的各种运营活动都可以通过积木系统灵活搭建。每次的搭建过程，为组件库不断积累新的组件，目前我们的组件库已有上百种不同业务的组件。而活动的开发过程效率提升也十分明显。

拿最近两次运营活动举例，我们的整体效率提升在40%以上，而前端提效更达到56%。

未来规划

5.1 丰富组件库

积木系统现在有基础组件11种，各业务类组件100多种，可以满足大部分页面的搭建。但运营活动多变的玩法，有些组件还是需要新开发，新开发的组件不断积累，丰富现有组件库，形成良性循环。而且游戏类组件还较少，后续将根据业务场景，抽离一些游戏类组件，提升活动引流水平。

5.2 风火轮接入积木系统

当前，简单的单页面房产运营活动，由运营同学通过积木系统自己搭建配置就可以完成上线。复杂的多页面项目还需要开发人员搭建，主要原因是页面元素过多的导致的位置及浮动需要到前端专业知识，而对于开发人员来说，搭建复杂活动页面也是非常耗时的一个流程。
如果UI图可以自动转换为可编辑页面，对活动开发效率将会有很大提升，也可以为运营人员提供更多自主上线能力。风火轮接入积木系统已调研完成，正在开发中。

5.3 增加PC端支持

由于房产大部分运营活动都是在手机客户端，因此前期积木系统内设计也都针对手机端进行的。但还是有一些C端及B端PC端运营需求，因此拓展积木系统的PC端页面编辑能力，也是接下来的一个方向。