开发平台运营（网站开发前景怎么样）

本文目录

• 网站开发前景怎么样
• 活动运营自动化平台实践
• 阿里体系下两种典型的研发驱动模式：运营vs产品
• 游戏开发与运营需要学习什么样的知识
• 移动运营平台的开发流程，及他们的业务
• App开发及运营需要多少资金（开发app的资金需求）
• FE主导打造一个运营活动平台

网站开发前景怎么样

一个网站包括什么

网站可以分为静态网站和动态网站。通俗的说，静态网站一旦做好，就不可以随便修改网站上的内容，内容是固定的，所以叫做静态网站。而动态网站，都有自己的后台，比如微博，每次我们打开所看到的前端页面都是一样的，但是每次打开，看到的内容都是不一样的。这些数据都是后台动态处理之后，交给前台页面，然后才展示给用户的。

发展趋势

第一、多元化的方向发展

对于网站制作的未来趋势，总的来说应该是往多元化的方向发展。因为现在的网站建设已经在越来越不能够满足现在很多公司和企业多方面发展的需求了因此在未来，为了适应越来越高需求的发展，那么网站制作方面必定是会往越来越多元化的方向发展的。

对于网站制作往多元化方向发展的渠道，首先是对微信的开发运营，因为微信现在是除了QQ以外使用最为广泛的社交软件，至于未来微信和QQ谁会占据更大的市场是说不准的。微信的很多功能都非常方便，尤其是现在对于微信公众号平台的开发。现在只需要扫扫二维码就可以关注公众号，非常的方便，而且现在在公交地铁上二维码也是很常见的，所以在这方面的范围是很广泛的，因此要想将做网站发展的更好，微信就是一个值得去开发的渠道。

第二、APP的开发

我们都知道，现在的网站很多都是要依靠着后面强大的运营商才可以实现运行，就比如很多网站都需要依靠360和百度等等才可以，这样对于网站来说其实是没有好处的，因为这样的话不仅不可以直接的向用户推广自己的网站，而且用户体验也比较差。如果开发出自己的APP，那么就可以更直接的向客户推广网站，并且对于客户群体可以更有针对性，因此开发自己的APP也可以作为将网站制作推广向更大的市场的一种渠道。

总来说，网站制作未来的发展趋势是很好的，并且由于企业和公司对于网络发展的需求不断扩大，网站制作也会向多元化的方向发展，而网站制作则可以借助微信和APP的开发来实现多元化的发展，我们在未来一定也会更加深刻地感受到互联网时代的魅力。

活动运营自动化平台实践

人人贷活动运营平台，是一个由人人贷大前端团队进行开发和维护，并用于自动化、可视化构建人人贷常规活动的系统。本文将会分享"人人贷活动运营平台"的设计思想和部分技术实现，希望对大家有所帮助。一、背景

人人贷前端团队在过去的几年里，接到了很多来自市场部门的活动开发需求，这些活动主要分为4大类：LP活动（LandingPage，引导页），用于新人注册的活动页面，基本都是一个注册框+若干产品卡MGM活动（Membersgetmember），用于好友间拉新的活动页面，一般包括记录，排行，分享等功能常规活动，一般包括抽奖、产品卡、排行榜、分享等功能，用于促进销量特殊活动，一般是游戏页面，相同的形式基本只会使用一次1.1活动开发人力瓶颈和上线周期长

一个普通的活动（包括上述的LP活动、MGM活动、常规活动）开发时间得多久？

正常情况下，一个涉及到H5和PC两端的简单活动，从产品提出需求开始，设计师需要2人*2天来完成设计工作，开发需要3人*2天（包括H5、PC端页面、后端接口开发、接口联调），测试需要2人*2天投入。

就这样，从需求提出到页面上线，需要一共投入14人*天的人力资源，得7个工作日才能完成。

而遇到比较紧急的活动开发需求，上线周期需要压缩，大家都得加班来完成。

