前言
对于广义上的前端来说，上游是接口， 下游是界面。
对于后端来说，上游是数据库， 下游是接口。
前端的工作的核心是交互，消费接口的数据，给到用户。我们分别来看这几个方面:
前端能够抵达的最上游是接口，作为数据的消费者( 或者说使用者)， 接口数据是-切 功能的根
基,换句话说，你要做多复杂的功能交互，都要在能拿到的数据基础上。而接口往往是后端给出
的，所以在需求评审的时候，前端同学通常就是关注一下界面、 组件、交互，反正接口到时候后端
会给出。这也是为什么在开发过程中会有“联调”这个步骤，因为接口经常会有格式问题，缺少字
段等问题。
前端没有接口的决定权，所以开展工作只能从UI出发，再把数据附加给组件。这样的工作流程,就
容易使得眼光局限在了组件层面。按照这个思路往下发展，前端的发展方向就是拓展体验。既然我
无法决定消费的内容，那我只能优化消费的体验了。
但是「用户体验」这个词又被UE的人拿走了，留给FE的好像只剩下设计的还原和数据的接入。
在很多公司近似外包的开发模式中，FE的工作是完成一个个设计稿的还原， 至于到了用户那里,效
果如何，是由PM和运营来追踪评价了，下一期改不改,怎么改，也是项目负责人决定。
再说，不改又能怎么样，FE 也不背用户体验和增长的KPI。
所以你看，前端的上游不能被自己决定，下游的反馈常 常收不到，收到了之后,自己也不定有能力
决策。
再看后端。后端发起项目的时候，要从建表开始，然后操作业务逻辑，最终产出接[口给前端。
相比于前端从UI出发后端是从数据出发的,前端是数据的消费者,而后端是数据的生产者。而大
多数的业务,都是以数据为核心的。
比如我们做一个业务中台,对于后端来说，能看到数据的结构，如何定义权限，如何增删改查，如
何聚合,如何打散，如何计算指标，这就是「业务」的全部内容。如果我转做运营，可能给个
postman,拿着接口就能上班了。
对于业务中台来说，前端的工作根本就不是「业务」， 是对数据和交互转化到U。我做过国际化的
业务，界面都是奇怪的外语，返回的数据代表什么内容我也看不懂，反正数据类型对上了，不报.
错，测试通过了,我就可以去做下一个页面。这个过程中，带着脑子上班和不带脑子上班，看起来
都没什么差别。
神雕侠侣中有这么一段:
洪七公道:“现下我有一 套武功传给你。这武功向来只传本帮帮主,不传旁人，只是你义父出言
小觑于我，我却要你演给他瞧瞧。”杨过道:“老前辈这武功既然不传外人， 晚辈以不学为是。
我义父神智未复，老前辈不用跟他一般见识。”洪七公摇头道:“你虽学 了架式，不知运劲诀
窍,临敌之际全然无用。我又不是要你去打你义父，只消摆几个姿式，他一看就明白 了。因此也
不能说是传你功夫。“
前端很多时候的处境就是这样，做了花哨的架势，但是对于数据从何而来,为何如此一头雾水。工
作交接的时候，看到接口就要去猜，这个字段是做什么用的，那个好像又被废弃了。就像挑食的孩
子样， 饭是后妈端来的，你只能挑挑拣拣的吃。
而后端同学能看到数据的最原始状态，自然是心明眼亮，看到前端页面的时候，自然知道哪里是从
哪个数据来的，哪里的交互又会写回什么数据。所以的「业务」都落在自己可以掌控的闭环里，自
然理解的快。
理解「业务」是后端必要的工作技能，而对于前端来说，这并不会直接阻塞工作开展。
对于大多数以消费数据为主的业务来说，可以看到完整数据的后端，比起只能看到部分接口数据的
前端来说，有天然的优势。
造成这个局面的根本原因在于，很多的开发流程是从需求给到数据,数据到接口,接口到交互, FE
处于最未端。
如果是以消费交互为主的业务，比如游戏，可能前端反而要比后端更快理解业务。因为业务的核心
是交互，前端掌控着完整的交互，而后端则是提供支持交互的各种数据，反而成了被动方。
此时需求是给到了交互，交互对接口提出要求,接口反推数据支持, FE 位于业务的间核心。
如果贵司业务是一个数据大屏展示， PM提了一系列老 板想要看到的数据，FE 同学积极的设计各种
图表方案，然后跑到后端去要各种数据接口，那这个项目
对于前端来说:
- ”这些地方的折叠是为了更好的展示数据。“
-“根据时间维度展示，能够更全面的看到总体的变化。”
-“随着天气变化，我们会标注不同的颜色，极端天气还能通知到相应的业务负责人。”
对于后端来说:
-“卧槽要这么多实时数据干嘛。
-“第三方天气接口真是坑，还有一大堆天气代码要处理。”
-“你要的这些指标给个公式吧，我拿各个业务线的数据给你算。”
你说这个项目里谁能更好的理解业务?
最后
所以不是要问「后端同学是不是比前端同学理解业务更快」，而应该说，业务的强势方比义务的弱势方理解业务更快。
话语权越大,理解的越快。
决策权越大,理解的越快。
