写给产品经理之前端是如何展示后端数据的

Posted 2023-04-25

参考技术A

移动互联网的迅猛发展让移动APP呈现出爆发之势，这两年更是移动开发程序员的春天。

今天的互联网上充斥着产品与技术的撕逼。也许你会问产品经理到底要不要懂技术？由此引申出，产品经理到底要不要懂设计？产品经理到底要不要懂运营？产品经理到底要不要懂市场？产品经理到底要不要懂业务？这所有问题的来源都是大家对于产品经理的工作认识不一致。

每个人心中都有一个产品经理的定义，产品经理在技术方面更多的是去统筹和规划。不是画画图写写文档就可以了。这里面更多的需要的是对逻辑的梳理和拆分。
例如很简单的一个app内嵌发红包的活动，产品经理需要确定整个活动的流程。从用户进入页面的那一瞬间就应该被产品经理掌控。他的每一个步骤，每一个操作会带来什么结果，有哪些变量会导致活动进程失败，这些都要产品去考虑。等到活动逻辑和过程全部梳理完成，下面就要进行拆分了。还是以发红包为例，红包中金额是客户端写死还是服务端进行计算，红包领取资格需要服务端返回几种结果，每种结果对应客户端的提示是什么，用户领取红包以后服务端需要记录那些信息（帐号，uid，领取时间，金额，是否使用等），客户端哪些地方需要加入计数器进行数据统计。总结起来其实就是，产品经理需要根据开发的每一个环节，将所有内容分类整理，并分发给不同部分的开发进行研发。最后，还需要给测试准备好check list，当测试按照check list测试完成以后，才可以上线。

以上种种都需要产品对前端如何显示后端数据有一个清晰的认识才能规划好数据如何展示。是APP写死呢还是后台返回，在用户任务进行的时候有哪些可能case。只有搞清楚这些，产品才能在实际的开发中掌握好整个项目的流程与进展，才能不被开发给糊弄。

简单的说，前端仅仅将后端返回的数据展示在页面上，不做过多的逻辑处理。前端需要关心的是，数据如何更好的展示出来，页面效果如何做出来，以及其性能问题。
而后端就是负责对这些数据进行处理，提供给前端展示。

前端一般有H5、android、ios等多端界面。数据不要轻易写死在前端里面，不然到时候三端都要修改，费时费力。而将这些变化多数据让后端进行处理，前端将这个数据取出来显示出来就行了。

举个例子吧，下图是一个美团app首页团购的展示效果

上方美食等8个icon一般为固定展示栏目，非特殊情况不会修改。那么前端一般是写死在app中，等到需要更新的时候更新app即可。

而下方猜你喜欢是一个列表，该列表数据经常变化，数据写在服务端维护，app取出数据进行展示即可。

首先，前段对页面的展示是分两步走的。
第一、在本地绘制好界面，当然此时未连api会填充一些假数据，或写一些默认值。
第二、连api进行数据获取，将数据填充进界面。

既然如此，咱们简单看下前端拿到的数据到底长什么样的吧。
现在前端获取到的数据基本是json数据。

不需要特别懂里面每一个的含义，只需要知道，前端通过"title"这个键名(key)就可以拿到"合辑护甲"这个值(value)。 "title": "合辑护甲" 这一整个就是俗称的一个字段。通过该字段前端就可以获取到列表的标题了。当然这个列表只是简单的展示用，还有诸如图片地址、优惠信息、已售份额等信息没有提供，这就是缺少字段的情况。
前后端就是通过这样的一个定义获取/传递数据的。

考虑到后期拓展、需求变更等，一般来说，涉及到计算的、可能有变动的，一律不要让前端来弄。
还是刚才那个例子，在刚才那个列表中有一个“立减5元”的橙黄色tag。
这个tag信息，如果考虑不充分，比如说，后端只提供一个数字5，然后前端在其页面写死“立减x元”，x为填入后端提供的数字，颜色固定为橙黄色。这个如果需求不修改还好，如果后期需要新增一个“满20减5元”的红色tag不傻眼了吗？
到时候只能通过升级app来解决，而且不升级的老用户将永远看不到这个红色的tag。
所以说，考虑到程序的可复用和拓展性，需要产品将后期可能新增或变更的需求考虑好，和前后端进行沟通，让前后端设计好实现，尽量降低程序的耦合和硬编码。这才能使一个产品更加健壮以及让苦逼的程序猿少加班的关键。

那么刚才那个tag的需求如何设计才合理呢？
首先是tag显示文字，全权由后端提供，可以是多个字段，由前端进行拼接。然后是tag的颜色，提供几种样式让前端判断是一种可行的办法，但是直接提供tag的色值给前端的这种方式无疑给前端展示增加了无限的可能。
是不是也要增加一个tag形状的字段呢？
俗话说，过犹不及。tag形状这种东西真的很少变更，字段太多无疑会增加开发的时间成本，而且会让人有一种舍本逐末之感。

前端获取到后端数据后，如果前端不主动刷新重新请求数据的话，这个页面的数据在该页面销毁前会一直保持不变。

