前言:一点对于前端框架设计的浅显思考

1 自我介绍

先做个简单是自我介绍吧,性别男爱好女,伪文青的中前端爱好者。不算上学时候写的代码,做前端已经近6年,两年半到三年的时候第一次技术瓶颈期,也是在那个时候开始梳理个人的知识体系地图和前端框架设计能力。

写这个系列水文主要是出于几点原因:

  • 量化前端框架设计的理解:完整的梳理且量化一下对前端框架设计的理解,同时让朋友和同行进行指正批评。
  • 补全技术知识地图:从框架设计角度对自身的技术知识地图进行补全和更新。
  • 分享、交流:对其他正在前端路上的朋友进行一些经验的分享。
  • 给自己的技术路线按一下暂停键

2 关于前端框架设计

我最早理解的前端框架设计,应该是15年左右,生态中的各种库开始进行模块化重构。开始接触到了commonJS、AMD、CMD那些模块化方案,也接触到了像requireJS、grunt、yeoman等服务于工程化的工具。

当然所有的系统或语言,开始进行模块化的原因都是实际需求中,应用的体积越来越大和复杂度越来越高,单纯库的抽象已经无法满足当下应用的低成本开发和维护工作。

2.1 什么是前端框架设计?

前端是服务于用户的,所以能影响到用户粘性的好的用户体验愈发重要。页面要足够快,要有细腻的动画和骨架屏等机制,要有高效的交互和合理的信息结构,也要有尽可能低的学习成本和使用门槛。

前端同时也是面向开发人员的,对于以上,前端开发要足够简单,封装的组件及逻辑库要有足够的弹性(API要全,且学习成本要低),开发的工作流要一站式,后期的维护成本要低,用时还要有机制去支撑产品的迭代和升级。

所以我们框架设计主要是为了解决低开发成本和高要求的用户体验之间存在的矛盾。这里提到的框架不是一个或多个库的集合,也不是像目前主流SPA应用框架的技术方案,而是针对开发人员服务的具有应用(产品)完整生命周期流程的解决方案。

2.2 我们为什么要进行框架设计?

首先的疑问是,前端生态中已经存在很优秀的且适合不同体量和不同能力技术团队的单页框架,如angular、react、vue,我们为什么还需要进行框架设计?

  1. 单一框架并不是最优的选择:在一个业务覆盖面足够广且面向用户、终端形态足够复杂的团队(公司),并不能一个单页框架就解决你所有的技术诉求,在不合适的交付应用进行错误的框架选型,反而会提升你团队的开发成本。

框架要根据应用特性和体量选择:比如,足够简单且对性能、流量有很高要求的的页面就可以用多页的解决方案。

框架也要根据业务需要进行选择:C端的应用可以根据业务场景(是否考虑小程序等)进行多端编译框架或react Native等方案的选型。

框架也要考虑开发团队的人员能力和学习成本等。

这里不赘述选型,后续会有专门的文章。所以没有最优秀的框架,只有适合的框架。没有哪一个框架能够完全满足你团队的技术诉求,但你可以组合和优化,定制一套服务你们团队的最合适的解决方案。

2、生态中的框架并不能够照顾到你项目或产品生命周期中的每一个环节,比如:

  • 版本管理:版本的语义规范、版本的灰度、版本的多环境切换等。

  • 源码管理:源码的组织形式和更新流程、规范。

  • 团队协作:团队内人员开发的协作方式,团队间同项目的开发方式。

  • 持续集成和发布。

    ……

    等等等等。

3、解决方案不够全面:目前开源生态中的这些单页框架,本身还不能解决大型应用本身的编译过慢的问题,也不能更好的支撑多团队间的协同。

随着应用体积足够庞大,且团队关系足够复杂的情况下,我们往往更需要一个定制一个符合自己团队的规范化的微前端解决方案。

综上已经从技术必要性上简述了我们要在开源生态上进行“画蛇添足”的部分原因。那么从不同涉众的角度考虑,框架设计解决了哪些人的问题?满足哪些人的利益?换言之是技术研发如何服务于涉众的?

截屏2021-06-16 下午7.42.46.png

2.3 什么是好的框架设计?

我认为好的框架设计一定是基于你的目前的人员能力模型及水平,结合你团队或公司的业务形态和体量基于开源生态进行组合优化的全流程的解决方案。如同上述2.2中的第一条,框架本身没有更好,只是适合于不同场景不同体量。

那么什么是你框架优劣的评判标准?如上2.3中,在满足从开发人员、公司到用户的利益诉求,就是好的框架。

那么如何量化框架好的贡献?可以通过一些可估算统计的指标如“节省了开发人员6000小时的开发时间”、“缩短了运维人员300次的部署成本”、“对开发人员的300条框架诉求进行了优化升级”等等,因为不是本文重点,这里不做过多的阐述。

2.4 需要哪些基本的能力和经验?

能继续往下读下去的你一定具有基础的webComponent的基础封装能力和一定的工程化经验,且对于生态中的各种解决方案有一些较为深刻的理解。

具体的能力模型,后续文章我会分别以自己的能力模型和生态中的 RoadMap 进行基于自己浅薄见识的探讨。

而框架设计实际需要的能力模型不会这么庞大,团队的业务场景及团队规模会部分决定你需要拥有的能力模型广度和深度。

3 关于系列文章的目录结构(暂定)

1、前言:一点对于前端框架设计的浅显思考

2、前端技术研发人员的能力模型

3、如何进行前端选型?

4、如何画好一个前端框架图?

5、如何进行前端框架推广?

6、关于开发人员支撑形态的见解

7、如何根据用户(开发人员)反馈进行框架优化?

8、前端框架用户体验方向的思考

9、专题1:前端自动化解决方案

10、专题2:前端研发流程下的权限控制

你可能感兴趣的:(前言:一点对于前端框架设计的浅显思考)