为什么在传统软件公司无法推广React-Native

| 分类 blog  | 标签 总结  React-Native  | 浏览  
前端杂谈

写在前面的话

笔者语

本文是结合笔者自身的经历以及个人有限的见识进行分析的。可能由于个人的视野局限会有一定的以偏概全现象,因此,如果有描述不当之处,可以留言指出,大家一起进步。

题纲

  • 传统软件公司的特点
  • 传统软件公司的技术现状
  • React-Native(Weex)技术简介
  • 推广React-Native(Weex)的成本与收益
  • 为什么在传统软件公司无法推广React-Native(Weex)

传统软件公司的特点

这里仅是以点见面,以偏概全的举例,便于下文更好分析而已,并不是就意味着在批判传统软件公司(笔者也自认为没有这种资格,它们能存在,并且好好的存在,显示是有它的理由的)

以何为生?

每一个公司都需要有自己的盈利模式,才能养活公司那么一大票人。那么传统软件公司一般是以什么为盈利模式呢?根据笔者自身的经验,总结如下:

  • 核心收入-做项目,项目的个数以及每一个项目的金额大小决定了全年的收入
  • 严重依赖-客户资源,资源与人脉很重要,有资源决定着是否能拿到大项目,决定着能做多少有盈利的项目

人员分布模式

上文有提到,传统软件公司的盈利核心是依托着已有的客户资源做项目,那么基于这种盈利模式,会有什么样的人员分布情况呢:

  • 管理层(功能不用赘述了)
  • 商务人员(作用十分之大,客户资源大多都是靠能说会道的他们打通的)
  • 项目实施(数量很多,主要作用为不同项目中客户与开发人员的沟通桥梁,以及一些项目相关繁琐事宜,在传统公司中,他们一般担任着项目经理(传统公司中是很少有产品经理这个概念的,一般它的工作就被项目经理以及开发负责人分摊了))
  • 开发人员(大多数为项目业务开发人员-进行着项目的代码堆砌工作,小部分为框架人员,负责者写出给业务开发使用的框架)
  • 测试人员(项目上线(完成)前的测试工作,不过传统软件中,大部分测试人员还需努力…)
  • 其它(比如每个公司都有的人事,行政等等)

项目开展流程

项目是传统软件公司的盈利核心,以下简要介绍下项目开展的流程:

  • 项目前期(前期需要商务或者相关人员去拉需求,找到那些有需求的客户(或者是客户自己有项目需求),确定后就可以立项了)
  • 项目立项(立项后一般就会设立一个项目经理角色-一般由实施担任,负责管理整个项目)
  • 项目开发过程(具体的项目开发,代码堆砌工作,具体就不详细描述了,大概就是不同开发人员的分工,根据需求完成项目,最后测试等等)
  • 项目上线(或交接),完成项目后,客户确认后一般就是项目上线或者交接工作了,完成后就算是暂时告一段落了
  • 项目后期维护,正常的维护阶段

一句话概括

以业务为核心(主要是需要广撒网,拥有更多的客户资源,更多的业务路线),由大量的底层代码堆砌人员堆砌出大量项目,从而达到大量的盈利。

传统软件公司的技术现状

由上文中可以看出,传统软件公司中的技术主要是为项目服务,因此技术力量比起互联网公司较为薄弱(因为大部分这种批量项目都用不到高深的技术,不用完美的用户体验,不追求极致的优化)

开发人员现状

传统软件公司中,开发人员一般有如下特点:

  • 开发人员比例占比不高(当然是相对的,比如笔者第一个公司的人员一共有接近3K,其中软件开发人员接近1K,而这其中又大部分都是业务开发…)
  • 业务人员占比过高,核心技术人员较少(譬如,1K的开发人员中,从事核心技术的寥寥数十人,大部分都是业务开发,代码堆砌)
  • 门槛较低(譬如,里面有很多培训机构出来的速成人才,其中甚至有不少是非本专业的0基础转行人士,“几乎没有”看到过985以上的科班人士(这里并不是学历歧视,只是陈述事实而已))
  • 技术氛围较弱(这里面的技术敏感度是要远远低于互联网公司的,大多人都在无穷的业务堆积中)

前端技术现状

差点又偏题了…本文的核心话题是传统软件公司中推广RN的话题,因此先介绍下公司中的前端技术情况(以笔者经历为主,存在以偏概全现象)

  • 技术落后于时代(在ES6+自动构建工具已经开始全面盛行的时代,这里面还是传统的JQ开发或者Require.js一些过时的模块化开发)
  • 有历史包袱(如上,有大量历史沉淀下来的技术包袱,比如JQ等,导致惯性很大,很难转弯)
  • 人员良莠不齐(由于客观原因,存在大量的专业技术能力较弱的人士,可以想象下大都是一些小白,并且一年,几年后大多还是“老白”的场面…)
  • 技术氛围较弱(这个原因很关键,大部分人只是在完成任务,混口饭吃,能较好的完成项目就不错了,更别提新技术的追求了)

