被妹子同事气炸

[yxs19910622]

事情是这样的 我们都是后端 人手紧张今天让我做了个页面 然后妹子做接口 页面中有个地方是三个部门的工作量需要显示 然后测试时发现有个部门工作量显示 undefined 查看接口时发现这条数据只传了两个部门的数据过来 我就问了下 妹子理直气壮的说都是数据库 select 出来的 那个部门没有工作量很正常 你要自己判断然后显示 0 上去 我说你处理下啊 妹子就说哪有后台处理的 你得自己前端判断啊 语气好像我根本不懂怎么开发一样。。。

虽然我不是专业前端 但是我觉着接口就是要处理好数据再传过来吧？ 不过为了避免尴尬还是要问问老司机们 我有没有错。。。

哈哈哈 你们真有意思
周一上班妹子说她处理过了
瞬间感觉自己又蠢又小气 TAT

[jonechenug]

同妹纸讨论这个你就输了

[hhacker]

妹子肯定不温柔也不漂亮
前后端甩锅的事，自从前后端分离以来已经见怪不怪了
这个其实你们都没有错，因为你们的接口没有标准文档，没有人规定妹子必须要传三条数据，也没有人规定你要在前端判断数据

[penjianfeng]

你这样想,妹子估计还会想:这 SB 前端,啥都要我自己处理,你自己不会处理,前端你自己判断一下要死吗?说的我好像不懂怎么开发一样...
到底需要怎么传,协商后就 OK,没有特定的规则.至少我是这样的.
PS: 我前后端都写,api 提供出接口,写清楚文档,扔给前端, 我成前端的时候看接口,如果有需要改的,如果能够在目前基础上实现的,不该接口前端实现. 如果前端弄起来是在太麻烦,我写的接口我自己改了,其他同事写的找那个同事协商.协商时注意语气,没了

[owt5008137]

看协议约定。
最好当然是前端处理，能少一点流量就少一点呗。虽然省那么一点没什么卵用。
讲道理服务器和客户端双方都是要不信任对方数据的格式，然后校验数据内容的，以防升级的时候数据结构变化导致问题。

[mdzz]

看标题还以为是被某妹子的同事气炸

[misaka19000]

然后楼主和妹子干了个爽？

这种东西按道理来说确实应该后台做判断，但是楼主当时没有反驳却自己却生闷气何必呢？要是我的话要么就默默把做了，要么就极力反驳，如果要一直和这种人合作，那么还是换同事吧。

[Deeer]

你需要个 CTO ，评评理

[free9fw]

说实话，女人的思维不太适合做程序，以后文档写好记得

[cxbig]

给前端用的数据最好在后端就处理好

[tolerance]

我感觉妹子没错啊

[jydeng]

我也认为应该后端处理， anyway ，和妹纸就不要计较太多了。

[yangqi]

前后端都要处理

[kxxoling]

看情况吧，我一般是遵循语义习惯的。

[v2mi]

看标题真吓我一跳...
可能是最近恐怖袭击和化学实验室爆炸的新闻听多了

[franklinyu]

@misaka19000 +1 ，建议

1. 当面反驳妹子的建议
2. 接受妹子的建议并且干个爽

[klesh]

这种小事，后端不处理就前端处理一下不是很简单，给 0 或者 undefined 在语义上都讲得通。又不是原则性的问题，别闹到 hr 去。

[Patrick95]

「今天被同事妹子气炸」 ————不漂亮不温柔妹子
「今天被同事妹子萌哭了」 ————漂酿妹子

[introom]

前端处理， unix 原生哲学，如果把后端看成操作系统，那么所做的仅仅就是 provide, provide, provide.在大型项目中，这个认知尤其重要。

[9hills]

你需要有个两边都服的人来定 API

[lxy]

后端处理。要不然不知道是真的数据缺失，还是后端代码运行出错。

[learnshare]

你说的没错，但不要跟妹子争对错

[billlee]

@Patrick95 瞎说什么大实话

[tracymcladdy]

妹子颜值的锅

[BingLau]

后台和前端工作量相加是个常量，看以前常规是谁处理就谁处理

[peneazy]

女人是感性动物，和她们讲道理你就输了

[sneezry]

不涉及到原则的问题，多妥协没坏处，提高能力的同时也搞好了人缘。工作这事有时得往开了想，不要觉得多做事情就是吃亏。我身边愿意多做事情待人特别友善的人混得都不差。

[hpeng]

你没错，只是说话权重低了一点。慢慢协调，实在不行再撕逼……撕不过找官大的一起来，再撕不过就应该考虑下一步了。

[whalegia]

这他喵的，标题去掉“妹子”这个帖子内容也完全成立。。

[an168bang521]

