正文
前端组
其实在内部我们叫大前端，公司名也不报了，妈妈说要低调，嗯嗯！
体系
不同公司对边界的定义都不一样。我们对界线的划分主要分为，是否影响了用户可交互，可操作的体验，效率需要高（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条产品线的应用研发工作
-
自研类的产品（微信预警、微信日报、邮件服务、内部项目管理平台搭建、前端监控埋点等）
监控
监控这块分了3部分：
工程
工程方面，在项目的评审，开发，联调，测试，上线，运营各个环节，我们提供相应的工具支持，以及标准操作流程和文档，从而保证各个环节的产出质量和效率，以及各个环节之间过渡的平滑性。
-
评审。包含需求评审、设计评审、测试评审。
-
开发。包含风格校验、前端调试、服务端调试。
-
联调。根据api自动生成mock数据。
-
测试。提供代码编译、部署，以及仿真环境的模拟（灰度）。
-
上线。同上
规范
规范化主要是eslint、csslint这类工具保证代码的风格，结合我们的团队特性我们也产出了自己的代码规范（每个团队应该不一样，所以不献丑了）。
整体质量的保证是各个组的leader，会定期review项目的代码（主要是忙，2周一次迭代，只能抽时间做）。
