移动前端架构升级

做者 俊余， 前端界一名小学生。

背景

最近移动前端架构升级，总结一下咱们作了哪些改变。 框架的事情越说越抽象，很难像show me the code 那样直观，除非你也在作相似的事情，不然很难以为有所收获。 每一个公司的组织架构都不尽相同况且是给挑剔的程序员用的框架呢。因此说框架必然是要不断更新，不断优化调整以后才能适应这家公司。

其实新老更迭自己就会带来不少挑战。 看似稳定的一切其实都是能够被替代的，目前的存在只是现阶段的妥协。

• 规范化

若是公司没有本身的docker化平台,那上线要作的事情就是同步。 把须要上线的代码同步到服务器上。 咱们是基于jenkins作自动化部署。主要有两方面的改造，

1. 明确开发&发版流程 咱们主要使用ESLint和StyleLint作强制代码check，git commit hook强制描述规则，文档描述使用markdown git分支规范（gitflow） Commit描述 核心模块CodeReview（人工）

2. 配合运维搭建自动化构建 输出统一目录 使用缩写作统一nginx配置

if ($uri ~ /hybird/(.*)/.*) {
      set $hybird /hybird/$1;
    }
    location ~ /hybird/(.*)/.* {
  }
复制代码

• 前端框架

  除了要解决老系统的问题，咱们还须要作到安全、解耦、可监控、可度量、能够快速发版、组件化、高性能、模块化、可扩展、热修复、一致性、隔离发版、BU化支持……

  团队大多推崇vue，整个技术栈切换到了vue、webpack、Postcss…的技术体系。

  使用选型后的技术体系，如何基于这样的技术选型设计一套能支撑3年（前端的平均寿命 周期可能比这个还要低）的框架呢？首先这个框架必须进行合理的粒度拆解，必须能轻 松的支持纵向功能级分层，横向按照BU分业务线。

  为了提升复用性，按照UI组件、BC组件、页面、模块、前端服务按照不一样粒度层 次进行组合。

• 粒度化

一个大的系统，不管从功能层级角度、仍是从业务角度、都应该能灵活的进行纵横拆 解。一个系统应该能够分为独立的系统、系统中的标准流程、流程中的模块、模块中的 组件、组件中的元素…，这些不一样大小粒度表明了不一样层级的复用性。

1. 页面上的每个独立的可视/可交互区域均可以视为一个组件
2. 按钮、label、panel等无业务逻辑的可视区域抽象为UI组件
3. 包含业务逻辑的信息区域和交互区域，根据业务场景，抽象为可大可小的业务组 件，业务组件能够由多个UI组件组合而成

组件与组件之间能够自由组合；通常状况业务组件会包含UI组件，可是不建议太复 杂的业务组件嵌套业务组件。依赖太深会下降独立性。

页面做为组件的容器，页面的数据适配器负责提供组件化数据，并负责组合组件为 功能完整的界面。 模块也是自包含的，能够独立打包，和其余模块彻底独立，不容许嵌套和功能依 赖。 模块能够和其余模块按照协议组合为一个标准业务流程。