前端组总结

前端组

其实在内部咱们叫大前端，公司名也不报了，妈妈说要低调，嗯嗯！

体系

不一样公司对边界的定义都不同。咱们对界线的划分主要分为，是否影响了用户可交互，可操做的体验，效率须要高（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 前端、大数据、爬虫~~