阅读 9

移动前端架构升级

作者 俊余, 前端界一名小学生。

背景

最近移动前端架构升级,总结一下我们做了哪些改变。 框架的事情越说越抽象,很难像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组件,但是不建议太复 杂的业务组件嵌套业务组件。依赖太深会降低独立性。

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

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