注:本文主要针对以数据展现查询为主的常规业务型的公司,不适用于非常规界面的项目,如游戏、视频工具等。
之前做JobDeer时,我们的整个技术团队大部分时间只有一个人,最多时也就两个工程师,一直运作得不错。除了功能上的节制,技术栈方案的选择也有很大的原因。最近新技术又起来了不少,我也更新一下之前用到的技术栈方案,这里和大家分享下。
初创期是一个业务需求猛烈变动的时期,在这个阶段,任何非业务逻辑相关的开发都是极大的犯罪浪费。所以我个人觉得这时候最佳的方案就是可以自动适配电脑和手机的Web全平台方案。
这点大部分人都知道,但其实要把开发时间和成本压到最低,有很多技巧,这里给一个思路:
首先,直接使用微信作为用户体系(微博更适合用来分享、可能的话预存下手机号,以后做自有用户激活用)。
这样有几个好处:
然后,全站页面通过Responsive设计,同时兼容 PC、手机浏览器、微信内嵌浏览器。
为了达到这个目标,PC端的设计要简单,尽量卡片化。微信内嵌时的导航、分享都和手机浏览器不同,需要识别设备做优化。虽然这样在产品设计时会比较慢点,但做好之后整个产品结构会非常统一,流程会非常清晰。顺便提下,原型工具Axure RP7是直接支持Responsive原型的,很好用。
最后,Web框架的选型上,React优先;Vue、Angular其次;最低也建议要保持接口和前端代码的分离。
就是说,PHP最好只用来构建Rest接口,不要渲染页面,全部页面全部用JS来渲染。你要问写接口用Go和NodeJS行不行,当然行,不过我觉得能完成同等工作的人里边,PHP的最容易招到、也相对便宜。
这部分有一个安全大坑。某些PHP程序员并不熟悉写纯接口,经常把敏感字段返回了。要多盯下。
初创期建议不要过早启动客户端方案,除非对客户端的原生功能非常依赖。原因比较现实,那就是客户端团队是非常贵的,光是一个iOS一个Android就三五万一个月了。而更贵的是APP的安装成本,如果从Web导流到微信公众号的转化率是60%,那么到APP的转化通常在20%以下。
当业务定型以后,你就会发现嵌到别人APP里边还是很憋屈的,而且微信的JS SDK的BUG经常让人无语。另一方面,对融完了一两轮的公司来说,过分依赖微信还是有风险的。需要把各个外围平台上的用户聚集到一个完全属于自己的地方,这时候我们就可以开始做APP了。
坦率的讲,要做一个90分以上体验的APP,原生方案是最靠谱的。但如果你的APP只是列表分页之类的简单结构,Hybrid(混合APP)看起来会是一个更好的方案。
之前我们的Hybrid方案用的是内嵌Html的PhoneGap+ionic,但我并不推荐大家去用这东西。
两个原因,一是在一些比较老机器上,会出现内存不足这种没法绕过的问题,导致经常性崩溃;二是JS在各个设备上的兼容性会让你调到想杀人,别问我怎么知道的。
所以这里推荐的是ReactNative的JS渲染原生控件的方案。虽然里边标签和CSS的语法都很奇葩,但是人家不卡啊,但是人家不卡啊,但是人家不卡啊。
加上如果之前的前端用的本身就是React的话,这时候可以重用不少业务逻辑。现在ReactNative已经可以同时支持iOS和Android,LeanCloud也对其做了 不少支持 ,但在Android上的推送依然需要自己来实现。
之后可能依然会需要iOS和Android的人来开发原生组件,以实现业务逻辑特有的功能。但由于开发的工作量一般较小、而且可以通过组件机制去耦合,所以非常适合直接外包出去—— 好像又能省不少钱。
粗略估计,这个方案应该足够支撑大部分的APP运营到百万用户了。ReactNative这块我只测试了一些Demo,但坑国内大公司已经踩了不少,不放心的同学可以抓来看看。
最后再说一边,初创期方案里边,从技术角度看,PHP换成别的语言是可行的,但用PHP人力成本更低。
当然你能找到一个ReactJS和NodeJS都非常资深的人,那么恭喜你一两年都都不用担心技术方问题了。所以NB点的前端动不动年薪60~80万,那是有道理的……