• Comments
  • Comments
  • Comments
  • Comments
  • Comments
  • Comments
  • Comments

前端框架带来的疑惑与是非

说到框架,行业间的人都无数在争执前后端分离的Vue和React,跨平台软件开发的Qt 和Electron,快速搭建整站的高性能解决方案并可满足全栈需求的Nextjs和Gatsby,它们都有各自的职责和特色,整体上都是为了解决一些共同的问题。那作为用户到底怎么去看待?涉及到业务领域,那么相对应的产品的业务框架,到底又是什么?有没有现成的"框架"以供使用?这些问题总是在各种社区充满了战火。

感觉“框架”这个词其实比较泛,它可以是基于Node的工具,可以是一个开发轮子,可以是UI组件的架构,可以是软件架构,也可以是达成业务的一套系统,可以是测试的一套方案。就好比Scrum敏捷开发框架,其实它不是代码层面的开发框架,而是一种遍布生活每个角落的方法论+思维方式+其它影响的综合体。

用敏捷开发的一个重要观点来说,就是永远不可能有“最佳实践”,这是一个不断改进,不断探索,不断尝试,不断革新的过程,只有更好更合适,没有最好最合适。这里的最佳实践其实是一个“上限”,框架也一样,是没有上限的。

同样的,“前端业务框架”,这个框架可以是代码层面的,可以是一种工作流程,可以是一套现成的开发架构,可以是代码层面和工作流的组合,也可以是纯方法论。

譬如Vue和React只是工具,一种手段,不要把它当成是目的。通常处理大型的业务体系,大厂都有自己的微前端架构,从前中后台、前后端分离、组件化、团队协作、不同的编程语言的兼容、发布测试集成部署一条线,这是一个庞大的体系,它并不一定单纯就是业务框架化,当然也可以绑定一些常用业务功能(注册登录、JWT验证、分页、SEO等),很大程度能给业务提速提效。需求不同,一定程度上来说业务代码还是需要去手写的,但是工具、组件和软件架构是可以重复利用的。比如WordPress也是属于一个工具,通过它提供的接口可以实现不同的业务需求,它也可以CD/CI化,也可以vue/react化,使用RESTful API,也可以用于Java环境,也可以直接开发小程序,App。

如果要做套框架,必要的封装肯定是需要的,但是软件设计模式的运用好坏,几乎直接影响了框架的好坏。关乎耦合、维护、迭代、目的、业务实现等方面。

如果你进一家非常规范的大公司,会需要去适应他们的研发体系,使用他们已经成熟的框架,也许你也只需要负责业务代码。如果项目独立性较强,也不是很庞大,完全可以自己构建工具,或者使用现成的第三方工具完成开发部署。

其实说了那么多,无非就是:萝卜各有所爱,在什么地方用什么工具,达成目的即可。

同样的原理,细微的差别,换一个人,换一个公司,可能就是另一套“框架”了。无需较真。我觉得真正要在意的,还是底层的技术和基础知识,任何框架都脱离不了他们,基础上去了,学什么框架都只是看看文档快速上手的问题,当然英语要尽量跟上,因为大多实时文档都是英文的。

如今框架已经非常卷了,开发框架亦是如此,那么设计框架呢?下次再思考一下这个问题。

本文出自没位道 - Chuckie Chang个人网站,转载请保留出处,谢谢!
文章采用 CC-BY-4.0 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。


返回列表  分享

分享给朋友!

微信
微博
文章评论