前端组
其实在内部我们叫大前端,公司名也不报了,妈妈说要低调,嗯嗯!
体系
不同公司对边界的定义都不一样。我们对界线的划分主要分为,是否影响了用户可交互,可操作的体验,效率需要高(ps:穷!)
在我们这面对前端的定义是高效率的实现可交互并且高质量的产品。所以我们整体的支撑体系如下:
- 应用
- 规范
- 工具
- 团队
应用
最终前端这块主要负责前端开发(本职工作)和服务端开发(应用逻辑)。
为了保证服务的高可用,并且能提供靠谱的用户体验,在整个应用这块我们主要做了4件事:
体验。
体验这块主要和设计团队的沟通比较多。设计团队主要负责:视觉规范、交互规范、界面设计。前端团队主要负责:组件抽象、视觉还原、交互还原 。
组件化这块,我们调研了多种方案(其实业内成熟方案真的很多)最终结合各种调研以及我们自己的业务场景我们得到以下结论:
- 我们是数据展示为主的业务,所以要根据数据模型来对组件进行建模
- 高内聚,解决文件管理的问题,可以快速剥离和替换
- api统一
- 可独立运行
- 业务一致性
基于以上的结论,我们先封装了第一批组件,但是发现整体粒度还是比较粗,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呢?
- 团队整体为前端团队,整体技术栈以js为主,python和php的同学只有1-2个
- 业务相对没有那么复杂,前后端的一部分逻辑是可以共用的
- 框架经过封装后上手难度相对较低
- 大家对这块的热情比较高
- 单方向沟通相对更轻松,效率也更快,ps:主要薪资更高了
- 业务分2块
- 主要负责公司2条产品线的应用研发工作
- 自研类的产品(微信预警、微信日报、邮件服务、内部项目管理平台搭建、前端监控埋点等)
- 服务主要以Node.js为主,部分老系统有python,也有php,为什么要选Node.js呢?
监控
监控这块分了3部分:
-
前端监控
-
由于我们的主要客户是酒店,遇到问题后,他们内部在远程调试上很难办到,但是有时候会出现用户有问题,我们自己通过账号去复现就很难发现问题,根据上面的情况,我们实现了一套前端监控的体系,用来捕获用户的操作路径和js层面的异常。
-
主要实现了2部分功能:
- 操作路径捕获,每个用户进来后记录用户的每次点击,根据时间和元素,来判断用户的操作流程。
- 捕获window.error和劫持ng和vue中的handleerror方法
-
-
服务监控
- 进程和硬件层面的监控比较简陋
- 进程守护pm2
- 端口扫描
- CPU、内存、硬盘监控 上面的产生异常后,调用预警服务发送到对应的用户
- 在业务代码中部署特殊的埋点,来监控某些特殊的场景
- 进程和硬件层面的监控比较简陋
-
预警
- 中间件服务,目前只实现了2部分:
- 微信预警
- 邮件预警
通过api来接收使用方的预警信息,目前也用在给客户发送相应的报表
- 中间件服务,目前只实现了2部分:
工程
工程方面,在项目的评审,开发,联调,测试,上线,运营各个环节,我们提供相应的工具支持,以及标准操作流程和文档,从而保证各个环节的产出质量和效率,以及各个环节之间过渡的平滑性。
- 评审。包含需求评审、设计评审、测试评审。
- 开发。包含风格校验、前端调试、服务端调试。
- 联调。根据api自动生成mock数据。
- 测试。提供代码编译、部署,以及仿真环境的模拟(灰度)。
- 上线。同上
规范
规范化主要是eslint、csslint这类工具保证代码的风格,结合我们的团队特性我们也产出了自己的代码规范(每个团队应该不一样,所以不献丑了)。 整体质量的保证是各个组的leader,会定期review项目的代码(主要是忙,2周一次迭代,只能抽时间做)。
工具
框架都是通过业内比较熟知的框架来封装的(前端angular,后端express),
- 前端主要是实现了命名空间控制,路由控制、根据路由对文件进行codesplit,资源预加载,通用接口和方法封装。
- 后端基于express自研,api简化,增加路由自动生成,数据库分库分表支持,多人协作,端口自动分配,nginx配置生成,业务分层处理等功能
自动化工具除了大家常规的工具如压缩、合并这类的,基于我们的项目我们自研了项目自动构建,配置自动构建等
团队
-
分享
- 团队内部
- 每周一次分享会,分享人自己定主题,分享人是通过轮询的方式来定。
- 分享的内容可以是项目心得,也可以是个人情感,也可以是新技术等等(一点节操都没有啥都不限制)
- 公司层面
- 跨事业部组织公司层面的分享会,效果还不错,借用了FEDAY的名字(嘻嘻),还有自己的logo衫,当然要感谢老板的支持,以及小伙伴们的热情。
- 团队内部
-
调研/自研
- 大家都是靠自驱动去造轮子或者研究开发新的玩意儿
- 最近在关注的新技术
- 看graphql,感觉在api这块是下一个爆点,准备在下一个项目中引入。
- 据说app的项目要回到我们手里了,最近在看RN,当然也在学一点OC和JAVA
- 其他的也会了解一点儿,但是看场景吧,可能过几天就忘了。。
-
总结
- 项目。每个项目结束,参与人会分享下当前项目的心得。
- 年终。每年每人回顾下上一年的得失。
ps:招人啦?liuqing@liluo.me
前端、大数据、爬虫~~