一转眼的功夫,新公司入职1年零3个月了,也算是成功从一个android原生开发转行到web前端开发了.一些小小感触:

对于开发而言,转语言并没有想象中难.

刚来的时候一度以为是HR给我分错了部门,说好的车联网呢,android车机呢,怎么变成做web页面了?

仅有的一个app还是用那个啥uniapp开发的,不就h5套壳应用么,这种上古hybrid方案我又不是没做过,还是自己开发的壳子.

给招聘的HR打电话了解了下,原来是他搞错了.这就比较尴尬了.

试用期转部门似乎也不太好,那就先从uniapp入手吧.

配环境,拉代码,再花晚上的加班时间看了总共2小时左右的教学视频,差不多就入手改bug了,真棒.

改了几天bug,就开始写新需求,copy一个页面,用改bug的思路去做,居然也做得有模有样.

程序员两大法宝:ctrl+c和ctrl+v,诚不欺我.

没过多久,遇到web前端的一个紧急需求,拉我去支持一下.也是硬着头皮上了,依旧是copy再改这个套路,边改边学.

作为新手,能做的只是尽量把注释都写完整.

说实在的,这种边学边做的模式,带来的是超高的学习效率.
跟前同事调侃:一年的时间就让我看起来像3年的开发经验~~~

原因是什么呢,我细想了下:

• 已经有过一门语言的经验在前,现在学习,会丢掉80%的语言相通部分,关注剩下的差异性部分,无形中起点高了很多很多.
• web前端和原生前端,在渲染这一块,殊途同归,都是基于mvvm和事件驱动,在性能优化和疑难问题上,有着意料之中的精准直觉.

全栈有存在的合理性,但不可为了全栈而全栈.

一向觉得全栈是垃圾的我,如今也算是开启了第二技术栈.
对全栈的观点算是发生了一点点的变化吧:

• 从技术角度,可以为了开辟新视角,便于领悟一些原本就殊途同归的东西而全栈,
• 从管理角度,可以为了扩大管理范围,防止外行知道内行而全栈,但万万不可以为了多做点业务需求而全栈.

还是那句话:人的经历是有限的,各方面都精通的人并不存在.

你可以多学几个技能,但是每个技能都想拿来吃饭,那我只能呵呵了.

有些所谓的”全栈”工程师,前端后端都能做,然而其在各端对应的”不全栈人士”看来,都是”小学生级别代码”…当然我并不是对这种工程师有意见,只是觉得:挺适合小公司的.

在大前端框架领域,web确实比原生优秀很多,但原因是关注点的区别.

最直接的感受:
做android的时候,对mvvm也只是有所了解.但并没有在项目中实施.结果到了web,发现已经是标配了.模板语言在这里发挥得淋漓尽致,比起android开启了databingding的xml都强了无数倍.

web前端开发效率高不是没有道理的.

原因也和关注点有关:
web前端更关注界面上的显示效果,开发人员的开发速度.
原生前端更关注界面的响应速度,软件的功能和稳定性.

• 由于对宿主资源使用能力比不上网页,因此android需要考虑性能优化.
• 由于采取安装包形式,因此android诞生了各种热更新,插件化的黑科技.
• 由于需要对接硬件,android要关注比web多得多的api.

举个例子:
网络库向来是原生开发中很重要的一个基础库.请求参数封装,线程池,连接和读写优化,响应解析,这些都是需要考虑的内容.

在web中呢?集成了常用了axios之后,基本上就做一下返回数据异常的处理就够了.

• 线程池?浏览器已经给你定死了并发量.
• 数据解析?js中可以直接处理json.
• 读写优化?你都接触不到byte那一层.

当然这并不是说web前端没有技术含量,技术含量在开发框架(比如vue这种)和打包阶段.但是前者基本也没有二次开发的必要,后者大多数业务都用不上.

toB的业务相对toC,技术水平差不少.

这是最值得吐槽的地方.
之前的所有工作都是做toC的软件.用户量大,暴露的技术问题也多,产品也有专门的团队,有自己的想法.整个项目的节奏把握得也很好.

嗯,很美好,这才是互联网软件开发应该有的样子.

自从做了toC,一切都变了:

• 用户量:日活100是常态.在这样的基数下,线上指标监控已经没什么意义了.
• 产品:都是用客户说了算.只要能让客户使用,客户提啥要求就做啥.
• 项目进度:还是客户说了算.
• 交互和UI:永远都是最低优先级,无关功能的东西,根本没有人在乎.

toB的软件,在前端侧,用户量已经和技术毫无关系了.

这带来一个很严重的问题:

长期做toB业务的,技能水平几乎毫无进步.

做为当下前端团队的Leader,这是必须要考虑的问题.暂时有了一些方向,不过这个话题就扯远了,日后再写吧.