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

[MuscleOf2016]

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

[darknoll]

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

[shanghai1998]

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

[vyronlee]

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

[Bingchunmoli]

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

[Bingchunmoli]

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

[retrocode]

@vyronlee #23 这点我补充下

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

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

[Archeb]

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

[kingjpa]

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

[wmwgijol28]

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

[EastLord]

会

[wolfie]

会改

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

[pkwenda]

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

[ZSeptember]

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

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

[hingbong]

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

[kkbblzq]

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

[leeraya]

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

[EvaCcino]

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

[aver4vex]

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

[1611499758wuhao]

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

[ClericPy]

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

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