尝试做“无线研发工程师”有感

简介: 开始着手写这个文章的时候,心生感概,好像终于在业务上阶段性的理顺了一些事情和代码。可以挤出那么一点点时间写写自己这一两个月以来的感受了。 前段时间一直在业务压力中,熟悉代码,改代码,堆代码。甚至都没来得及好好的想想业务的加分项,包括可做的更有价值的事情。

开始着手写这个文章的时候,心生感概,好像终于在业务上阶段性的理顺了一些事情和代码。可以挤出那么一点点时间写写自己这一两个月以来的感受了。

前段时间一直在业务压力中,熟悉代码,改代码,堆代码。甚至都没来得及好好的想想业务的加分项,包括可做的更有价值的事情。
原因就是因为组织架构的调整,我们从前端职能走出去,接手了一整块业务。从前到后,从客户端到服务端。
而我个人作为团队的领跑者,作为从“前端”走出去的同学,一定是要先行在跨端跨栈这件事情上的。以便给团队同学铺好路,让大家都能更轻更快的过度到新的“业务职能”中去。

回头翻我在组织架构调整后第一周的周报,有这么一段感慨:

“英雄不问出处”,我们是无线研发工程师

这次组织架构调整,前端团队垂直到业务线,更多的不应该是人从一个大的前端团队划分成好几块,汇到业务线上做小的前端团队,那一点意义都没有。而应该是团队形态,职能,人的心态一起的变革与升级,技术取向从业务出发,技能拓展从人出发。

“前端”这个词在这次调整之后,对于我个人,对于团队而言,都不再那么重要了 。我自己到今天为止,做了将近6年的“前端”了,说没有情结,或多或少都有一些。我也自认在“前端”这个领域上有一些认知和沉淀,然而时不我待,无线时代的迅速崛起,端侧越来越重的体验和功能,都在开始挑战着当下的技术分工。

我说,要求我们走出单一职责,甚至摘掉“前端”这个title的人,不是老板,而是这个时代。

Web2.0在PC的时代,一个网站,所有的业务几乎都承载在浏览器上,泛泛而谈,技术上无非两种人,“前端”和“后端”,基本就能Cover掉整个业务的实现。
然而无线的时代,移动设备App的崛起,OS和平台的差异,导致同样一个业务,简单的看,需要四种技术人才来支撑,“IOS开发”,“Android开发”,“前端开发”,“后端开发”。

且不说时间成本,人力资源成本从2个变成4个都会是一个巨大的包袱和挑战。集团不是说我们的人才策略从“平凡人做非凡事”变成“非凡人,平常心,做非凡事”了么,既然我们自命“非凡”,那必然要求我们可以承担的更多,所以,技术栈的拓展,无论从时代还是集团策略来看,已经是必然。

挑战往往也预示着机遇,我本来还有些偏执,说趁着这次的调整,干脆把自己和团队的职能titile摘掉,不再是“前端工程师”,而是“无线研发工程师”。

然而转念,英雄不问出处,路是要靠自己走出来的,团队的转型也不是我一个人的转型,整个大的无线技术团队也都需要做“端”的融合这件事情。在“事”的维度我们已然做了不少尝试了,Hybrid,Weex等等,是时候在“人”的维度做些“融合”的努力了。

Title已经不再重要,时间会证明一切。

到今天为止,总算也是完成了在IOS,Android客户端一个完整的功能性需求的迭代,服务端能力也随着业务的bugfix,feature的更新有新的迭代和发布。至此,我上周在周报里面说,终于标志着我们从前端走出去的小团队有了完整的无线技术栈研发能力。

回头看IOS和Android

不得不说,顶着压力学习的过程是痛并快乐着,这跨年的一个多月以来,我经常说自己有好长时间时间没有过这种每天都看得见自己技能和知识的成长的这种充实的过程了。
每天都有新的输入,有新的知识入账。这是以前做“前端”已经好长一段时间无法得到的体验了。

然而痛苦的点是我在得到这种知识输入的快感时是顶着业务风险和压力的,在我不熟悉的领域,我会像一个新人一样对一个需求能做到什么程度,需要多少时间没谱... 同时作为一个业务的技术owner,还不得不背负业务需要快速迭代,使劲往前跑的责任。

这是我巨大的压力所在。

所幸通过一个月时间的磨砺,通过一个完整业务需求的迭代,基本算是理顺了包括IOS,Android在内的业务代码和研发流程。
对端上技术这个领域似乎也有了更广度的认知。

从前端的角度来看,客户端IOS,和Android也有很多看似相似的地方,年前在做技术大团队的“前端技术栈培养”课程的时候,我大概理了一下端上方案的一些共性:
screenshot

不得不说编程,或者是UI构建,在某种程度上都是通的。甚至让我想起了在学校时代做MFC编程,原来UI的世界都是这样八九不离十,瞬间让我觉得端侧技术的世界变得好小...

