阅读 8759

前端组总结

前端组

其实在内部我们叫大前端,公司名也不报了,妈妈说要低调,嗯嗯!

体系

不同公司对边界的定义都不一样。我们对界线的划分主要分为,是否影响了用户可交互,可操作的体验,效率需要高(ps:穷!)

在我们这面对前端的定义是高效率的实现可交互并且高质量的产品。所以我们整体的支撑体系如下:

  • 应用
  • 规范
  • 工具
  • 团队

应用

最终前端这块主要负责前端开发(本职工作)和服务端开发(应用逻辑)。

为了保证服务的高可用,并且能提供靠谱的用户体验,在整个应用这块我们主要做了4件事:

体验。

体验这块主要和设计团队的沟通比较多。设计团队主要负责:视觉规范、交互规范、界面设计。前端团队主要负责:组件抽象、视觉还原、交互还原 。

组件化这块,我们调研了多种方案(其实业内成熟方案真的很多)最终结合各种调研以及我们自己的业务场景我们得到以下结论:

  1. 我们是数据展示为主的业务,所以要根据数据模型来对组件进行建模
  2. 高内聚,解决文件管理的问题,可以快速剥离和替换
  3. api统一
  4. 可独立运行
  5. 业务一致性

基于以上的结论,我们先封装了第一批组件,但是发现整体粒度还是比较粗,UI一致性很难保证,所以我们在这一层的基础上抽离了一层UI组件,用来保障UI的一致性。

命名空间是通过文件夹的方式去管理,每个组件通过index.js来做为出入口。

每个组件内部存在于一个状态组,来对内部逻辑进行控制。

前后端分离

前后端分离分为2块,由于我们的业务数据量比较大,单个接口的速度会非常慢,如果采用后端直出的方案去渲染页面的话,页面白屏的时间会非常长。所以我们采用前端spa,后端自建服务(基于Node.js)。

  • spa

    • 框架选择这块我主要针对几个方面进行调研,社区、是否数据驱动,是否大厂出品,是否支持ie8(或者通过改造可以比较容易适配),团队整体的学习和上手成本(部分同学比较弱),圈定出来的范围其实比较明显angular1.x,react,团队同学一致对大而全的框架比较感兴趣,react在构建大型应用上需要引入太多第三方的包来管理状态,所以最终的决定是angular1.4.7(改动的成本最小)

    • vue是团队内部比较喜欢的框架(不兼容ie8/(ㄒoㄒ)/~~),所以我们在移动中尝试使用,相比于react的jsx,我们更加喜欢vue的简洁

    • 在pc端我们的产品是非常重的数据型产品,所以前端的单个文件会比较大,通过构建工具合并后文件会非常大。所以我们引入了code split的方式,通过路由来切分文件,并且在会在主页面渲染完成后,预加载部分脚本(js、css我们是压缩在一个文件中的),来优化整体的体验。

  • 服务端

    • 服务主要以Node.js为主,部分老系统有python,也有php,为什么要选Node.js呢?
      1. 团队整体为前端团队,整体技术栈以js为主,python和php的同学只有1-2个
      2. 业务相对没有那么复杂,前后端的一部分逻辑是可以共用的
      3. 框架经过封装后上手难度相对较低
      4. 大家对这块的热情比较高
      5. 单方向沟通相对更轻松,效率也更快,ps:主要薪资更高了
    • 业务分2块
      1. 主要负责公司2条产品线的应用研发工作
      2. 自研类的产品(微信预警、微信日报、邮件服务、内部项目管理平台搭建、前端监控埋点等)

监控

监控这块分了3部分:

  • 前端监控

    • 由于我们的主要客户是酒店,遇到问题后,他们内部在远程调试上很难办到,但是有时候会出现用户有问题,我们自己通过账号去复现就很难发现问题,根据上面的情况,我们实现了一套前端监控的体系,用来捕获用户的操作路径和js层面的异常。

    • 主要实现了2部分功能:

      1. 操作路径捕获,每个用户进来后记录用户的每次点击,根据时间和元素,来判断用户的操作流程。
      2. 捕获window.error和劫持ng和vue中的handleerror方法
  • 服务监控

    • 进程和硬件层面的监控比较简陋
      1. 进程守护pm2
      2. 端口扫描
      3. CPU、内存、硬盘监控 上面的产生异常后,调用预警服务发送到对应的用户
    • 在业务代码中部署特殊的埋点,来监控某些特殊的场景
  • 预警

    • 中间件服务,目前只实现了2部分:
      1. 微信预警
      2. 邮件预警

    通过api来接收使用方的预警信息,目前也用在给客户发送相应的报表

工程

工程方面,在项目的评审,开发,联调,测试,上线,运营各个环节,我们提供相应的工具支持,以及标准操作流程和文档,从而保证各个环节的产出质量和效率,以及各个环节之间过渡的平滑性。

  • 评审。包含需求评审、设计评审、测试评审。
  • 开发。包含风格校验、前端调试、服务端调试。
  • 联调。根据api自动生成mock数据。
  • 测试。提供代码编译、部署,以及仿真环境的模拟(灰度)。
  • 上线。同上

规范

规范化主要是eslint、csslint这类工具保证代码的风格,结合我们的团队特性我们也产出了自己的代码规范(每个团队应该不一样,所以不献丑了)。 整体质量的保证是各个组的leader,会定期review项目的代码(主要是忙,2周一次迭代,只能抽时间做)。

工具

框架都是通过业内比较熟知的框架来封装的(前端angular,后端express),

  • 前端主要是实现了命名空间控制,路由控制、根据路由对文件进行codesplit,资源预加载,通用接口和方法封装。
  • 后端基于express自研,api简化,增加路由自动生成,数据库分库分表支持,多人协作,端口自动分配,nginx配置生成,业务分层处理等功能

自动化工具除了大家常规的工具如压缩、合并这类的,基于我们的项目我们自研了项目自动构建,配置自动构建等

团队

  • 分享

    • 团队内部
      • 每周一次分享会,分享人自己定主题,分享人是通过轮询的方式来定。
      • 分享的内容可以是项目心得,也可以是个人情感,也可以是新技术等等(一点节操都没有啥都不限制)
    • 公司层面
      • 跨事业部组织公司层面的分享会,效果还不错,借用了FEDAY的名字(嘻嘻),还有自己的logo衫,当然要感谢老板的支持,以及小伙伴们的热情。
  • 调研/自研

    • 大家都是靠自驱动去造轮子或者研究开发新的玩意儿
    • 最近在关注的新技术
      1. 看graphql,感觉在api这块是下一个爆点,准备在下一个项目中引入。
      2. 据说app的项目要回到我们手里了,最近在看RN,当然也在学一点OC和JAVA
      3. 其他的也会了解一点儿,但是看场景吧,可能过几天就忘了。。
  • 总结

    • 项目。每个项目结束,参与人会分享下当前项目的心得。
    • 年终。每年每人回顾下上一年的得失。

ps:招人啦?liuqing@liluo.me 前端、大数据、爬虫~~

关注下面的标签,发现更多相似文章
评论
说说你的看法