现存的APP开发模式

笔者经历的这家公司中也是有移动APP开发的,模式如下:

  • 开发模式为混合开发(也就是传统的Hybrid模式,这种模式是比较契合这类型公司的,门槛低,开发迅速,不追求极致性能)
  • 批量产生业务型的项目(与开发产品不同,这类业务型的项目追求的是开发速度,性能损耗只要合理就行了,并且最大的优点是,只需要懂一点前端知识,会使用js api就可以了,可以最大程度上的利用开发人员资源)

试想,如果推行的是一项有门槛的技术,那么势必会将一部分人拦在门外,人员利用率会低下来(当然,走精英路线不会存在这个问题,但这又与实际公司情况与方向不符合)

React-Native技术简介

正主来了,React-Native这门技术已经很成熟了,具体这门技术是什么,原理是什么,相信网上有很多的资料,这里就不再赘述了。这里主要进行一些分析对比(顺带会介绍下Weex)。

核心理念

React-Native的核心理念是:

  • Learn once, write anywhere(也就是一次学习,多次开发,而不是一次开发跨平台运行)
  • 组件化开发(基于React的概念)
  • 用JS写原生代码,最终渲染的是原生UI(完全抛弃了HTML,采用JSX语法,与H5开发已经不搭边了)

以下是Weex的理念:

  • 跨平台开发(一套代码,多个平台运行,当然了,实际情况下会遇到不少坑)
  • Vue的语法(最新的Weex是支持Vue语法的,很简洁,当然了实际用在Weex仍然是会遇到很多坑…)
  • 原理和RN一样,最终渲染成原生UI(但是只要遵循一定的语法要求,是可以用HTML部分语法的,比如DIV,CSS什么的都支持)

个人感觉,Weex在设计上吸收借鉴了RN,实际开发过程中,Weex这一套方案是更容易上手的,但是奈何现在Weex仍然不够成熟,社区什么的都太坑了…

外围技术

RN和Weex技术都是一个体系,与现存的传统HTML+JS开发模式有所区别,依赖于一些其它技术前提,譬如RN的技术栈一般是:

  • React
  • React-Router
  • Redux
  • Node.js
  • Webpack
  • JSX语法知识
  • Android,iOS原生语法(因为需要直接用JS写出原生代码)

以下是Weex技术栈:

  • Vue
  • Vue-Router
  • Node.js
  • Webpack
  • HTML,JS,CSS语法(Weex中大多采用Vue的写法就行了,前端比较容易平滑过度)
  • Android,iOS原生容器(不需要写出原生代码,写出Vue代码即可,但是需要一个原生容器方便调试,一般由专门原生人员提供)

可以看出,不管是Weex还是RN,都依赖于Node等一系列前端技术栈,基于前端工程化构建,但它们两直接较大区别是RN需要直接写出原生语法,但Weex不需要,因此RN大部分都懂原生开发,而Weex业务开发人员理论上来说可以不。

当然,实际经历下来,发现它们要求开发人员有一定学习能力,一般这种前端人员都会懂些原生的…

React Native(Weex)与Hybrid对比

优势:

  • 性能高于Hybrid应用,体验接近原生(比如Hybrid的一些显示边界问题,响应慢问题,首屏渲染问题,RN,Weex就不会有)
  • 能做到一些H5无法实现的功能(H5中很多强交互性的功能是无法做到,否则体验太差)

劣势:

  • 学习成本高(RN,Weex开发需要掌握一系列技术,开发人员至少也要掌握React(Vue)思想,其中底层组件开发人员要求更高,而Hybrid模式人员要求相对较低,开发时更是只需要一个前端人员掌握两个api就行了)
  • 开发效率低,组件化开发固然便于复用提高效率,但是组件需要积累,当刚起步或组件太少时开发效率会很低
    • 当然了,技术积累足够后,开发效率会有明显提升(当然前提是技术积累足够…)
  • 跨平台开发的坑(RN不能跨平台,Weex虽然能跨平台,但是会有很多坑,比如Web模式下经常会出现各种不兼容问题)
  • 质量存在不可控现象(譬如Weex或RN中某个功能出了bug(Github上应该就能看到一堆的bug),这时候只能向官方提Issue,等待官方修复(要不然自己该底层编译源码么…),当然了RN相对成熟点)
  • 维护成本相对较高(相比H5来说,RN或Weex更多的依赖于官方的SDK,譬如SDK升级后的维护工作是很恐怖的,就好比RN的频繁升级造成的问题,Weex .we升级.vue问题等)
  • 实际案例少(虽然官方都推出了已有案例,但实际上真正完全依靠这些技术做出的完整项目又有多少,现阶段并不一定就适用于所有项目)

