这是一个创建于 1310 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近内部的创新项目，大家一起做的很不舒服，因为需求很多不明确，管理问题，作为前端，有洁癖，评审后端接口文档，还经常提了修改建议，感觉得罪人了。。。
 | 1 MuscleOf2016 OP 包括一些文档格式建议。。。 |
 | 2 Rocketer 2022-03-19 00:15:02 +08:00 via iPhone  3 建议互怼，把动静闹大一点，不把问题暴露出来，上面是不会知道你们的经理不合格的 |
 | 3 233373 2022-03-19 00:16:00 +08:00 如果可以说服我，会修改 |
| 4 MuscleOf2016 OP @Rocketer 前端，我说了算吧。后端 leader 太慢，评审不及时。 |
| 5 MuscleOf2016 OP @233373 主要增加了工作量。。 |
| 6 MuscleOf2016 OP @MuscleOf2016 太忙。。 |
 | 7 dumbass 2022-03-19 00:24:38 +08:00 via iPhone 我一般不会提格式问题，只会按照原型或者 ui 和后端沟通字段缺失问题 |
 | 8 pengtdyd 2022-03-19 00:29:21 +08:00 接口文档不都是自动生成的吗，哪来的格式问题？ |
 | 9 sun5244725 2022-03-19 03:01:13 +08:00 @pengtdyd 先有文档再有代码 没法生成的 |
 | 10 wheeler 2022-03-19 06:11:41 +08:00 via iPhone 为什么不呢？ |
 | 11 MegrezZhu 2022-03-19 06:26:49 +08:00 看有没有空，有空就做，没空加 TODO |
 | 12 changdy 2022-03-19 08:05:22 +08:00 ennn 讲道理 后端也要稍微 为前端着想下... erp 系统之类的 .部分设置如果嵌套层次比较多 .. 实际上不如后端直接保存 json |
 | 13 Forest000 2022-03-19 08:12:51 +08:00 一般我们前端都是让我们和 Element UI 组件的的数据格式对齐... |
 | 14 gam2046 2022-03-19 08:13:16 +08:00 合理为啥不能改呢，单纯为了抬杠而抬杠就没意思了。大家都是出来赚钱的，可不是来抬杠的。 |
 | 15 ericls 2022-03-19 08:17:24 +08:00 via iPhone 前后端不能分人 |
 | 16 dayeye2006199 2022-03-19 08:30:35 +08:00 可以手写 openapi 的 spec ，然后自动生成文档。这样就不存在格式问题了。 还能自动生成 mock server ，SDK ，十分方便 |
 | 17 huixia0010 2022-03-19 08:44:31 +08:00 合理，建议，无论是前端测试还是运维，我都会改。特别有价值的我还会请对方喝咖啡。 |
 | 18 ALVC666 2022-03-19 09:18:00 +08:00 合理的肯定改了，你说没空改可以写个 todo 正如楼上所说， 大家都是打份工，彼此担待点搬砖搬的舒服点不好么。 |
 | 19 7911364440 2022-03-19 09:27:04 +08:00 格式问题别提了吧，毕竟大家都还有功能要开发，你这样只会平白无故增加别人工作量，别人肯定不乐意啊。 |
 | 20 paradoxs 2022-03-19 09:48:29 +08:00 晚上一起喝喝酒 谈谈心 第二天所有意见都不见了 |
 | 21 darknoll 2022-03-19 10:36:30 +08:00 提的好的就改，还会赞扬他 /她 |
 | 22 C603H6r18Q1mSP9N 2022-03-19 11:21:23 +08:00 前端只负责切图、布局，接口对接后端自己做；不就行了呗 |
 | 23 vyronlee 2022-03-19 11:57:43 +08:00 按我这么多年接触到的，很多后端基本不会改，API 的设计压根就不考虑使用方的便利性，而且冠以各种“出于性能考虑”，“这样能省点流量”为借口，其实就是图省事懒得改。有时候调整下数据结构，多发一两个字段下来，客户端就能省下大量的接入功夫，维护起来方便，排错成本又低，但就是不愿意做。只要功能能实现就行，“又不是不能用”。客户端抱怨一下，还会被说“矫情”。我不是针对谁，国内不少的都认为“后端要高于客户端 /前端一等”，至少我接触到的都这样。 |
 | 24 Bingchunmoli 2022-03-19 11:58:31 +08:00 via Android @sun5244725 现在一般代码先行，文档生成 |
