作为后端程序员，如果前端对你写的接口提了合理修改建议，会修改嘛？

[MuscleOf2016]

最近内部的创新项目，大家一起做的很不舒服，因为需求很多不明确，管理问题，作为前端，有洁癖，评审后端接口文档，还经常提了修改建议，感觉得罪人了。。。

[MuscleOf2016]

包括一些文档格式建议。。。🤦‍

[Rocketer]

建议互怼，把动静闹大一点，不把问题暴露出来，上面是不会知道你们的经理不合格的

[233373]

如果可以说服我，会修改

[MuscleOf2016]

@Rocketer 前端，我说了算吧。后端 leader 太慢，评审不及时。

[MuscleOf2016]

@233373 主要增加了工作量。。

[MuscleOf2016]

@MuscleOf2016 太忙。。

[dumbass]

我一般不会提格式问题，只会按照原型或者 ui 和后端沟通字段缺失问题🤔

[pengtdyd]

接口文档不都是自动生成的吗，哪来的格式问题？

[sun5244725]

@pengtdyd 先有文档再有代码 没法生成的

[wheeler]

为什么不呢？

[MegrezZhu]

看有没有空，有空就做，没空加 TODO

[changdy]

ennn 讲道理 后端也要稍微 为前端着想下...
erp 系统之类的 .部分设置如果嵌套层次比较多 .. 实际上不如后端直接保存 json

[Forest000]

一般我们前端都是让我们和 Element UI 组件的的数据格式对齐...

[ntdll]

合理为啥不能改呢，单纯为了抬杠而抬杠就没意思了。大家都是出来赚钱的，可不是来抬杠的。

[ericls]

前后端不能分人

[dayeye2006199]

可以手写 openapi 的 spec ，然后自动生成文档。这样就不存在格式问题了。
还能自动生成 mock server ，SDK ，十分方便

[huixia0010]

合理，建议，无论是前端测试还是运维，我都会改。特别有价值的我还会请对方喝咖啡。

[ALVC666]

合理的肯定改了，你说没空改可以写个 todo 正如楼上所说，
大家都是打份工，彼此担待点搬砖搬的舒服点不好么。

[7911364440]

格式问题别提了吧，毕竟大家都还有功能要开发，你这样只会平白无故增加别人工作量，别人肯定不乐意啊。

[paradoxs]

晚上一起喝喝酒 谈谈心
第二天所有意见都不见了

[darknoll]

提的好的就改，还会赞扬他 /她

[C603H6r18Q1mSP9N]

前端只负责切图、布局，接口对接后端自己做；不就行了呗

[vyronlee]

按我这么多年接触到的，很多后端基本不会改，API 的设计压根就不考虑使用方的便利性，而且冠以各种“出于性能考虑”，“这样能省点流量”为借口，其实就是图省事懒得改。有时候调整下数据结构，多发一两个字段下来，客户端就能省下大量的接入功夫，维护起来方便，排错成本又低，但就是不愿意做。只要功能能实现就行，“又不是不能用”。客户端抱怨一下，还会被说“矫情”。我不是针对谁，国内不少的都认为“后端要高于客户端 /前端一等”，至少我接触到的都这样。

[Bingchunmoli]

@sun5244725 现在一般代码先行，文档生成

[Bingchunmoli]

@vyronlee 我们也要考虑增加字段的复杂度，和多平台接口的复用度，如果可以加就加了

[cvooc]

@vyronlee #23 这点我补充下

主要原因是大部分的后端,常年做的是各种管理系统, 最常用的场景是列表展示, 导致对前端特别是移动端的一些的接口交互是没有概念的, 图省事是重点, 一般在暴漏性能问题前,后端绝大部分业务代码都是以快速做完符合业务为导向的, 性能考虑省流量都是接口

所以我都是要求提权的,至少我有权能改一部分后端代码才可以=.=

[Archeb]

你都觉得合理了，那证明你认同他的建议，那肯定是能改就改了

[kingjpa]

当然是要改的， 不过取决于手头忙不忙

[wmwgijol28]

后端返回结构现在一般都是统一的 不存在格式问题, 一般就是沟通字段缺失 缺啥补啥

[EastLord]

会

[wolfie]

会改

个人经历，前端 2/3 提的修改建议都不合理。
而且比较会甩问题或者工作量。

[pkwenda]

大家都觉得和理才行，你提的你当然认为合理

[looplj]

合理肯定改，问题是你如何说明你的 API 设计更合理。

有公司 API 设计 Guideline 吗，有项目 API 设计 Guideline 吗

[hingbong]

会改，不过有没有前端提出直接上 graphql ，要什么前端都可以直接拿，会不会省事

[kkbblzq]

会改；但是关于前面前端同学说的点我也想补充一下，有些情况下，多加一些字段并不是所谓的"改下数据结构"就能达成的，很多时候多的字段需要额外的请求外部服务、额外的关联表查询等等，这块对于性能和复杂度是会有一定影响的，有时候甚至需要针对这部分做专门的优化，所以有时候所谓的性能问题有时候并不是都是"借口"；就个人的观点来说，接口在满足业务需要的部分，额外所谓易用性的部分，是需要根据业务场景再来做取舍。再者就是前后端同学还是要更多的交流和互相理解吧，不然互相都会觉得对面在甩锅😂😂😂

[leeraya]

一切按文档来，文档没说清楚的，让前端找 leader 和 产品说清楚，最终落实文档版本更新，留到下个 story 排 task 。

[EvaCcino]

会，前端说怎么改就怎么改，最好让前端什么都不处理

[aver4vex]

一般会，除非是马上要上线，来不及改。

[1611499758wuhao]

建议如果是合适的，然后跟项目经理要时间，用来修改接口

[ClericPy]

最近在关注领域驱动的玩意, 不确定会不会解决 /避免标题里的问题

就之前的经验来说, 如果是很专业的开发团队, 这种问题就不会提出来; 如果连需求都不明确的团队情况, 搞好自己的事情吧, 规范或者优化改进在大领导眼里都是无法产生利润的额外工作量. 不管专业不专业, 一切以文档为准, 轻易修改不光违反开闭原则, 还可能导致从上到下信息不对称, 徒增烦恼

[w4087]

@paradoxs 喝完酒谈完两个人准备一起出去接私单了

[yoloMiss]

🤣怼他，拿规范说事。

[FrankAdler]

看情况，比如我们公司很多前端都是妹子，水平差的不行，可能都没听说过 DELETE,PUT 你给个这样的接口人家说要 POST 才行，你需要各特殊的 Header ，人家说封装好的，加不上啥的，后端看第低一眼前端存在的情况大都是妹子导致的，或者很多前端连自己做的是啥都不知道，根本不去思考 业务逻辑