商量着来，但是这个场景下，感觉还是让后端处理好数据吧，不然以后维护起来很蛋疼的；（实在不行，找 leader ，大家一起讨论下）
很多东西都没有说必须前端或者后端做的，都是商量的；
我现在开发的项目里，开始是和后端约定好哪些功能谁来搞的，但是做的过程中，很多时候的有后端小需要的时候，我会顺手写一点后端的代码，或者把应该后端做的事顺手弄一下；然后牵上去让后端 review 一下；后端做的开发过程中，也经常有前端的小改动，他也是顺手帮我弄一下；如果该的不对，我再改或者优化下；
不然屁大点改动，都要对方去弄，对方弄好后，自己再获取，然后才能做下面开发，效率太低了；

[FrankFang128]

你们前后分离的人，终于发现这个问题了？

[cuebyte]

妹子说的没错啊，前后端都可以做，看谁做啦。

看楼主的意思好像是因为她是妹子所以应该她做。

[qianmeng]

我就问一个事，到底妹子漂亮不漂亮，不漂亮不要叫妹子，叫 3 分女同事

[maomaomao001]

前端判断一下可以啊～～～又不是多大一件事儿

[wolfan]

其实呐，如果 LZ 长的帅，估计也就没有这个事了，大家觉得呐~

[Akagi201]

让 swagger 拯救你吧, 看看 swagger 的规范.

[pyufftj]

@Patrick95 2333

[liaowu]

然而两个都没有错，开发以需求规范为准，规范没有提的协商解决，总要有一方妥协～假设这事你成功让妹子妥协了，说不定还有另外一个“被前端男同事”的贴子气炸。 233

[ncworm]

楼上说得对。 lz 长得一般

[wizardforcel]

数据库 select 出来的该是空数组就是空数组，没有算怎么回事。

[issues]

涉及到的业务逻辑和数据处理，能后端处理的尽量后端处理，前端给啥显示啥，不做其他特殊处理，这样在客户端资源开销会小点，对于需要多平台的话，则更需要后台多做处理。当然，更好的是有开发规范, 就不用纠结了。

[thinkif]

@FrankFang128
哈哈哈哈哈哈

[Perrie]

@issues
我也是后端妹子- -
我以前一直觉得- -客户端只用处理单个用户数据，服务端要处理大量用户的数据
所以有些事情客户端可以做就让客户端做 orz
……

[yidinghe]

你改为显示“未知”，然后就可以把锅推给她背了。

[Vizogood]

只怪妹子长得不漂酿(T ＿ T)

[Wenwei]

前后端都要处理，前端需要做一些容错。不然哪天后端抽风了，页面岂不就出错了。。

[wc0517]

看标题以为是 LZ 的妹妹的同事，看了半天没找到第三个人=。=

[guidao]

明显前端做啊。我给你真实的数据，你自己展示啊，就这个还得我给你遍历填充数据?

[likebeta]

写代码没有防御性处理吗？

[LouisGuo]

妹纸也被你气炸了

[panzhougeek]

@Perrie 哈哈，你这个回答给满分。到时候前端代码一堆看不懂的坑。接手的人肯定要骂娘

[zongren]

这个应该后台做，我是处女座
但是话又说回来，前台做，节省服务器啊

[fising]

写代码要有稳定和健壮的考量

[anerevol]

除非有约定。在程序员严重 undefined 和 0 完全是两个东西啊。

[yihan1019]

欢迎来我厂，我厂的妹纸，上得了厅堂，下得了厨房，写得了代码，查得出异常，杀得了木马， 翻得了围墙，开得起好车，买得起新房，知诗书，明事理，兼具高颜值和高智商，不信你点链接瞧瞧： http://job.youzan.com/team

[tabris17]

妹子丑，这是根本原因

[wizardoz]

我觉得妹子说的没错怎么办？
如果我的工作中遇到这种事应该两边都改。但是前端不能因为后端给了一个错误的数据就发生奇怪的事。

[zhiqiang21]

妹纸？一开始就注定结局，你输了呀

[guonning]

想问下楼主男的女的？

[V2Simon]

没有一点协作精神 一个和谐的团队是不会有这种情况的 两边都可以做 如果后端没考虑到 你这边判断下就 完事了 还找人去理论有这时间又可以多写几行代码。

[ByZHkc3]

同前端，这个正常来说谁处理都一样，但是个人还是偏向于后端做下简单的处理。

[wmhx]

应该后端改, 页面展示 0,对业务来说,数据是真的是 0 还是没有数据? 这是 2 个概念, 可以好好商量,让妹子看到你的睿智,说不定妹子以身相许了呢.

[jjx]

前后端都可以处理, 这个要视实际情况而定. 没有一定要后端处理这一说

[dreamcountry]

一点容错机制都没有， low

[hslx111]

一开始没定义好注定要扯皮，不过和妹子扯皮能赢的概率太低了些。。。

[alqaz]

服务端更新数据正确，其他逻辑越少越好，这个是数据显示，感觉还是不要后端做了