| 25 Bingchunmoli 2022-03-19 12:00:34 +08:00 via Android @vyronlee 我们也要考虑增加字段的复杂度，和多平台接口的复用度，如果可以加就加了 |
 | 26 cvooc 2022-03-19 12:05:46 +08:00 @vyronlee #23 这点我补充下 主要原因是大部分的后端,常年做的是各种管理系统, 最常用的场景是列表展示, 导致对前端特别是移动端的一些的接口交互是没有概念的, 图省事是重点, 一般在暴漏性能问题前,后端绝大部分业务代码都是以快速做完符合业务为导向的, 性能考虑省流量都是接口 所以我都是要求提权的,至少我有权能改一部分后端代码才可以=.= |
 | 27 Archeb 2022-03-19 12:24:31 +08:00 你都觉得合理了，那证明你认同他的建议，那肯定是能改就改了 |
 | 28 kingjpa 2022-03-19 12:26:18 +08:00 当然是要改的， 不过取决于手头忙不忙 |
 | 29 wmwgijol28 2022-03-19 12:43:47 +08:00 后端返回结构现在一般都是统一的 不存在格式问题, 一般就是沟通字段缺失 缺啥补啥 |
 | 30 EastLord 2022-03-19 12:51:53 +08:00 会 |
 | 31 wolfie 2022-03-19 13:47:22 +08:00 会改 个人经历，前端 2/3 提的修改建议都不合理。 而且比较会甩问题或者工作量。 |
 | 32 pkwenda 2022-03-19 17:04:39 +08:00 大家都觉得和理才行，你提的你当然认为合理 |
 | 33 looplj 2022-03-19 17:10:26 +08:00 合理肯定改，问题是你如何说明你的 API 设计更合理。 有公司 API 设计 Guideline 吗，有项目 API 设计 Guideline 吗 |
 | 34 hingbong 2022-03-19 18:00:06 +08:00 via Android 会改，不过有没有前端提出直接上 graphql ，要什么前端都可以直接拿，会不会省事 |
 | 35 kkbblzq 2022-03-19 22:43:53 +08:00 会改；但是关于前面前端同学说的点我也想补充一下，有些情况下，多加一些字段并不是所谓的"改下数据结构"就能达成的，很多时候多的字段需要额外的请求外部服务、额外的关联表查询等等，这块对于性能和复杂度是会有一定影响的，有时候甚至需要针对这部分做专门的优化，所以有时候所谓的性能问题有时候并不是都是"借口"；就个人的观点来说，接口在满足业务需要的部分，额外所谓易用性的部分，是需要根据业务场景再来做取舍。再者就是前后端同学还是要更多的交流和互相理解吧，不然互相都会觉得对面在甩锅 |
 | 36 leeraya 2022-03-19 22:49:25 +08:00 一切按文档来，文档没说清楚的，让前端找 leader 和 产品说清楚，最终落实文档版本更新，留到下个 story 排 task 。 |
 | 37 EvaCcino 2022-03-19 23:06:01 +08:00 会，前端说怎么改就怎么改，最好让前端什么都不处理 |
 | 38 aver4vex 2022-03-19 23:06:55 +08:00 一般会，除非是马上要上线，来不及改。 |
 | 39 1611499758wuhao 2022-03-19 23:09:37 +08:00 建议如果是合适的，然后跟项目经理要时间，用来修改接口 |
 | 40 ClericPy 2022-03-19 23:12:46 +08:00 最近在关注领域驱动的玩意, 不确定会不会解决 /避免标题里的问题 就之前的经验来说, 如果是很专业的开发团队, 这种问题就不会提出来; 如果连需求都不明确的团队情况, 搞好自己的事情吧, 规范或者优化改进在大领导眼里都是无法产生利润的额外工作量. 不管专业不专业, 一切以文档为准, 轻易修改不光违反开闭原则, 还可能导致从上到下信息不对称, 徒增烦恼 |
 | 42 yoloMiss 2022-03-20 21:56:08 +08:00 怼他，拿规范说事。 |
 | 43 FrankAdler 2022-03-21 00:25:09 +08:00 1 看情况，比如我们公司很多前端都是妹子，水平差的不行，可能都没听说过 DELETE,PUT 你给个这样的接口人家说要 POST 才行，你需要各特殊的 Header ，人家说封装好的，加不上啥的，后端看第低一眼前端存在的情况大都是妹子导致的，或者很多前端连自己做的是啥都不知道，根本不去思考 业务逻辑 |
Select Language