为什么公司的后端这么懒

一个样，leader 领导不力

前端不调怎么知道是后端问题。。

现在天天陪后端调接口，，点一下一个异常。。

欠怼
多怼几顿就老实了

上 GraphQL 问题就解决了.

看来都没有写测试的习惯

欠怼。换我就这么怼回去
1.我就要一个接口，你怎么做我不 care。我就要一个接口，这是需求吧啦啦啦巴啦啦。我请求多次容易出问题。出问题你负责啊。（除非是全栈，后端程序员一般不知道前端可能的坑，他们质疑，随便怼）。
2.5XX 错误。直接找他们 leader。5XX 错误，你们处理。
3.计算 md5 必须服务端给数据，客户端验证不可行。必须给，不给我就怼的你妈都不认识我
4.继续怼，看不懂。你给我改了，口头说的不算数。时间长了我就忘记了。我们领导要求的。巴拉巴拉巴拉

恩。怼天怼地怼空气，然后你就被扣上了不团结，沟通成本高的帽子。但实际每一步如果是对的。这样被开了何乐不为。。能解决问题和稳定项目的程序员才是好程序员

明显后端的事情 找领导吧

@a494836960 后端不测试就放出来后端背锅。即使不单元测试，也得手动测试吧，后端写的代码依赖前端人肉来测试简直不负责任，浪费前端生命。

你惯的。。。

找领导

为毛。。。我和你是反的。。。都是前端说后端做，后端改，后端的锅。。。

看来我算个合格的后端，不管是 APP 还是 Web 前端，后端能做的事我一般都不让前端去做，能一个接口搞定的就不调两个接口

文档写清，后端测试写全就差不多了，剩下的前端自己慢慢玩。

楼主的话题格式没缩进，不太好

为毛，我们都是前端说的算？要啥给啥，推动改进优化下，忙得很的样子

看人脾气了。以前对接个 ios 开发，有啥问题都先往我们服务端扔，“这个是服务端的问题”。逼得我搞了个对照测试，定位到就是 ios 的问题，他才说是自己打包的问题。。。。

leader 不给力 内部规范不清晰 缺 QA

emmmm,我跟你相反，基本上出错了都是后端在改，前端就写了页面，接口调试还是我做

不过也有那种只要一个大接口的前端，说多了不好处理，我想这前端 promise 都不会用吗，我后端都会。好吧给你一个大接口，然而最后因为业务原因，还是拆开了。接口主要是后端定。

当然，也有很不靠谱的后端。自己在理就怼他呗

因为前端不值钱，人微言轻

不过相反，我们当时出错都是直接找后端，前端也没啥日志记录

这么多前端的吗，我觉得你俩应该换换，你去当后端，他来干前端哈哈哈。

把他的活一起干了就没那么多锅甩来甩去了

哈哈哈，被前端投诉离职的后端

把接口接过来自己干

确实是这样，程序员老油子就是这样，直接怼就完事儿了 这种老油子脸皮厚的不行，不用怕伤他自尊。

前端已凉

因为后端觉得这该前端做

API 前端写，后端去做运维好了
多半是后端人不能自制，团队又缺乏规范

这种还是上 GraphQL 吧

我司也一样。懒。

@a494836960 5xx 的错误后端自己测试都能测试出来。

让后端出一个搜索接口一周了都没弄好，没办法只好递归分页列表接口把所有数据 down 到本地再查找，超长的 loading 菊花像吃了屎一样难受

@sampeng 稳！

给前端之前一般都会直接用 postman 测一下。。。

前面说 GraphQL 的，要是有这觉悟，知道这东西的也不会出楼主说的这些问题。而且看着尿性，说了别人肯定也不会用

思想滑坡救不了

其实这个存在一个设计哲学问题，在设计上如果将后端定义为 M,那么就要提供原子正交的接口即可，前端可能需要处理 VM 和 V 的事情，那么这个时候前端的工作量可能会大一些，但是微服务可能更灵活一些，这个就要取决团队技术栈，项目的期限，人员的配备，做适当的调整和取舍。所以是一个设计哲学的问题，你们的团队评估这个设计语言和大家及时沟通，另外后端同学基本的验证要自己做，不能依赖前端的调用进行测试。这是团队管理的失职

这是欠骂的表现。
不过我们这边后端只负责出楼上所谓的原子正交接口，拼合接口的工作前端 nodejs 层做了。

所以你们为什么要前后端分离呢？

确实欠怼，我都是 xx 这个数据格式你看方便不，不方便的话我改一下； xx 需要需要转化吗？需要的话后端一起转了； xx 需要还差什么数据，我一个借口给你，调用两次太麻烦……

我都是都是收集问题，找到问题原因，解释下为什么，给出修改意见，写成文档，发全组邮件，抄送各个 leader。如果是重复问题，引用之前邮件，继续抄送各 leader。两三次过来，感觉是得罪人了，但是工作进行的顺畅很多。

