一个前端的自我回顾

7,973 阅读8分钟

最近潇洒的裸辞了,离开了奋斗了2年的公司,从心里其实还是有一些不舍和遗憾。

还记得当时刚从360出来,于老板和老暴找到我,说是希望我过来帮忙去重新组建一个前端团队。当时定了几个未来需要干的事:

  • 团队搭建,人员重新组织和梳理,找到核心,建立第二梯队。
  • 技术氛围,培养大家的技术体系和氛围。
  • 梳理当前的产品线的流程和规范,建立制度和体系。(ps:当时没有限制技术栈)
  • 如何能加快整个项目的迭代和产出。

团队搭建

团队搭建其实是一个长期的任务,当时我们团队内有5名同学。单独沟通和找周末合作的同事沟通后,技能上大概可以分为2组,A组属于高级,B组属于初级。人员的两极分化还是比较的严重的。从沟通和业务能力上来说也大概是这样的。

跟大家沟通后分了组,1位高级的同学带一位初级的同学,另一位高级带2位初级的同学。

2位高级的同学和我搭伴组成基础建设组,业务接口暂时由我来代劳。

初期整个团队的组织架构大概按照这样的规划来切分开。

基础建设搭建

当时的状态大概有这几点:

  • 公司内统一使用jq来搭建,没有任何组件沉淀。
  • 数据型的业务,需要维护大量的配置来决定页面的渲染。
  • 产品线直接公式和计算方式需要一致。
  • 业务需要快速迭代。
  • 2条收益产品线中多个模块其实是可以互通和复用的。
  • 后期产品线中会有堆积木的方式来组织页面结构。
  • 接口规范各不相同,需要每条产品线都兼容。
  • 编码规范和风格需要制定。

基于这样的要求和状态,梳理出来几条:

  • 需要设计一条完整的组件体系,不止是UI层面的。
  • 最好是数据驱动的框架来帮助我们解决配置影响渲染的问题。
  • 组件直接需要复用,防止功能出现不一致的情况。
  • 组件需要可随意嵌套来达到堆积木的效果。
  • 最好是一个单页面(SPA)来保证页面直接的数据传递和渲染。
  • 接口需要统一成restful接口

框架选项集中在angular.js、react、vue中,由于我们有大量(40%)的用户在使用IE8,所以vue先不考虑了,react其是可以做到兼容IE,但是全家桶下来学习成本其实会很高(团队内部初级的同学会非常吃力),所以我们选择了angular.js。

angular.js提供了指令和service,非常方便让我们来做组件化的封装。

路由的话选用了ui-router,相对原生提供的router更加强大。

根据angular.js、ui-router、以及组件化的方案(后面单独说),封装了一个框架来支持这些。

但是由于需求追的比较急,大概花了2天时间先上线了新框架,主要替换了路由和架子,简单处理把jquery的代码隔离开,避免影响当前的架子。ps:就这样上线了第一版o(╥﹏╥)o

组件化方案

组件化的方案直接上张图吧,文字描述不直观

结构大概是这样的,A业务组件有可能是BC组成。

组件的目录结构是这样的。

以index.js为入口,service为当前组件的状态管理器。

index.js中也包含实际的业务逻辑。接口大概是这样的

其他的都比较直观,model接收基本的配置和当前状态,然后在其中写入具体的业务逻辑,根据这些会编译成指令。为啥这么做呢,其实是为了后期方便切换技术栈。

组件组装解析图

技术氛围

大概干了几个事吧

  • 组内轮换分享
  • 学习目标落实到KPI中
  • 跨BU交流学习
  • 标杆效应
  • 每一个项目完成后会给大家买一部分书(后面没有完全做到)做为奖励

业务提速

组件化方案落地2月左右,整个项目的效率已经从前端逐渐转移到其他同学那里。分析了有几个方面:

  • 服务端业务逻辑可拓展性比较差,没有详细的进行业务拆分。
  • UI设计比较慢,一个页面大概在2天左右。
  • 产品的同学需要些大量的文档。并且高保真是按照UI图来做的,所以绑死到UI身上。
  • 项目必须要等待完整的一个周期完成,才会释放所有的资源。

由于在组件化落地的时候需要后端提供一个resetful的接口,但是其实他们没有提供,所以当时在后端接口中间搭建了一层Node.js 用来做代理。

所以在服务端业务压力比较大的时候前端这面开始往后做了一层,可以抗住业务的压力,并且效率也提升了。

UI这个层面,只需要他们提供基本的结构,我们按照固定的组件实现就可以,提供给产品的UI需要按照组件库中的组件来设计,这样的话UI的设计成本也逐渐提升上来,而且有时间可以给我们提供一些交互的建议,这个很nice。

产品的文档我们只需要相对详细的业务逻辑的文档以及新组件的异常点文档,组件越来越多的情况下,产品的文档其实是一个下降的过程。

跟项目的同学协调之后,前端进入测试阶段,人员会根据情况抽调一部分出去开始新的项目,来保证资源的最大化利用。

当时其实除了这些还有一些其他可以提速的点,但是那些方面其实研发这面可以影响的东西比较少。

Node.js架构图

整体架构图

收益相关的业务会有很多不同酒店的配置不一致,导致相应的计算逻辑不一致,所以抽象出来一层叫做逻辑层。

初期部分产品线的用户中心其实是跟整体的用户中心不一致的,后期其实已经逐渐的靠拢回去。

应用日志和前端的异常日志有一套完整的服务来支撑,但是其实做的比较浅,目前只是满足当前事业部的业务,后期这块会移交给基础架构部来继续支持,也跟我们的尽力有限有关系。

谈谈收获

对接的人从产品研发这个体系,开始接触销售、商务(业务专家)以及客户接触到很多技术之外的东西,可以从技术之外去看整个业务的发展。

参与过预算制定、跟客户的定制化项目、并且参与项目的报价、协调,让自己能深入到其中感受前沿的部门是怎么沟通和运作的。

做为负责人免不了会有背锅的状态,有机会思考和调整自己的心态和定位。

谈谈失落

大量的精力放在沟通和协调上,有种不适感,每天回头看看感觉自己就像没干啥活一样。

从研发的角色转换到管理的角色,对未来充满了迷茫,也看不清后期的发展路径。

谈谈离职

很多人认为离职可能是因为晋升或者斗争,其实还好,于老板和老暴对我都很关照,我们到现在也是很好的朋友,所以不存在的。

只是想自己安静下来,可以想想后期怎么走,人总要在适当的时候停下来看看过去。

谈谈面试

最近面了一些公司,有大厂也有小厂,有过的也有没过的,有我拒绝的也有拒绝我的。

总的来说大家面试其实看重基础,当然其实就那几个方向,看看书应该可以很快补回来,还有就是大部分前端组其实是偏向于客户端这一侧的,目前我的方向其实偏向于后端这一侧。

当然也有好玩的点,有部分同学其实认为架构是UI组件化(╯▽╰),其实真的应该是业务抽象,不同公司根据不同的情况,设计出符合现状的一整套方案,来保证一段时间内资源的消耗最小化。