和前端小姐姐合作后，她“破防”了

yemusn

之前一直是独立开发，没有什么协作经验。这次接了个项目，主要是做 Web 和微信小程序的后端开发，于是找了一位前端小姐姐合作。

合作了几个月，最近前端情绪很糟糕，甚至有点“破防”。今天找我聊了很久，一顿输出。我举几个例子：

判断订单归属问题
前端在要判断某个订单是不是“我的订单”。
我主张：对比订单的 wechat_id 和全局保存着当前登录用户 id 对比，相等则是自己的订单。
但前端觉得这样处理复杂，为什么后端不能直接返回一个字段，比如 is_self，让她直接用这个字段判断。
我觉得，反正前端也需要if is_self ，这和 if order.wechat_id == my_id 区别很大吗，而当前用户的 my_id 是全局信息也很容易获取。（ps:这里内部后台不需要担心id泄漏问题）

审核数据对比问题
有个场景是审核时需要显示数据的变更情况。我接口返回了原始数据和修改后的数据。
我主张：前端需要自己对比两者，不相等的就是发生了变化，然后展示出来。
但前端的诉求是，希望后端直接返回一个字段，比如 has_changes这种boolean字段表示有变化，同时再另外加个字段带上具体的变更内容。也就是说，前端更倾向于后端把所有数量准备好，拿到直接渲染。

在讲这些具体问题之前，前端还提到我没有和人协作的经验，之前自己开发习惯了“随性”，这导致她在和我合作时非常不适应，觉得“和我对接是最恼火的一次经历”。
她认为问题在于我不够考虑她的开发习惯，而她自己和很多后端合作过，没有遇到类似的问题。她的总结是：“是我的问题，她没问题。”

我的初衷很简单，在不影响数据安全性和完整性的前提下，尽量把一部分计算任务转移到前端去处理。
后端直接从数据库处理数据直出，少量应用层逻辑计算，这样能够更高效地利用后端资源，尤其是内存。这种设计原则，我在独立开发时也是这么做的。

前端对我的做法很不满意，认为不符合她的开发习惯，而她的习惯是后端返回尽量直观的数据，让前端不需要再去判断或计算。她觉得，我的处理方式很失败，完全不如她之前合作的后端。

这让我有些无所适从：

到底是我的问题，还是我们的协作方式需要调整？
后端是否真的应该尽量直出数据，让前端不需要再计算？
我甚至不好意思提，后面还有个更复杂的功能：数据大屏需要连接 WebSocket，前端需要自己在浏览器维护一个订单列表，根据服务器传来的碎片数据进行更新、校验 checksum，并自行判断是否刷新、根据分类拆分和合并数据。

现在我非常困惑，可能是我确实不太懂协作，想听听一些建议或解决方法

zhiyang3

虽然没做过这个。【下面均为个人观点，友好讨论】
但是前后端分离的话，前端的任务就是渲染为主，附带会有点计算，大部分都是接口只接给到最终计算结果。 后端做各种数据的校验工作。api中尽量不涉及隐私信息，能后端计算都在后端处理。

在不影响数据安全性和完整性的前提下，尽量把一部分计算任务转移到前端去处理。
不太认同这个观点。因为一些东西你没办法保证不会泄露隐私数据。后端的任务就是计算处理。尽量不把计算任务给到前端。

后端直接从数据库处理数据直出，少量应用层逻辑计算，这样能够更高效地利用后端资源，尤其是内存。这种设计原则，我在独立开发时也是这么做的。
貌似不需要考虑后端资源占用，而且这些简单计算也不会占用太多配置。

可能你之前自己做全套的时候比较随心吧，但是为了安全性，计算还是在后端为好，前端只做渲染工作。几乎不参与计算。前端校验会有风险。

而且你这两个案例来说，可能减少了服务器的运算力，但是增加了带宽消耗，传递的参数值太长。

前端的页面，因为是组件开发的模式下，如果单个接口能直接返回是最好的，否则的话就要：
1、考虑走你的多个接口拿数据（带来多余接口请求）
2、缓存部分数据（数据变更就出问题了）
前端尽量不要耦合进去太多的业务逻辑，以避免出现的代码泄密风险
但是常规的业务判断是肯定要有的，不可能前端什么业务都不接触，否则这个前端就比较低级

至于你最后的那个东西，前端肯定不能做，至少在我之前的公司这个业务是不能做的（做出来的东西如果有bug，前端需要改了之后重新发版，上线，CDN缓存刷新，如果是已经有的页面、填写的数据、暂留的页面均会失效；但是在此基础上，如果是后端更新，用户可以几乎无感知，不影响正在做事的用户，所以项目经理BOSS-服务端老大直接定的前端不参与过多业务逻辑）

“在不影响数据安全性和完整性的前提下，尽量把一部分计算任务转移到前端去处理。”

我关注的更多的是, 尽可能把逻辑留在后端完成。 因为从分工角度, 前端没有那么的深入业务。在我关注的现象中, 后端能理解数据含义、更能把控一些意外情况。 根据观察也确实是后端cover这种场景比较多

上面仅作个人看法。