关于前端框架的思考

Posted 2021-04-05 servicecomb

多年之前有个朋友让我说服他的一个刚入门的JAVA开发转做前端， 最终未能如愿，他撂下了一句话“我宁愿花8年时间成为一个合格的后台开发，也不想10年以后还在写页面”，虽然说他对前端了解不深，却也道出了前端之困境。前端重复劳动颇多，需要解决的琐碎细微问题太多，而价值却难以充分体现，毕竟前端所做的事情只是锦上添花，而后台数据层是不可或缺的命脉关键所在。至此，矛盾已经体现，前端不可或缺，前端在重复自己，前端难以积累沉淀，前端太需要成长。然而，马克思说了，矛盾即一切事物发展的动力，矛盾会推动前端技术的发展。

从个人经验来看，对于前面所提到的矛盾有一个已经被证明的可行方案就是积累自己的前端框架，注意，此处所提框架并非jquery之类的类库函数，而是“framework“（关于框架的定义在四人帮的设计模式中有比较经典的描述）。技术的积累和沉淀在框架中体现，公司的开发者基于框架协同开发，可以使用现有的框架构建自己的应用，在应用中的积累和沉淀再反馈回基础框架。如此，一个公共的框架提供了一个可以不断伴随业务演变的技术平台，开发者之间的交互变得高效。然而，光有正确的价值观没有实际可操的方法论，又有何意义？何况。。。

我们从头构建一个项目系统的时候，往往是集众人之期待，紧迫的工期目标，人力资源可能处在人来人往的变动中，前端需要各色人等通力合作才能构建出一个中级复杂程度的业务系统。有坚持，有妥协，有苦劳，个中滋味非经历过的人无法感受，如同创业之初，无数期待于一身，而后各种时间，精力，人员变动种种限制，有人会放弃，有人漠不关心，有人选择主动离开，然而项目要继续，总要对得起自己更要对得起一同奋斗的人吧。业务不能停，前端每天要处新页面，提出给我一个月的时间构建一个前端框架，也许只能是在适合养老的大公司才敢有的奢望吧。然而，刚才说了，要想10年以后不再重复自我，前端就得舍命一搏，注重积累，框架必不可少。在实践过程中，有以下一些思考（我知道这时候上帝一定在笑，凡人的思考往往是自寻烦恼而已），权当是给自己留下一点痕迹吧。

1. Don't repeat yourself. “明日复明日，明日何其多。我生待明日，万事成蹉跎”。我们在构建新的项目的时候，最不提倡的就是随便去网站上找个插件，往页面上面一放，ok，任务完成了。然而，后面再修改和完善的时候发现，根本是脆弱的难以维护的项目。比较正确的做法是首先看看，框架中是否已经存在相同的UI实现，如果已经有了，拿过来进行优化（注意的是不要去修改之前的接口），完善好了之后在代码里面添加注释，并添加到组件demo库中，以供后人参考。如此重复下去，积累一个完善的UI库也是水到渠成的事情了。

2. 他们即我们。我们在构建框架的时候，往往发现最困难的并不是自己写的逻辑和样式，这些只要花时间研究，倒也是可以完成的。难的是如何与后端开发，设计，项目经理进行沟通。其实，最重要的是大家要有“全国上下一盘棋“的觉悟，在此提出”他们即我们的概念“是为了说明，最终项目的成功与否，跟大家的协作是无法分开的，尤其在想构建一套前端框架的情况下。对于后台来说，遵循统一的接口实现，对于前端框架是必要的前提条件。譬如，一个分页的列表，后台各有各的实现，这个列表怎么做成即插即用的公共的组件呢（当然，也可以提供一个解析返回数据的函数，这会增加复杂度）。

3.滚动的石头不长苔。技术不一定越新就越好，新的框架在概念和模式上可能是汲取了前人的经验，然而在不了解框架本身解决的实际问题的情况下，光凭一些新颖的概念和名词就盲目跟风，往往会让自己一直停留在API使用者的角色上，很难有更深入的理解和提高了。

4. 重于内而不重于外，勿为名所累。知其然而知其所以然，对新框架的理解深刻，即使框架不能满足业务的需求了，也能够举一反三，自己去动手修改框架，积累自己的框架。没有人比你更了解自己需要什么，只要能够不断吸取新的思想，不断去改进和封装框架，积累一套自己的框架不是难事，因此你还会对JS和CSS有更深入的理解，有了问题也可以快速定位，开发新功能也会得心应手，从而有更多时间去思考如何去优化了。

5. 创新 －－ 守旧 之辩

大浪淘沙，留下来的不一定是金子。前端各种作死的概念翻新，各种新框架层出不穷，选择合适的框架不仅仅是玩具式的尝鲜，更要考虑的是团队之间的协作和稳定的性能以及业务开发过程中的积累沉淀。创新固然是好事，然而像重装电脑带来系统变快，然后丢失很多重要的基础构建，重新再装一遍QQ，360，办公软件，开发软件等等，并非明智之举。done is better than perfect，对于目前的前端资源紧缺的情况下，保护每一次技术栈上的投资，尽快从技术细节中脱离出来，更多去关注性能和安全。

6. 前端团队之价值 

疑人不用，用人不疑。技术流派，百花齐放，文人相轻，自古而然。前端团队拿出来的是一整套的解决方案，必定有技术层面的考量，更有人力资源的权衡，倘若无法形成公司层面前端技术栈，最终公司技术团队将会沦为一些英雄主义者的过场，表面各司其职，实质上低效重复比比皆是。

7. 穷则独善其身，达则兼济天下

业务代码开发同时，将技术积累和共用方法与具体业务分离，在做业务的同时形成框架雏型，当业务没有那么忙的时候完善框架，以帮助下一次项目开发提供技术积累，如此良性循环下去乃是正道。

8. 解耦和同构

紧密耦合不利于分工协作，往往导致互相扯皮，不能做到并行开发。而前端的代码复用更是必须之举，反复无常的设计和需求，导致前端资源白白浪费，无法专注于前端应该做的事情，最终人疲马乏，项目歇菜。不注重技术本身的积累，不但导致前端本身的提高无门，也导致项目开发不能提高效率。

总结：

 前端开发已经不是一个简单的页面编写过程，而是一套工程化的流程，如果能够不断钻研基础知识，不断深入去理解一些概念，才不会疲于奔命的跟风新框架，才能真正达到知其然而知其所以然，登堂入室，成为前端专家。否则，对所有框架的一知半解往往让前端忙而无获，忙忙碌碌虚度光阴了。