另外，由于公司财务结算的特殊性，很多活动的开始时间一般都是凌晨，开发、测试人员需要确认活动在线上运行正常，才能下班。1.2活动功能重复和反复修改

随着公司业务的发展，活动的开发需求越来越多。前端团队有三分之一的人力，长期投入在活动页面的开发中。

事实上，咱们大部分的普通活动，功能并不复杂，而且大部分的功能比较重复。

这种功能重复性的页面开发，对于个人和团队的长大来说，并没有太多的价值。而且活动上线后，经常因为样式和文案的关系，需要修改代码，重新上线，导致团队成员普遍比较反感这种普通活动的开发。

期间，团队也提出过组件化开发的方式，试图将不同的功能模块抽取出来，在不同的活动页面上进行引用，以便节省开发时间。但由于设计方案的不确定性，以及不同开发人员参与，这种抽取的功能模块复用性不太高，效果不是特别理想。并且不能解决样式和文案修改，需要重新上线的问题。

总之，普通活动的特点是：页面功能大同小异、开发时间紧、下线快、技术长大低。

随着团队的技术体系日益成熟，我们终于腾出精力，试图解决普通活动开发中各项痛点。二、人人贷活动运营平台

早在十几年前，使用Dreamweaver就能可视化地搭建出前端静态页面。虽然Dreamweaver已经成为过去式，但是可视化搭建的思想，却被广泛使用。

我们在调研业界常用解决方案中发现，很多公司都有自己的活动运营系统，可用来高效、可视化地配置活动，以及监控活动运营数据。我们希望采用这种活动页面可视化搭建的思想，由运营人员根据实际的运营需求，自行添加活动，并配置对应的活动页面。运营平台2.1整体框架

首先，简单介绍下人人贷前端的开发模式。

随着Node.js的兴起，我们从2016年开始，将原有基于JSP的前端开发模式，改造成使用Node.js做中间层，进行前后端分离的模式。前后端分离

人人贷前端使用的就是图中所示的前后端分离的开发模式（图片来自Web研发模式演变），这种开发模式下，前后端的职责清晰。对于前端来说，两个UI层各司其职：Front-endUIlayer处理浏览器层的展现逻辑，Back-endUIlayer可以用来处理路由、模板、数据获取、cookie、服务器端渲染等。

在这种前后端开发模式下，整个人人贷活动运营平台的架构图如下：整体设计

整个运营平台系统分为四大块。

1、组件库。运营平台采用了业界通用的组件化方案，并且选用React.js作为组件的开发库。下面会详细介绍组件库的拆分和开发模式。

2、前端系统。整个运营平台包括积木系统、rrd-h5、rrd-pc三个前端系统。其中积木系统是运营创建、、发布活动页面的系统，属于内部系统。而rrd-h5和rrd-pc属于面向用户的Back-endUIlayer，它们是基于生成的活动配置数据，对活动页面进行渲染及提供异步接口，以供用户访问。

3、后端接口。在后台服务上，由于活动并不是特别复杂，我们有较大一部分接口，比如抽奖、记录收获地址，只是做一些简单的存储或者计算，就直接使用了Node.js实现，也就是上图中的node-market-service服务。而部分与公司主营业务相关的接口，比如投资返现这类，还是直接使用后端提供的Java接口。

4、数据层。用于存储活动配置相关的数据以及部分运营数据。2.2组件库

我们按照功能模块，将往期的活动页面拆分成了不同的组件。

以移动端的好友页面为例，这个页面就包括：图片组件（banner图）、活动规则组件、记录组件、战队排行榜组件、平台增信组件和好友按钮组件等。

组件拆分完成后，我们就得到了一个组件库。

为了便于对组件库进行管理，我们按照所属的平台，将组件库拆分为jm-common、jm-mobile、jm-pc三类，分别对应两端公用组件、H5组件、PC端组件。