招个测试吧 随便摔~

哈哈，只能说明后端太弱，接口写完了都没测试。。。

后端不背锅，这个锅得给个人背吧。我后端还说前端呢。。。每次看文档都不看完整，post 方法调的用 get，同异布的问题还找我去查。。

前后端分离就这样的，不然还需要啥联调啊，所以说前后端都懂点的人还是比较好的，可以两边怼，避免甩锅。

跟这样的人搭配干活简直就是受罪

之前的 leader 说过好几次 后端不要把前端当成测试了 先学会自测。。。

拖出去打一顿就好了。打不过就忍着吧

点进来看看是不是我们前端偷偷骂我。

what do you think

第一点我到觉得还好
前端一般喜欢大而全的接口，恨不得所有的数据一个接口都返回了，但是有时候这样的设计是不合理的，所以要分情况。
其他的。。。 确实是后端的问题

看了你的说明深感这个后台的有很多坑，我是写后端的，我碰到公司一个写前端的跟你的情况相反。只要后台能解决的都要给他解决好来(有些很复杂的接口尽可能简单了还嚷嚷)，一个简简单单的 json 都不会，我问他怎么调用方法都不会。js 选择器都要我教（他会一两个标签选择器），一点自学的本事都没有，本来可以百度的一下什么都让我来.调试程序只要出现问题就在公司里喊你这个有问题啊，像调用接口首先得先阅读文档，直接文档都不看想当然，导致整个公司都觉得我很菜，有时候也确实我的程序有问题，但是问题都不看总是说我程序有问题气炸了。

接口我也调过很多次，作为过来人觉得其实有很多因素的，我觉得首先得确认自己有没有问题，先看看文档，有时候没按照文档参数规格也会报错 500，规范的程序会捕捉参数异常信息返回给前台。后台接口怎么样是看前台页面来决定的，也并不是所有接口能合成一个就合成一个，如果考虑到前端近期更换界面或者操作逻辑的话，后台基本是给出一个通用尽量少改动后台的接口为主（我们上面都是这么要求的，而且开发也比较紧）。如果自己没问题的话大可向后台沟通，当初我是菜鸟的时候就是这样，尽量避免互相之间厌烦。

这个东西看人。跟前后端关系不大。

什么样的 leader，什么样的 coder，永远都是上面决定下面

与后端前端无关，跟人有关。当年做后端的时候，所有接口都是测试通过，逻辑连通后才交给前端的。

我也是有什么锅先让前端背着，嘻嘻

典型的研发 leader 不作为造成的, 尤其常见在重业务的小型创业公司

典型的后端做 N 多工作不如前端改个图片链接

很好奇是什么公司

@zwh2698 赞同

不能太现实了

怼...

有些接口可能考虑的是复用，你前端考虑的只是业务，所以就有矛盾。。。

不会连表查询？哈哈哈哈哈哈哈

楼上不知道要尽量避免连表查询吗？

@ycz0926 甚至是后续的扩展
其实，单单实现一个前端要的接口，是很省事的（大不了多个 sql 连表），可到了后期，项目复杂起来了，很多东西都会是重复编码，前期能抽象的抽象出来，不过最好还是不要暴露给前端，再有一个就是，如果写 django 之类的项目，用的是类视图的话，一个功能一个 class （不一定和业务一一对应）
个人的一点见解

这是人的问题，跟前后端无关。

@bestkayle 写 php，很容易这样做，多迭代几个版本，估计连自己都分不清哪个字段有修改，一个业务接口一大坨代码，看到的就是各种注释，维护起来，你就知道痛苦了

都是惯的

所以，学一下后端语言很有必要，方便 dui

看了下，赞同一些观点。接口考虑的是通用复用性 设计灵活性 合理性有时候还得考虑下开发时间，策略成本，能一个接口写完还省事了，前端这里考虑的更多的是少写几行代码前台怎么方便，后台怎么改，后台接口是得考虑下前端，但是也不能因为一己之私少写几行代码影响系统。就比如其他公司要调用你的接口，人家要求为了方便，要求你改接口。改好了然后另外一家公司也要求你改接口，这不就乱套了吗？还有一点就是纠正一下后台能解决的并不是都要后台来解决，这考虑到分工，合理性，人家也没义务什么都帮。所以就要看后台设计规不规范，合不合理，不合理就让他改，合理就是自己不讲究了。

不是后端不改，你前端只考虑一个点，但实际上后台接口错综复杂，要考虑全平台，改了之后你这里是满足要求了，但其他地方可能就出问题了

base 上海 ，之前的后端同事有个是本地的，也是懒到极致、出境界 , 后来那哥们走了我们就不在招上海人了（不要对号入座，因人而异）

打工的都没什么主动性，对这份工作不在意或者说，准备好了下家。

