面向前端的开发同学和团队,解读一个前端架构需要哪些角度去建设和完善,补齐开发同学对技术架构的偏颇认知.
-
架构的本质: 其实也是一种管理,通常我们所说的管理,都是指对于任务和人员的管理,而架构管的是机器和代码.比如说,机器的部署属于运维的物理架构,SOA属于服务架构,那么前端的架构指的是什么?
-
前端的位置: 长期以来,前端所处的位置是比较偏应用层,很薄的一层.而架构需要有深度和广度,所以在前端谈架构很受限,伴随着一些新的技术和概念出现,如Node.js、RN等让前端的范围放大了,慢慢这一层也开始变得厚重.
-
语言的角度:
- 不考虑模块化、工具、压缩优化时, html+css+js上手快,可以快速完成一两个功能简单的页面;
- 规模很小的项目中,技术要素彼此不会直接产生影响,因此无需架构相关的思考;
- 规模到达一定体量时, 要用模块化开发,就必须对应某个模块化框架,用这个框架就必须对应某个构建工具,要用这个工具,就必须对对应某个包管理工具,这个时候,就需要从更高的角度去寻找适合的集成解决方案.
一系列解决问题的工具和手段就是所谓的前端架构.
框架是架构的重要组成部分,架构决定框架的选型,框架决定架构的技术路线,架构围绕框架进行一系列的流程工具建设,从而形成完善的自动化开发体系.
-
框架不等于类库: jquery,underscore,seajs,requirejs等只能称为类库,一套编码框架需要包含一系列元素组成(开发模式、通讯模块化、模板、基础类库)
-
开发模式: 实现代码职责分离,JS的MVC也很多,有的强化M、有的强化C.再比如现在最流行的MVVM,angular、React等,我们是场景需要才把他们纳入到开发体系;
-
通讯&模块化: 组件化是前端在推进开发模式过程中的一个过程产物,为了有效的进行组件隔离和独立,现在有各种各样的通信模型,比较成熟的有消息总线、事件模拟、缓存中转、flux模型等;
-
模板: 集中处理数据往HTML转换过程,在代码行、缓存管理、预编译、运算性能、语法糖提高性能;
-
基础类库: jq、zepto、angular、react等,核心就是为了改善编码生产力.
-
-
框架的选型: 框架的适用场景,团队的技术栈
-
大工程应该尽量避开谷歌产品: 断崖式升级,变数太大,升级成本高;
-
关注应用场景: 是否有历史包袱,是否兼容IE6,是否支持SEO,是否考虑自适应,目前团队规模,产品特性是强内容、强交互或者是游戏性
- 内容型web站点: 侧重渲染方面的优化,前端逻辑比重小;
- 操作型B/S系统: 以数据和逻辑为中心,界面较规整;
- hybrid内置型: 要处理缓存和一些本地接口,包括PC客户端和移动端.既包含原生的代码,也包含嵌入的HTML5代码;
- web游戏: 前端的逻辑重,在代码结构上要求非常高的可管理性和更复杂的设计模式;
- 桌面应用型: PC端混合开发,比如NW,electron,可以方便做跨平台,极大减少开发工作量.
- 没有最好,只有最适合自己,基本上,针对每个平台,我们都可以列出一些主流框架,优先选择团队能够驾驭住的框架;
- 对于引入框架如何尽量延长他的生命力,选择框架时去追求概念,而不是潮流,当现有的架构可以接受新的设计概念时再去考虑引入新的框架,用设计理念的选择代替框架的选择.
-
每个团队都有自己的打包编译、发布工具,用一个列表来描述这个工具链:
- 代码管理->开发调试->代码编译->项目构建->模块管理->配置部署->测试支撑->性能监测->性能分析->安全扫描->规范约束->统计分析->运营支撑
工具平台主要就是围绕我们的研发流程中的每一步关键节点去建设起来的,工具平台是前端工程化的主要生产力.
业界团队提出的各种解决方案:
- seajs开发体系:支付宝团队前端开发体系,以spm为构建和包管理工具;
- fis-plus,百度大多数前端团队使用的开发体系,以fis为构建工具内核,以lights为包管理工具;
- modjs,腾讯AlloyTeam团队出品的开发体系;
- yeoman,google出品的解决方案,以grunt为构建工具,bower为包管理工具;
...
纵观这些团队推出的前端集成解决方案,深入剖析其中的框架、规范、工具和流程,都朝着同一个方向推进,将前端工程化中孤立的技术要素整合起来,解决常见的领域问题.
要从多个维度去不断review阶段成果,包括前面列举的按研发流程中的各个环境,另一个维度从客观list之上再抽象一组分类list,可以让我们发散出新的具体环节出来.
- 代码结构设计的灵活性在前端架构中的重要性;比如一个平台方对接各个合作方,做一套基础模型和标准流程作为入口就很重要,各个合作方继承或覆盖对功能、展示进行重写.便于扩展
需要通过一些维度来思考:
-
假设当前的团队放大10倍,业务复杂10倍,当前代码管理还能跟得上吗?
-
如何避免开发人员之间的开发行为耦合?
-
如何支撑多特性、多版本的并行?
-
主路径按功能、按版本还是按渠道?
-
好的开发规范不会让使用者感到约束,而是能帮助他们快速定位问题,提升效率;
-
开发规范通常是指编码规范,另外可以在放大一些,设计思路、模块拆分、结构分层方面达成一致的规范;
-
最关键的是执行落地,要考虑工具来自动执行或者自动检测,更好的方式是把开发规则条款做成功能,构建的时候去自动执行;
-
流程边界设计是架构设计的一部分,架构层面新的变化将来自于岗位自发的对自身工作内容、职责的重新定义,也就是边界;
-
技术跨界所形成的如服务器直出,h5增强,hybrid,桌面应用这些前端新领域技术越来越多,这个是前端架构的发展趋势,应该鼓励团队结合自身实际情况从不同的方向去尝试探索新的岗位边界,为自己团队的前端架构进化打开新的空间;
-
研发流程的扩展:
- 针对活动开发(繁杂、重复、个性化)特点,需要通过平台化的角度去提升效率;
- 功能管理后台(权限、复杂的配置、重复劳动力)特点,需要通过封装常见的后台组件、标准化运营操作接口格式和规范、统一操作流程和管理后台,基于接口的维度快速在平台搭建想要的管理界面.
- 很多的前端成功技术和成果都来自于对原有流程边界的改造.
- 不同的团队架构模型必然不同,适合团队架构的才是最好的;
- 一个架构还需要有一个统一的牵引力去影响它的成长,这个牵引力就是团队理念.统一的团队理念可以帮助我们在架构演进过程中形成统一的技术选型、解题思路、价值观念.
- 团队理念来自于团队对自身实力、业务特征、业务发展方向、技术挑战点等常识性问题的明确和共同认可.
运营活动类:
- 强运营、体系大、流程长;
- 页面多、活动多、包袱重;
- 能快速构造页面、需要强大的运营支撑体系、清晰可控的前端soa
开放平台类:
- 强运营、活动频繁、跨业务合作多;
- 核心功能少、页面生命周期短;
- 需要低成本的活动开发和管理体系
工具应用类:
- 强功能体验,模块间逻辑交互复杂;
- 强大的UI管理体系,清晰的功能交互设计
技术架构最强大的地方在于控制,好的架构不担心差的程序员,它能把编码带来的风险控制在局部; 好的技术架构需要持续传承
前端架构是指在前端开发过程中用于提升开发效率、质量、性能和可维护性的保障体系
需要有一个完整的闭环:
核心理念->组件框架->代码结构->开发规范->工具平台->流程边界->经验沉淀