如上文所述，我们的积木系统定位为可视化平台，在对组件进行配置后，需要在页面实时展示。rrd-h5和rrd-pc服务也需要根据页面的配置数据，对组件进行渲染。

这三个系统中都需要使用组件库，为了方便组件的开发以及预览，我们将组件库的源码集成到了积木系统的代码仓库中。

积木系统通过项目代码中的组件库源码来加载组件库，当组件的代码有修改，积木系统能通过重新编译，刷新页面并预览到新的组件样式。

组件库还会通过开发环境判断，会自动在系统中使用模拟数据，方便了组件开发时的测试。

为了方便进行版本管理和组件库接入，当组件开发完成后，我们会将组件库发布在私有的npm仓库中，同时在rrd-h5和rrd-pc中，更新对应的组件库版本号，就能加载到新的组件。2.3活动配置与页面配置

在积木系统中，需要先创建活动，然后才能创建该活动对应的移动端、PC端页面，而不是直接创建活动页面。

这是因为根据以往的运营经验，一个活动，是可以对应多个推广页面（至少是H5和PC端两个页面），而这些推广页面需要共享一些活动配置。

数据存储上看，我们新建了activity、page、page_record三张表用于存储活动配置、页面配置和组件配置相关的数据。activity是活动配置表，负责记录活动名，活动的上下线时间，业务相关的活动配置以及公用活动配置等。其中公用组件配置，是指该活动下的页面，需要公用的组件配置项。比如领取优惠券组件，会将优惠券的金额、类型、批次等，放到公用组件配置中，这样能有效避免在多个页面的组件中分开进行配置时，配置出错或者不统一的情况。公共配置page是页面表。新建页面时，就会往该表中插入数据。信息会记录页面名，页面所属的活动id，页面所属的平台（移动端orPC端），发布时间等。需要注意的是，该表不会记录具体的组件配置数据。这是为了将页面数据与组件配置数据分离。但是页面表会记录线上页面使用的online_record_id，用来关联查询线上页面使用的组件数据。每次发布页面后，我们会将最新的online_record_id更新到对应页面数据中。page_record是组件配置记录表，主要负责记录所属的页面id，具体的组件数据，人，发布时间等。在积木系统的活动页面中，每一次保存页面，都会在这个表中插入一条数据，这样方便查找记录，同时也方便回滚。页面2.4组件的配置与配置数据解析

按照我们规划的操作流程，运营同学在积木系统中新增活动，创建页面后，需要给页面添加组件，修改组件配置，配置完成后，保存页面中的组件配置，最后发布页面。

不同的组件，需要用到不同的配置项。那么我们该怎么在积木系统中，给不同的组件提供不同的配置项呢？

首先得介绍一下组件的开发模式。

在开发组件前，我们会提前和产品同事确认该组件所需要的配置，包括组件样式配置、组件文案配置以及组件业务属性配置等。

开发组件时，我们一般会添加三个文件。以图片组件为例，我们添加image.jsx、image.scss、spec.js，分别是组件的具体实现代码、组件样式文件、组件的配置文件数据。

在配置某个组件时，积木系统通过读取该组件下的spec.js文件，提供不同的配置弹窗。

***隐藏网址***

以上的配置文件中，有部分属性是以下划线_开头，这部分属性属于积木系统专用的属性，会在给前端页面传递组件配置数据时，过滤掉这些专属属性，避免配置数据过多，也避免部分内部数据泄露。

一个活动页面，一般会添加多个组件，而且组件间还可能存在嵌套关系，页面上的组件配置数据如何组织、解析，也是必须要解决的问题。