[cjyang1128]

不管怎么样，你这边也不应该显示 undefined ，要做点容错

[xiaonengshou]

无论怎么和 api 工程师对接，都得做容错处理。。。。

[dearmymy]

后端的锅， undefinde 和 0 是两个概念。当然前端得处理下。

[Ouyangan]

别和妹子吵架 , 呵护她!

[watzds]

应该前端处理，后端只告诉你没这个数据就行了。谁知道前端显示“ 0 ”还是“无”还是其他什么

[zenxds]

为了健壮性前端还是最好判断一下， var data = response.data || []; 鬼知道后端会不会突然给你搞个坑

[aitaii]

应该整理出来一个接口文档,大家都认同的.

[cheng007]

这就气炸了。
前后端分离啊，这完全不依赖对方的。

[itabas016]

论程序员的修养～

[jarlyyn]

如果数据为空，返回为空后端没什么大问题。

相反的，数据为空前端显示 undefined 而不是空白， 27 前段有非常大的问题。

说明是不做处理直接拼字符串，分分

[jarlyyn]

分分钟被 xss 打穿

[muziyue]

妹子要是好看你早就自己处理了

[Loop680]

长得漂亮标题就是被妹子蠢萌哭了

[alqaz]

后端主要职责应该我觉得主要是验证前端发送的数据的合理性(正确性),然后处理逻辑，更新数据；至于前端请求的数据，如果所有的都在返回给前端之前都要做在客户端表现形式上的转化和处理，这做的也太多了吧。

[chairuosen]

我觉得可以这个字段为 Null ，但是不能缺这个字段

[harker]

我觉得是后端判断更合理，不过你和妹子争，你就输了，遇到这种事，只能节哀，忍忍吧，不是什么大事，你判断也一样啦

[contractswif]

@muziyue 似乎，有道理

[admol]

我觉得和妹子同事没关系，换成一个男同事也可能那么做。接口开发就不要轻易相信别人传给你的数据，不管别人是否有做检验，自己再检验一下还是极好的，不然坑你没商量啊。

[lnkn]

开个小号把这篇文章抄送给她

[qhxin]

不管后端有没有给这个字段，前端都不应该出现 undefined ，因为你面对的是用户，不是后端妹子

[skywatcher]

一个人前后端都写就不会出这样的事了

[lincanbin]

破事这么多，这个谁做都一样，协商好了就行了。
各有各的优劣。

[toono]

同事的妹子气炸了🌚

[poke707]

又到了安利 graphql 的时候了

[PureDark]

前端确实应该做容错，但是后台需要返回有一定规范的数据这有问题？
有三个数据就应该返回 3 个数据，数据库里没记录就返回 0 ，保证至少 API 返回的数据数量要一致，这是后台的基本素养吧

[fhefh]

是萌妹纸不

[JoanVon]

需求是要显示三条数据的，那后端肯定要做好处理，这种撕逼很常见，当前端发现问题，要做修改，希望断绝此类问题，希望后端处理，后端不干，明明可以在最开始就能规避的问题，非要到出现问题了，再想怎么处理。。。很多时候还是前端妥协
妹子不愿意改就不强求吧，哥们处理下呗
或者就不规定显示数据，后端只返回有数据的条目（那就要改需求咯~）

[pncltp]

只要工资给的高，不在乎谁处理数据😀

[bramblex]

一定是写 php 的

[jarlyyn]

@PureDark

0 和空是一个概念么？
除非有特殊约定，不然前端可以把空显示为没数据，未取得数据，相应数据不显示

后端怎么可以强行显示 0 呢？

[honam]

1 、妹子肯定是不漂亮，不然楼主不会因为这事吵
2 、需求有点奇葩没数据还得显示啊
3 、一般后端传什么数据前端只展示，不做过多业务逻辑

[Balthild]

没有标准接口文档你们吵个球………

[hstdt]

接口文档没约定好，她也没责任，你下次就知道要先定好这东西了。


虽然我是前端，不过我们这边关系没这么僵啊，多大点事。

[PureDark]

@jarlyyn 看数据类型啊， 如果“工作量”应该是一个整型或者浮点，那肯定有一个默认值，一般都是 0 ，如果应该是一个字符串，那么默认值要不是 null 要不是空字符串，总之一定是要有数据的
比如如果是用 json 格式返回，那就算是 null ，也应该返回["部门 1 工作量","部门 2 工作量",null]
如果因为没有数据就可以随意减少接口返回数据的“数量”，那岂不是可能有["部门 1 工作量"]，["部门 1 工作量","部门 2 工作量"]， []或者干脆因为 3 个都没有数据直接返回空？

[PureDark]

@PureDark 不对，我例子举得不好， json 的话没有就相当与 null ，没有区别、、 算了你理解我大概意思就行了……
还是尽量避免 null 的出现