当然了,上面列出的劣势竟然比优势还多这只是一种视觉上的错觉而已。实际上,光是用户体验那一条就已经足够选用RN或者Weex方案了。

还有一点要提到的,很多人都吹嘘RN或Weex完全替代原生,笔者个人认为现阶段还不可能做到,毕竟都是基于原生的,但是部分替代Hybrid确实可以做到的,比如Weex方案更成熟点后,熟悉Vue语法的人完全可以很轻松的转过来。

推广React-Native的成本与收益

对于一个公司来说,一项技术不管多么的先进,不管被吹的多么天花乱坠,但是如果对于自己没用,那么就没有意义。任何技术最终的目的都是要应用于实际的生产环境中,而不是一味的追求“所谓新技术”。

毕竟适合才是最好的

从客观来分析,RN与Weex对于实际环境会有两种影响,一种是需要投入的成本,另一种是实际能产生的收益。

成本

  • 学习成本(相关的系列技术栈,对于技术较弱的人士来说是相对比较昂贵的)
  • 推广成本(推广时,由于很多人员会心里上拒绝学习更难的知识,以及部分人员学习起来或比较慢,可以预测会遇到重重阻力,主要在传统公司内部较多)
  • 基础技术积累的投入成本(在一些技术技术积累足够之前进行大规模的RN(Weex)开发是不现实的,因此RN(Weex)相关外围技术都需要投入人力和时间进行研发与积累,并且短时间内没有收益)

收益

  • 开发出来的项目(产品)体验更高(一般这是一个最主观也是最重要的原因)
  • 技术积累的提升,像RN(Weex)的一些外围技术栈,如Node.js,本身也是很热门的技术,积累下来后,整个团队的技术层次会有一定的提升
  • 对外宣传方面能更有“技术品味”(外界很多都关注那些潮流与所谓的“技术品味”)

为什么在传统软件公司无法推广React-Native

终于回归到正题了,前面提到那么多都是为此刻的分析做铺垫,那么为什么在传统软件公司无法推广RN(Weex)呢?

不急,我们先看下RN与Weex适合什么样的团队,不适合什么样的团队。

适合与不适合(有更新)

适合团队:

  • 适合初创团队(这类团队没有历史包袱,容易转型,而且这类团队一般会走精英路线)
  • 技术积累足够的团队(这类团队技术积累足够,研发人员爬坑能力比较强,而且一些基础技术往往都已经具备,比如Node.js技术栈)
  • 想要迫切技术转型的团队(这类团队可以去尝试下最新的技术)
  • 对批量产生的产品性能有要求的(原生不适合批量,H5性能瓶颈)

总的来说,需要先投入一定人力进行研究,进行技术积累,然后进行小范围试点,最后再进行推广。

不适合团队:

  • 历史包袱太重的团队(严格来说也不是完全不适合,但是这类团队不能急着转型,而是需要迭代式投入人力,小范围试点,否则可能会造成大问题)
  • 人员良莠不齐的团队(这类团队有一个特点就是大部分人员的技能并不能达到一定的水准,这样的话就算小范围试点成功,最后的推广,后续发展也会有问题)
  • 技术追求不足的团队(同上,新技术是要担风险的,也可能会不实用而被淘汰,如果能用就好的心态,那还是慎入)
  • 不追求性能优化优化体验的(任何技术都是需求驱动的)

如果团队中确实“新手”较多,技术水准较低,那么强行推行起来可能会有不小的代价。

为什么无法推广

笔者个人的观点是:(有更新)

  • 人员良莠不齐(技术薄弱,学习起来较为困难)
  • 大面积推广困难重重
  • 不完全契合公司的模式,强行推广会存在风险(这是最重要的一点,前往有总结到的,适合的才是最好的)

或许是此阶段的技术还不大适合于此阶段的“公司”吧,但技术是会发展的,未来总是要与时俱进的,或许到了那时候,真正实用的技术,在此类“公司”中推广下来也是没有问题的。

写在最后的话

本文仅仅是笔者个人对自身的一段经历的总结与感慨而已。笔者第一份工作就是在这么一个传统软件公司中,现在看来谈不上好与坏,只有适合与不适合,毕竟这么多的传统软件公司都活着,活的好好的,并且有越活越好的趋势,所以它们的存在必然有它们存在的道理。

最后,还是感觉有必要稍微表露下,我其实还是有那么一点技术追求的~~

附录

原文链接

https://dailc.github.io/2017/02/25/traditionalCompaniesCannotPromoteRNAndWeex.html

上一篇     下一篇
Lichun Dai

Lichun Dai

程序员,偏前端。会点口琴和吉他。

博客 60 项目 2 随笔 103

GitHub 5sing 知乎 segmentfault 掘金