如何理解？
首先，第一次进入一个页面，该页面数据为空或默认数据。此时前端会链接api请求数据。数据请求完成后，填充进页面。那么本次联网请求就完成了，在前端不进行二次数据请求之前，该页面会一直保持本次请求的数据。也就是说，就算服务端修改了数据，前端此时是不能事实的进行更新的，因为我前端不知道你数据更新了。

那么在这个需要实时更新页面数据的时候和前端讲这种需求会被前端直接回绝：“做不了”。这个时候产品咋办，怪怪妥协？最后背锅的还是自己，而且自己也不知道是真做不了还是假做不了。

实时刷新也不是不能做，只是做的成本略高，需要和后端进行配合，像微信聊天一样和后端进行长连接(socket)，这样服务端数据变更前端就知道数据变更了。
当然如果稍懂页面刷新机制的话，可以要求前端在适当的时机进行页面刷新，如在页面可见的时候进行刷新，这样用户每次看到的都是最新的数据。也可以让用户主动刷新，如新增刷新功能。

产品懂技术这件事情，不仅会降低和开发同学沟通时的难度和被歧视风险，还会提升在面对开发同学意见时的判断力，会降低被技术团队忽悠的几率。同时，在需要向上级解释技术原因导致变更的情况下，也会有助于说服老板。
“闻道有先后，术业有专攻”，要相信自己所接触的开发团队是专业的，靠谱的，相信开发团队为实现需求所做出的技术方案是合理的，最优的。如果有质疑，可以加深沟通，以合适的方式提出自己的质疑。这里要补充一句的是，这个信任过程是需要建立的，也是会根据团队的表现不断变化的；同理，其实团队对于产品经理的信任度也是一样的情况。
吐槽是没有意义的，关键还是要解决问题。如果觉得产品经理不靠谱，那么有没有进行过深入的沟通？如果觉得开发不好沟通，那么有没有进行过了解，不好沟通的原因在哪里？如果当事人本身确实不可沟通，那么有没有考虑和对方的老板沟通，或者通过自己的老板如实反映情况？吐槽是最容易的，解决问题反而会很难。

前后端的分离

对于大部分应用，已经不需要从后端读取HTML页面或者模板，前端完全可以根据数据自行渲染页面/模板，这样，前后台交互就可以简化为数据的增删改查。利用AJAX技术，实现页面局部刷新，促使了前后台分离的可能性。

那么，如何利用前后端分离开发模式，开始一个项目呢?

1. 产品文档

产品经理会先设计好整个产品的业务模块和流程，并给出产品文档，包括UI交互，流程图，模块划分等等。
这个时候，产品，前端，后端，测试需要一起评审文档，可能需要多次评审才能确定设计方案。

2. 前端提供接口定义

第二个阶段是前后台同时开发时期。后端同学在设计数据库和表结构的时候，前端同学应该熟悉交互文档和整个业务在表现层上的流程，并且根据页面的展现方式，给出合理或者期望的数据模型（一般是JSON数据结构） 。

比如，需要哪些接口？接口API是只读的还是可修改的？接口入参是什么？接口出参是什么？......这些问题，以往都是由后端同学考虑并定义的。但是，实际上，前端同学是最熟悉交互操作的，前端同学期望的API也是最符合页面需求的，当然，如果某个接口涉及到其他业务模块时，它的复杂性可能就无法在页面上体现出来。然而，无论如何，前端同学是应该，也能够在接口定义上提供合理，富有建设性意见的方案。

因此，第二阶段，前端需要给后端同学提供一份接口定义清单。

3.后端给出接口文档，并通过review

阶段二前端同学提供的接口设计清单，毕竟只是建议，真正的接口还需要后端定义和实现。所以，第三阶段，后端需要提供正式的API文档，并且，前端同学参加review，确保所有的API（入参，出参，和HTTP请求方法）都被双方认可。

4. 前后端同步开发

API文档确定后，前后台就能够同时开发了。这时，又可能分为两种情况。

(1) 后端已经定义好接口并且发布，但是，返回值都为假数据，不支持修改操作。前端同学利用已发布的API进行测试。
(2) 后端没有发布任何接口，前端同学自行mock数据（利用本地json文件，或者在线的一些mock工具，比如easy mock等模拟数据），然后边写页面边测试。

5. 联调阶段

当后端业务代码已经完成，前端页面和数据交互部分完成，前后端就可以进行联调了。这个阶段，是磨合期，肯定会出现很多问题，也需要双方协商去解决。

当后台接口变更时，必须同步更新API文档，并第一时间通知前端同学，保证前台接口调用也同步更新。

同时，测试人员可以介入，针对接口进行单元测试。注意，这时只是针对接口的黑盒测试，不要涉及任何UI操作。

6. 冒烟测试和其他安全性测试

当联调阶段完成后，也就是开发人员（前端和后端）认为已经没有bug的情况下，项目再交由测试人员进行冒烟测试。同时，有需要的话，同时安排安全性测试。

几轮测试，几轮bug fixing之后，项目就可以上线了。

小结

可以看到，前后端分离开发模式可以让分工更明确，提高生产效率，加速项目开发和迭代，也能够让API文档化，便于后期维护。