同时也会发现,前端的世界和客户端比起来,有太多美好的地方,但是也有太多糟糕的地方:

  • 前端的同学们拼死拼活做工程化这件事情,做到今天,感觉颇成规模,但是对比起IOS环境,完善度和规范度瞬间感觉是战5渣
  • 前端同学们拼死拼活做的各种组件化方案,基于React也好,基于Vue也好,感觉终于可以做到声明式,可嵌套,内聚解耦... 但是Android的layout和组件方案似乎天生就有这种feature...

前端的不足让“前端”这个领域在一步步往“软件工程”这个方向走的更近。

然而前端在UI构建调试的即时性是客户端开发同学们心里永远的痛。

  • 保存即更新,保存即可见,这在Web领域已经是常态。然而在客户端,特指“手淘”这个庞然大物背景下。每次代码的更新和调试都是心里的伤。尤其是Android...
  • 我经常开玩笑说在Android做业务的同学,估计有一半的时间花在了打包上面 :) 。 大家可以想象改一行代码需要打包2~3分钟才可见可调 这种感受么?

能力最大,责任越大

业务职能垂直化这件事情,我相信我们正走在一条对的路上。对于我们过往的“前端同学”,是一个挑战,也同样是一个机会。

当我们抛开了职能的概念,当我们具备了业务所需的所有研发能力。那我们对于业务会有更好的判断和归属。有更顺更合理的方式做新的尝试和创新。

当我们从技术上能整个Own一块业务的时候,我们要想的就不再是怎么去支撑PD或者PM同学的需求了,而是怎么让这块业务跑的更快更好。并且我们也有了能力和责任去让他跑的更快更好。

回头再来看 “无线研发工程师” 这个Title,忽然觉得好有使命感和厚重感。在当今移动大时代的背后,我希望有一天我自己和我团队里的同学都能顺理成章的赢得这个Title。

而这一天,我看着,正在到来!

目录
相关文章
|
8天前
|
新零售 JSON 物联网
振南技术干货集:制冷设备大型IoT监测项目研发纪实(7)
振南技术干货集:制冷设备大型IoT监测项目研发纪实(7)
|
3月前
|
人工智能 安全 大数据
回顾2023,网络研发2024再起航
回顾2023,网络研发2024再起航
|
人工智能 自然语言处理 机器人
|
传感器 存储 监控
工业企业物联网项目实施经验分享
物联网的实施很复杂,互连设备和IT服务的集成在网络、通信、数据量、实时数据分析和安全性方面构成了重大挑战。
工业企业物联网项目实施经验分享
|
运维 文字识别 监控
无线运维的起源与项目建设思考
无线运维的起源与项目建设思考
154 0
无线运维的起源与项目建设思考
|
机器学习/深度学习 人工智能 弹性计算
软硬件协同优化,平头哥玄铁斩获MLPerf四项第一
在4月7日发布的全球权威AI基准测试榜单MLPerf Tiny中,基于平头哥玄铁RISC-V C906处理器的软硬件联合优化方案,取得了全部4个指标的第一。
395 0
软硬件协同优化,平头哥玄铁斩获MLPerf四项第一
|
传感器 存储 人工智能
带你读《创新之巅: 未来十年重构商业的六大战略性技术》第二章传感器和物联网(IoT)2.1廉价的微型电脑与100 万亿个传感器实现万物智能互连
《创新之巅: 未来十年重构商业的六大战略性技术》第二章传感器和物联网(IoT)2.1廉价的微型电脑与100 万亿个传感器实现万物智能互连
|
存储 弹性计算 运维
夯实信息安全底座,统信软件“云”上跑出加速度
在网站运维方面,由于后端存储不统一,统信软件需要收集Nginx、Apache等服务器以及安全产品等不同类型日志,无法统一采集管理,为数据分析、故障排查带来了不便。为了改变这一现状,统信软件亟需构建一个高效的运维平台,提高IT运维效率。在与阿里云进行深入的沟通与交流后,统信软件采用了日志服务SLS智能运维方案。
445 0
夯实信息安全底座,统信软件“云”上跑出加速度
|
设计模式 移动开发 开发框架
如何成为无线架构师
从毕业来阿里到现在已经有4年了,一直在从事Android开发,从一开始的业务开发,到后面负责部分架构工作,再到后面作为ICBU无线Flutter的架构师,虽然不是我们Android技术栈架构师,但是对无线的架构还是有一些感想。另外看到集团内部好像没有关于无线架构的文章,私以为无线架构和后端架构还是有些不同的,所以在此抛砖引玉,希望大家共同交流探讨。 无线架构师职责 --- ![image
243 0
|
存储 机器学习/深度学习 传感器
智能实验室:物联网如何彻底改变研发
通过启用IoT的智能实验室收集数据可以消除研发中的人为错误。
454 0
智能实验室:物联网如何彻底改变研发

热门文章

最新文章