前端VS后端

最新推荐文章于 2024-05-17 09:58:14 发布

前端瓶子君

最新推荐文章于 2024-05-17 09:58:14 发布

阅读量244

点赞数

文章标签： java 编程语言大数据人工智能数据分析

前言

对于广义上的前端来说，上游是接口，下游是界面。
对于后端来说，上游是数据库，下游是接口。

前端的工作的核心是交互，消费接口的数据，给到用户。我们分别来看这几个方面:

前端能够抵达的最上游是接口，作为数据的消费者( 或者说使用者)，接口数据是-切功能的根
基,换句话说，你要做多复杂的功能交互，都要在能拿到的数据基础上。而接口往往是后端给出
的，所以在需求评审的时候，前端同学通常就是关注一下界面、组件、交互，反正接口到时候后端
会给出。这也是为什么在开发过程中会有“联调”这个步骤，因为接口经常会有格式问题，缺少字
段等问题。

前端没有接口的决定权，所以开展工作只能从UI出发，再把数据附加给组件。这样的工作流程,就
容易使得眼光局限在了组件层面。按照这个思路往下发展，前端的发展方向就是拓展体验。既然我
无法决定消费的内容，那我只能优化消费的体验了。

但是「用户体验」这个词又被UE的人拿走了，留给FE的好像只剩下设计的还原和数据的接入。

在很多公司近似外包的开发模式中，FE的工作是完成一个个设计稿的还原，至于到了用户那里,效
果如何，是由PM和运营来追踪评价了，下一期改不改,怎么改，也是项目负责人决定。

再说，不改又能怎么样，FE 也不背用户体验和增长的KPI。

所以你看，前端的上游不能被自己决定，下游的反馈常常收不到，收到了之后,自己也不定有能力
决策。

再看后端。后端发起项目的时候，要从建表开始，然后操作业务逻辑，最终产出接[口给前端。
相比于前端从UI出发后端是从数据出发的,前端是数据的消费者,而后端是数据的生产者。而大
多数的业务,都是以数据为核心的。

比如我们做一个业务中台,对于后端来说，能看到数据的结构，如何定义权限，如何增删改查，如
何聚合,如何打散，如何计算指标，这就是「业务」的全部内容。如果我转做运营，可能给个
postman,拿着接口就能上班了。

对于业务中台来说，前端的工作根本就不是「业务」，是对数据和交互转化到U。我做过国际化的
业务，界面都是奇怪的外语，返回的数据代表什么内容我也看不懂，反正数据类型对上了，不报.
错，测试通过了,我就可以去做下一个页面。这个过程中，带着脑子上班和不带脑子上班，看起来
都没什么差别。

神雕侠侣中有这么一段:

洪七公道:“现下我有一套武功传给你。这武功向来只传本帮帮主,不传旁人，只是你义父出言
小觑于我，我却要你演给他瞧瞧。”杨过道:“老前辈这武功既然不传外人，晚辈以不学为是。
我义父神智未复，老前辈不用跟他一般见识。”洪七公摇头道:“你虽学了架式，不知运劲诀
窍,临敌之际全然无用。我又不是要你去打你义父，只消摆几个姿式，他一看就明白了。因此也
不能说是传你功夫。“

前端很多时候的处境就是这样，做了花哨的架势，但是对于数据从何而来,为何如此一头雾水。工
作交接的时候，看到接口就要去猜，这个字段是做什么用的，那个好像又被废弃了。就像挑食的孩
子样，饭是后妈端来的，你只能挑挑拣拣的吃。

而后端同学能看到数据的最原始状态，自然是心明眼亮，看到前端页面的时候，自然知道哪里是从
哪个数据来的，哪里的交互又会写回什么数据。所以的「业务」都落在自己可以掌控的闭环里，自
然理解的快。

理解「业务」是后端必要的工作技能，而对于前端来说，这并不会直接阻塞工作开展。

对于大多数以消费数据为主的业务来说，可以看到完整数据的后端，比起只能看到部分接口数据的
前端来说，有天然的优势。

造成这个局面的根本原因在于，很多的开发流程是从需求给到数据,数据到接口,接口到交互, FE
处于最未端。

如果是以消费交互为主的业务，比如游戏，可能前端反而要比后端更快理解业务。因为业务的核心
是交互，前端掌控着完整的交互，而后端则是提供支持交互的各种数据，反而成了被动方。
此时需求是给到了交互，交互对接口提出要求,接口反推数据支持, FE 位于业务的间核心。

如果贵司业务是一个数据大屏展示， PM提了一系列老板想要看到的数据，FE 同学积极的设计各种
图表方案，然后跑到后端去要各种数据接口，那这个项目