先查出来 XXX 再根据 XXX 查，这个有时候后端还真不一定简单搞定，尤其是大数据

前端大部分时候不用考虑高并发，sql 查询效率，安全漏洞等等，最多就是压缩一下文件尽可能缓存。而后端给你一个接口要考虑到是否合理，是否有更加 OK 的实现方式，以及查询效率会卡死狗 shi 等等。
比如，你让我 java 弄一个集合操作，如果不是特别机密的算法，我更宁愿让前端配合 lodash 去弄，这样也间接减轻了服务器端的负担。

作为一个（伪）全栈我得给后端说几句话：
你要考虑到代码寿命问题。
前端的一行代码，一个页面每过一年都要大改一次。甚至整个业务都会完全废掉。
可后端业务，尤其是和核心数据库相关的业务可是要一直跑下去的。甚至后端语言换一遍，后端开发者换一遍，接口的设计和业务逻辑都不会变化。
你随随便便加个接口，过几个月页面下线不用了。你说我敢不敢把这个接口废掉？我后端如果过几个月想重构下代码，看见一大堆没什么用，功能重复但又不敢删的接口代码（特别是那种“就几行，联合查个表，拼个字符串就行”）的代码，是什么心情。你们前端能理解么。。。

可能是遗留问题。。

@a494836960 兄弟 postman 了解下

我们差不多也是 有问题都是找前端 然后定位接口问题 这里少了什么 那里少了什么字段

怎么说呢 以前我专门做前端 和楼主有一样的遭遇 我就去学写 PHP 了 现在前后端都做了~~ 就差不会设计了 哎~

和人品有关，和前端后端没关系，有的人就是这种嚣张性格，直接和领导说吧

这哥们儿不行啊 我都是恨不得把前端的活拿过来一起给干了…

@ycz0926 #65 实现业务需求难道只是前端的事情？实现一个业务不是前后端都得干的活吗？现在流行业务逻辑得给前端做后端只提供数据了？我记得以前是前端只负责展示，业务逻辑都在后端的啊。

楼上的很多问题通过 dui 都可以解决，当遇到前端希望接口设计成 Github 那样的时候，想怼回去找不到理由，唉

我也遇过类似的情况，后来我就私下自学一下后端，怼他们的时候也更有底气了
后来，发现做后端很有趣的
再后来，发现可以在业余时间从前到后撸一遍了

一般 leader 也是搞后端的，他们后端是一伙的。你不知道么。

有一次，客户说 app 很慢。然后老大就问我。看我前端能不能优化一下。我看了一下，一个 api 请求要 6-10 秒。我就直接把这个问题群发邮件给大家了。然后技术总监知道了就不高兴了，因为他和那些搞后端的是一伙的。

直接给 mongodb 给前端调用就好。

5xx 这点还真说到我的心坎上了。
每次出错，产品、测试全都把问题往我扔，自己调试一看全特么是 5xx 问题。

看来我还算是合格的后端。最近我自己写的接口都加了测试，覆盖率起码 90%。在公司喊了一段时间的单元测试之后，后端这边终于有了测试意识，成功推广了单元测试。。。虽然其他人操作起来并没有那么合理。。
我更倾向于后端只提供一些原子接口，把后端当成数据库查询引擎来用，同时让后端实现一些必须在后端完成的操作（例如安全相关的、设计大量数据库操作的）。
提供原子操作，让前端可以复用接口，提高前端灵活性。
如果前端每一个页面，每一个功能都要提供一个相应的接口的话，那跟 HTML 模板 MVC 的时代有什么区别呢？前后分离的一个重要意义恰恰在于，后端不需要根据前端页面的展示数据来设计相应的数据格式结构。
后来流行服务端渲染，这种大前端的方案，是让前端用 nodejs 来处理服务端与客户端之间的通讯，而真正涉及数据库操作的后端接口是由前端开发者通过 nodejs 来调用的（或者部分接口也能直接客户端调用）。
基于这种需求，现在又流行 GraphQL。问题来了，我该如何在公司推广 GraphQL 并让其他人（关键是前端）来学习？

我对每一个接口，都小心翼翼地到处判断，尽量避免出现 5xx 错误。我看到前端调用自己的接口报 500 会觉得特别不爽。

前端调用我的接口出现 5XX，我心里就会想：我的逻辑如此缜密，代码那么完美，居然还会 500 (；··)

嗯 前後端分的，啥要分成人做 XD

v2ex 上确实前端比较多～

@l00t dxd，麻烦逻辑清晰点，必要非充分

@Heavytiger 如果不是如此，痛苦的就不是前端一个人了

全栈有必要，互相了解，沟通方便
一面之词，叫后端来这里撕逼
后端可能属于个例

后端其实也很简单的，学一下，帮他们把问题定位到具体的某一行代码，然后给出修改的建议，再不行手把手教他们改

往死里面怼。

居然还有这种事情，一直都是前端把后端往死里虐