我们这样定义页面上的组件数据：{"dataMap":{"id1":{"cid":"id1",//组件id"type":"pc_component_1",//组件类型"name":"组件一",//组件名"platform":"pc",//组件所属的平台"acceptChild":true,//是否能添加子组件"data":{},//组件数据"style":{},//组件样式"childs"://第一层级的组件id}

页面的组件配置数据中有dataMap和childs两个字段。

在需要通过这些配置的组件数据来渲染页面时，首先使用配置项中的main字段获取所有第一层级子组件的id，然后在dataMap中，根据组件id来查找对应的具体配置，进行渲染。

如果某个组件配置数据中的childs字段不为空数组，就意味该组件中嵌套了其他组件，就继续通过childs中的id值，在dataMap中查找对应组件的配置数据，并渲染子组件。

还有，我们之前提到过的公共组件配置数据，在渲染组件前，也会和dataMap中的对应组件配置进行数据合并。2.5rrd-h5&rrd-pc中如何渲染？

那么积木系统中生成的页面组件配置数据，是如何在rrd-h5和rrd-pc中，进行渲染的呢？

其实，目前主流的组件渲染方式有三种：加载所有的组件定义，然后通过活动id和页面id获取页面的配置数据，进而动态渲染出页面先通过活动id和页面id获取页面的配置数据，然后按需加载组件，渲染出页面服务器通过页面配置和组件定义，直接在发布时生成静态页面

不同的方案各有优劣。rrd-h5和rrd-pc系统中，我们使用了第一种方案来进行渲染：我们的线上页面模板，会默认加载所有的组件。

以rrd-h5为例，我们会在活动页面模板中引用所有的jm-common(公共组件)和jm-mobile组件库代码。然后使用活动页面URL中携带的活动id和页面id，通过node-market-service服务获取活动数据和页面组件配置数据。之后就按上述2.4组件的配置与配置数据解析中介绍的组件配置数据解析方式，渲染出整个活动页面。

就这样，用户就能看到配置的活动页面。三、TODO

目前的运营平台，其实主要以系统为主，并提供了少量的查询功能。

我们未来会继续迭代，将继续集成运营监控、报警，自动生成活动数据报表等功能。

***隐藏网址***

人人贷活动运营平台在2018年9月上线后，效果极其明显：活动运营平台，能够自动化、可视化地创建活动及活动页面。活动运营平台，让活动的上线周期，从以往的6天，降低到了2天。设计师切完图，运营人员就能配置上线。活动可配置上线和下线时间，开发人员基本不会因为活动的开发而加班。运营平台规范了活动功能的形式，同时，设计师也会在组件的可范围内进行设计，组件可配置项丰富。活动页面的样式和文案的修改，不再需要重新上线。释放出的前、后端开发人员，能将更多的精力投入到对新技术的研究。

由于篇幅有限，活动运营平台的很多具体实现细节并没有过多描述。如果大家有感兴趣的问题，可以留言进行交流。

最后，欢迎大家star我们的人人贷大前端团队博客，所有的文章还会同步更新到知乎专栏和掘金账号，我们每周都会分享几篇高质量的大前端技术文章。参考文章转转运营活动高效开发有哪些秘诀？QQ会员活动运营平台演变实践页面可视化搭建工具前生今世前端服务化——页面搭建工具的生与死积木系统，将运营系统做到极致美团外卖前端可视化界面组装平台——乐高

阿里体系下两种典型的研发驱动模式：运营vs产品

在产品研发领域会涉及到很多不同的角色，比如运营同学、开发同学、产品同学、设计同学等等，除此之外相关的人还有汇报线上的老板、我们的客户……不同的业务和场景下，不同的角色对研发活动的影响力也不尽相同。这篇小文就是想总结一下不同角色驱动的研发模式的特点。

废话不说，先直接罗列一下我目前能想到的几种典型不同角色驱动的研发模式：

在阿里内部，最常见的就是 运营驱动 和 产品驱动 这两种研发工作模式，所以这里，我们尝试详细对比一下这两种模式的差别。如果你能看到这里，那么也建议你可以把自己目前(和以前)的团队套过来感受一下，如果有什么不同的观点，也希望能联系我，和我交流。

一般来说一个业务在新创立的阶段往往都是产品驱动的，这个时候需要产品去探索满足业务的产品形式，产品价值的不确定性使得研发还是在实现产品功能为主；但如果在产品相对比较成熟的阶段，产品价值的逻辑已经明确固定了，这个时候就是需要靠运营去实现影响力的最大化，比如现在阶段的手淘，往往是运营驱动的模式为主，但我们去读读《人人都是产品经理》就知道，在淘宝上线的早期也是产品驱动为主的模式。

不同的业务种类也会导致不同的驱动模式。如果是工具类的产品，由产品来驱动研发是合适的（如钉钉）；但如果是O2O、团购、到家这些偏服务类的产品（如双十一），可能运营驱动就比较常见，符合业务组织方式的特性。

相对于产品，运营更现实，希望更快的看到结果，看到KPI数字的变化。这种方式的好处是更加结果导向，执行力更强，但倾向见效快，但短视的产品方案，不可避免的比较容易出现为了当前的业绩数据而牺牲长远的战略价值。并不是说产品驱动一定会有远见，只是相对运营来说，产品驱动会考虑的更长远一点，往往会有一个产品发展路劲的思考和规划。

运营更关心的是业务规模，比如安装量、日活量、成交量等等相对来说偏绝对值的目标，这些目标对运营来说比较容易找到抓手去影响；对产品来说往往比较习惯订偏质量的目标，比如覆盖率、转化率、活跃度等目标，这些目标代表了用户的心智模型，是产品比较容易有抓手去影响的地方。

相对运营，产品往往和开发同学离得更近，所以产品更能理解开发对技术沉淀和突破上的诉求，所以在产品驱动的模式下，技术开发相对来说会有更多机会创造体系化的产品、沉淀技术能力；而运营驱动下的研发相对来说重复的、临时的工作会多一些，这种环境下就需要开发同学自己更加主动的思考技术上的归纳、抽象，通过技术的手段更好地来满足运营的需求。

这个最直接，在产品驱动的组织里，产品同学的成就感自然就比较高，在运营驱动的组织里，运营的同学成就感就比较高（其他驱动模式里的道理也类似，比如技术同学会在工程师文化比较浓重的团队更有成就感）。

其实没有完美的研发驱动模式，不同的业务，在不同的阶段，甚至不同的团队基因都有适合自己的研发模式。对于我们每个人，首先你得有能力能判断出你当前的组织是哪种研发驱动的模式，这个模式都会有哪些特点；其次，你的得知道怎么利用当前模式的特点，让自己的能力和影响力在组织内部得到更快的提升。

游戏开发与运营需要学习什么样的知识

1、游戏开发是一个过程，为了激发玩家玩游戏热情，通过遵循设计制作规则，来设计人物、场景等游戏要素。
2、主要流程包括原画创作、建模、材质、灯光及渲染、骨骼设定、动画、特效等部分。涉及范畴包括 ：游戏规则及玩法、视觉艺术、编程、产品化、声效、编剧、游戏角色、道具、场景、界面等等元素。
3、游戏程序开发归根到底就是软件工程，是游戏制造环节中不行短少的重要部分。游戏程序开发是技术含量最高的，游戏程序员的薪资也相对其他职业高许多，目前游戏职业中游戏程度人才的缺口非常大，供不应求。
二、游戏开发需要具备的知识
1、游戏本质分析，游戏产业概论、游戏开发流程及职业划分、玩家需求分析、构思创意及文档编写要求、游戏故事设计、游戏元素、规则、任务、系统、关卡设计、游戏平衡设定、界面与操作功能。
2、透视基础、构图基础、结构素描、明暗素描、艺用人体解剖基础、人物速写、Adobe PhotoshopCS3软件应用、PhotoshopCS3造型基础、游戏美术风格技法、色彩基础、游戏色彩练习、肖像绘制、质感表现。
3、3DMAX软件基础、游戏材质基础、游戏道具制作、作品渲染。
三、游戏场景制作技巧、场景材质制作、卡通角色制作、写实角色制作、怪物制作。简单分类的话就是：
1、扎实的算法知识。主要有：树或图的搜索算法、A*算法、碰撞检测算法、BSP树、人工智能。
2、相关图形处理知识。比如:Direct X编程、OpenGL编程、图形学的相关知识（三维图形的形体、纹理、贴图、照明，还有三维对象的消隐算法比如油画算法，Z缓存）和动画处理知识。如果想深入还要学会几种三维引擎比如OGRE。
3、扎实的程序语言功底，主要代表为VC、DELPHI和JAVA。其中VC使用最广，现在比较大的游戏也由此开发；DELPHI功能也很强，很多网游：比如网金、传奇都用到了DELPHI；JAVA用于开发手机游戏。
补充：
一、游戏开发需要学哪些
1、基础公共课：游戏概述 Photoshop平面软件及像素美术 3dsmax软件基础及效果图制作 游戏程序设计基础及游戏制作原理 游戏策划、制作、测试及运营实践 游戏行业规划及职业素质。
2、专业技能课：手机2D游戏开发 2D游戏开发技术实战 C++语言及算法基础 WIN32程序开发及MFC基础 2D游戏开发实践 行业规划及职业素质。2D网络游戏开发主要学习内容有网络游戏程序设计、网络游戏算法设计、2D网络游戏平台设计以及商业实战项目训练，包含C++、数据结构、算法基础、Windows API使用、MFC原理及其应用、2D图形渲染技术、界面设计与应用。
3、游戏程序方向： Direct 3D程序开发基础 3D游戏开发技术实战 游戏引擎的修改与使用网络通讯、数据库及游戏服务器、行业规划及职业素质、游戏综合项目实战训练、基地顶岗项目实训。
二、游戏开发常用软件
1、3dsMAX：大多数游戏开发公司美工使用，效率较高，可以独立制作游戏中所有美术相关资源。
2、Delphi：直接编译生成可执行代码，编译速度快。由于Delphi编译器采用了条件编译和选择链接技术，使用它生成的执行文件更加精炼，运行速度更快。在处理速度和存取服务器方面，Delphi的性能远远高于其他同类产品。
3、 Photoshop：PHOTOSHOP是一个很好的图像软件，PHOTOSHOP的应用领域很广泛，在图像、图形、文字、视频、出版各方面都有涉及。
4、MAYA：跟3dsMAX差不多的软件，因个人喜好而定， MAYA在制作动作的方面较MAX稍差，不过在很多方面这两款软件都是可以兼容的。
5、其他：在个人计算机上，可以用目前流性的软件开发工具，比如：C，C++，VC++，Delphi，C++ Builder等。由于Windows操作系统的普及和其强大的多媒体功能，越来越多的游戏支持Windows操作系统。

移动运营平台的开发流程，及他们的业务

1.移动运营平台有很多种吧。我接触过的有：
电子运维系统——通常用于日常运维，包括故障，割接，值班，各种统计等
资源管理系统——通常包括局站，光缆管线，人井，接入间等，偏向于硬件
大客户系统——通常是对大客户如华为等的日常业务。
另外好像还有客服系统，BOSS系统等。
2.语言就很多了。大部分都是B/S结构，最常见的是JAVA,C#。各地的都不一样。
3.开发流程——合同达成、需求分析(几乎都要现场沟通)、需求书形成、Demo制作、概要设计、数据库设计、编码、测试，这个是基本模式，不过国内的软件开发几乎都要做后期维护，而且通常会有按期完成若干模块的概念，经常变更需求。做起来比较辛苦。
4.业务……我最熟悉的也许就是电子运维系统的关联业务了。
主要就是：日常运维。
包括数据、语音、传输以及综合的故障单处理(如果不是一套的话，那基本上就要与其他系统如客服系统，号线系统做接口)；
割接业务的发起、审批、变更、实施直至结单的流程；
集客响应包括资源核查、重保通信、运维任务等流程的实现；
排班、值班、交接班；
作业计划，就是制定作业，定时完成；
报表统计类，比如故障的处理及时率、值班出勤率、割接成功率等。

App开发及运营需要多少资金（开发app的资金需求）

App开发及运营需要多少资金

简单点来说，要视手机APP的需求及质量而言，价位一般在几千到十几万左右，更高端的价格更高。

今天，我们就来详细分析一下这个问题，请继续往下看吧。

一、APP开发款式分为固定款和定制款，两者的价格均不相同

固定款：是指直接套用已有的、现成的APP固定模板，报价是固定的，所需要的功能也是固定的，缺点就是客户拿不到源代码，也不能根据企业需求进行定制，由于源代码是封装的，如果企业以后想进行功能升级或系统维护的话，也不能够实现，只能重新开发一个新的软件。

固定款的APP开发时间短，约2~3日的时间即可完成，费用大约在几千到几万之间。

定制款：定制款是指APP的功能全部重新开发，过程比较繁琐，需要美工、策划、APP开发（前台/客户端/手机端）、后台程序员等工种协同完成，大型的、功能复杂的APP甚至需要数十人的团队。

由于APP的功能和设计都是定制的，因此价格会高些。定制款的开发时间与开发价格是成正比的，开发时间长，大约在两三个月甚至不定的周期里才能完成，而费用大概在几万甚至十几万左右。

因此，想要知道开发一款手机APP需要花费多少钱，企业主首先必须把APP的详细需求和功能告知APP开发公司，开发公司才能报出一个合理的价格。

二、手机APP平台不同，制作成本也不一样

现在市面上流行的手机APP制作平台主要有两种一般包括两种系统：安卓系统（Android）和苹果系统（IOS）。

一般来说，制作苹果系统的手机APP软件费用要比安卓平台的贵一些，因为苹果公司对苹果平台的封闭性和手机APP开发语言Objective-C的难度，都让APP开发者加大了苹果系统手机APP开发的难度。

三、APP制作成本包含参与人员的工资

通常情况下，开发一款APP需要产品经理、客户端工程师、后端工程师和UI设计师各一名，这已经是制作手机APP应用软件比较精简的配置了，所以这些参与人员的工资也是包含在APP制作成本当中的。这些工作人员的月薪加起来可能都会超过4、5万元。

四、APP开发公司的所在地

需要注意的是，同样实力的APP开发公司，在不同的城市也会导致APP的成本费用高一些

FE主导打造一个运营活动平台

背景

当今互联网公司，一般都会有一些运营类活动，如公司活动宣传、节假日优惠促销等，在电商类公司更是需要频繁的上（下）线运营活动。在这里要说明一下，本文讲的并非类似易企秀这样的制作“手机幻灯片、H5场景应用”的运营平台，而是一些常规运营活动。当然如果要做幻灯片滑屏效果，也可以开发一个“幻灯片组件”。

那么，如何上线一个运营活动呢？传统流程如下：需求收集专题制作：页面切图、效果实现、接口开发QA测试上线活动结束，手动下线

传统开发方式存在以下几个缺点：周期长，从往往每个运营活动都做为一个独立的Mini项目进行开发人员大量重复劳动，无法（不便）复用一些之前运营活动中开发过的功能，比如设置分享、与App的交互等运营活动投放过程中，修改不便，如bugfix、修改文案，正规公司也需要一个完整的上线流程

为解决这些问题，很多公司都推出了自己的运营活动平台。比如淘宝早期的eCRM-图腾，到目前的统一营销平台UMP、蚂蚁金服的闪蝶（闪蝶更像易企秀）、京东的通天塔等，都是非常优秀的平台工具。

那么，如何开发一款精美轻巧的运营活动平台呢？本文为大家提供一种新思路：利用组件化的方式开发一个运营活动平台平台架构图

平台架构图平台架构说明

mongonDB提供数据存储；Node.js提供平台接口、文件处理等服务；PM2用来管理项目；组件脚手架，为参与组件开发（自定义组件）的同学提供一个快速开始的工具，避免复制粘贴；组件库，构成运营活动页面的骨架；平台，由平台基础功能（页面配置）和N个组件（包括组件的数据项）构成；最终生成一个运营活动页面；平台操作流程

平台操作流程平台依赖的“技术栈”React-前端JavaScript库Redux-状态管理，在所见即所得（实时输入=》输出）的专题预览发挥最大作用ReduxForm-表单数据管理，并负责后台复杂逻辑展示，以及表单配置项的数据联动webpack-项目构建工具Node.js-服务端功能支撑，提供后台数据接口MongoDB-数据存储如果需要动态接口（平台不能提供）支持，放到组件预览的实现部分即可；开发一个平台组件

一个组件就是一个完整的NPM包，基于此，任何FE同学都可以独立开发一款自定义组件，只需要发布到私有NPM（当然也可以托管到github等公网平台）即可。

除了NPM所必须的package.json、用于组件开发的webpack/postcss.config.js/.eslint/.npmignore配置等文件之外，通常一个组件通常由以下几部分组成：config.json-组件默认配置，用于组件初始化数据，包含类型、名称、分组（tag）、开发者信息、默认样式、支持终端类型等；thumb.jpg-示意图，用于用户选择添加组件时的组件预览；src/components/ConfigForm.jsx-组件表单配置；src/components/Preview.jsx-根据ConfigForm的数据配置、动态接口拉取数据，实时预览组件的呈现（见下方效果图，该图片组件中，用到了RD提供的图片上传接口）；src/dev.jsx、src/preview.jsx、src/config.jsx-本地开发组件时的入口（webpack中的entry），根据dev/production判断入口文件是dev还是preview/config；如果是生产环境，会生成dist/preview.js和dist/config.js两个文件，在运营平台下添加组件时，会读取组件打包的这两个文件；src/dev.scss、src/main.scss-开发环境的样式和组件的样式，打包后，会生成dist/config.css和dist/preview.css实现效果

实现效果webpack配置注意事项output中要指定umdNamedDefine为’true’，否则打包出来的文件在平台中import时会报错生产环境下，要指定externals，将react、react-dom、redux-form、react-redux等依赖包排除，以减小和优化打包文件体积css-loader中，开启modules模块，并将process.env.npm_package_name加入localIdentName配置中，如此打包出来的css文件中的class名称包含了组件名（而组件是不可以重名的，否则也无法publish到相同npm平台上），结合hash:base64:10，为css的class名称避免重复提供更多保障；在运营平台项目中管理组件

运营平台需要为有权限的用户提供组件管理的功能，包括新增、升级、禁用组件，新增组件时，根据组件的唯一标识package_name来判断组件是否存在。另外，如果是发布到私有npm平台，可能需要判断组件名称是否合法：私有npm包名往往会以@xxx/开头，用于区分私有npm包和公共npm包。

升级组件-原有组件如果进行了版本升级（在私有npm中发了新的版本），需要在平台组件管理中进行组件手动升级。

组件升级带来的好处：假设新版本组件中存在bug，未采用新组件的线上运营活动不会受到影响。但也有个弊端：假设旧版本组件有bug，修复后，线上引用了有bug版本的运营活动需要手动发布。所以，平台需要提供根据引用组件检索的能力，且最好提供批量发布的功能；平台中动态引入组件

在一个运营活动中加入一个组件时，如何动态引入已有组件呢？以配置文件JS为例，注：convertName是对组件名字的处理结束语

最近，中台的概念吵的比较热。笔者以为，中台存在的最重要意义就是降本提效。以组件开发的形式，开发运营活动平台，可以由FE主导，节省很大开发成本，符合降本提效的初衷。大家如果有更好的开发思路，欢迎留言交流。

作者简介武明礼：58本地服务FE负责人。