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

2017-02-25 | 分类 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)相关外围技术都需要投入人力和时间进行研发与积累，并且短时间内没有收益)