V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Chingim
V2EX  ›  程序员

后端开发完接口才给接口定义, 是常规操作吗?

  •  1
     
  •   Chingim · 2019-04-18 22:36:53 +08:00 · 17049 次点击
    这是一个创建于 2080 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近加入了一个 1000 多人的中型公司, 在做项目的过程中, 后端不愿意先协商接口定义, 坚持等他开发完后才给接口文档, 理由是先给接口文档, 实现的过程中难免有变动, 改动起来很麻烦.

    而作为前端, 我的理由是, 产品需求文档以及设计稿已经具备的情况下, 先约定接口定义, 前后端可以并行开发, 提高效率.

    几番交涉之后还是没有达成一致, 现在是他开发一个接口, 给一个接口的文档.

    之前就职的小公司是开发前给接口定义, 所有人评审接口之后再开发的. 我觉得效率很高, 定义好的接口, 开发过程中的改动也只是简单的增减, 不会有很大的变化.

    是公司规模造成的开发流程差异吗? 请朋友们说说

    第 1 条附言  ·  2019-04-19 17:52:56 +08:00
    我不是求认同, 也不需要 v 友站队.

    我想要的是: 充分了解其他公司的协作流程, 充分了解其他后端同事对出具接口协议的看法,心智负担在何处。以及探讨怎么样才是合理的可实行的协作方案。

    如果你没有探讨的想法,你可以保持沉默.

    no war, make love
    143 条回复    2019-04-19 21:56:03 +08:00
    1  2  
    bangq
        1
    bangq  
       2019-04-18 22:43:29 +08:00 via iPhone
    easymock 很方便,还是要提前约定的
    zjp
        2
    zjp  
       2019-04-18 22:44:13 +08:00
    我是这几天第一次和前端对接的新人...
    公司现在的做法和楼主之前就职的公司一样,但是我在做实现的时候经常发现要改接口,前端也提了好几处修改...产品支持后端开发完才给接口文档其实对前端不是更有利吗
    kevinlm
        3
    kevinlm  
       2019-04-18 22:46:39 +08:00 via iPhone   ❤️ 6
    我是安卓,接了一个外包,后端让我们列出所需接口,然后他们才去写。妈的我想弄死他们,这帮鸟人压根不想动脑子。
    zhuzhibin
        4
    zhuzhibin  
       2019-04-18 22:48:06 +08:00
    应该是 先出接口文档 然后前端 mock 并行开发吧 最后才联调 ?
    Chingim
        5
    Chingim  
    OP
       2019-04-18 22:51:44 +08:00 via Android
    @zhuzhibin 不要应该,说说贵司情况。

    @zjp 有利很难说。如果急着上线,开始开发的时间越晚,你的心智压力就越大。而且开发完才给接口定义的话,改起来更麻烦。
    zhuzhibin
        6
    zhuzhibin  
       2019-04-18 22:58:07 +08:00
    @Chingim 我各种场景都有经历过。。。 我是后端出身 之前公司是写完接口 补文档 同步给前端 后面也是因为效率问题 前端不可能干等后端接口 项目赶的时候 效率会差 所以才说了上面的那个方式 而如今 我自己一个人撸完页面 自己写接口 自己对接口 over 我要继续搬砖了
    also24
        7
    also24  
       2019-04-18 23:01:44 +08:00   ❤️ 2
    先出全部详细文档的话,对后端来说工作量确实比较大。

    工期确实紧张的话,我一般会建议先约定好大致的接口分类,和每个接口包含的大致内容(具体结构暂不约定),这样在前期就可以先做功能逻辑推演,及早发现问题;至于细节部分就留在开发过程中解决。
    Chingim
        8
    Chingim  
    OP
       2019-04-18 23:03:49 +08:00 via Android   ❤️ 2
    @zhuzhibin 全干工程师要注意身体,这都 23 点了。休息吧
    changdy
        9
    changdy  
       2019-04-18 23:07:43 +08:00
    前后端都是个小菜鸟发表下自己看法:
    前端属于所见即所得,不会涉及太多的状态流转。
    而后端并不完全所见即所得,经常在开发过程中修改结构和实现方式。
    一般来说越是逻辑复杂和初始阶段的项目,后端越难给定义。

    不过前端也不算是等到后端有定义了才开始能写页面吧。刚开始的时候也可以写写样式 dom 结构等等..
    zhuzhibin
        10
    zhuzhibin  
       2019-04-18 23:08:03 +08:00 via iPhone
    @Chingim 开玩笑的啦 我还是挺注意休息的躺床听歌睡觉了💤
    kidtest
        11
    kidtest  
       2019-04-18 23:08:34 +08:00
    理想情况肯定是先沟通,两边技术对好方案,商量好接口,同步开发。但实际上两边的排期可能会有出入,所以,尽量不影响双方开发进度就好
    Chingim
        12
    Chingim  
    OP
       2019-04-18 23:19:15 +08:00
    @changdy 对于一些富前端应用, 其实并不是单纯地进行状态的展示, 也存在状态的变化.

    没有接口文档也不是不能开发, 只是在开发过程中定义的各种数据结构可能和最终的接口相距甚远. 当接口出来之后要多加一层适配器.
    Chingim
        13
    Chingim  
    OP
       2019-04-18 23:20:41 +08:00
    @kidtest 嗯, 可能是我的要求太过于理想了.
    我决定在前端维护一套数据模型, 接口定义好之后再写适配器进行转化. 试试效果
    hyyou2010
        14
    hyyou2010  
       2019-04-18 23:34:13 +08:00   ❤️ 2
    这里面很可能是一个怕背锅的问题,比如现在商定好了,但后端以后需要更改一下,他怕你把责任都推到他头上。只要大家都理解这个研发工作存在不确定性,告诉后端不用担心背这种锅就好了。
    reus
        15
    reus  
       2019-04-18 23:37:08 +08:00   ❤️ 3
    需求确定了,接口就能写出来了,实现时改接口,说明需求没有搞清楚,或者根本就没有试过去理解需求,就开始做了,那当然要一边做一边改。

    这种后端就是个坑货
    ChefIsAwesome
        16
    ChefIsAwesome  
       2019-04-18 23:54:35 +08:00 via Android   ❤️ 1
    其实就两种情况:
    页面长什么样,接口就给什么样。一般这都是后端套了一层的结果。
    接口跟页面不一致。前端自己拼出需要的数据。

    前端开发的时候,只要把 getData 和 render 分开就行了。对 render 来讲,getData 只是一个函数,总是返回自己需要的数据。getData 里头你返回假数据也好,取真正的接口也好,取几个接口再拼出来结果都跟 render 没关系。这样就灵活多了。
    AngryMagikarp
        17
    AngryMagikarp  
       2019-04-19 00:01:15 +08:00   ❤️ 1
    如果真的要先给出全部文档,而且是那种不更改的,那要花很多时间,而且也绝不是后端自己就能定的,还要参考前端的意见,不然到时候还是大概率要改。你就说说你们以前的迭代规模,接口评审花了多少时间,效果如何。

    另外就算要推动这一流程,绝不是后端程序员的事,找你们的技术总监。

    很多公司连产品需求都要改来改去,更别说是接口了。

    再其次,既然需求已经定了。某种意义上前端自己也能设计出一套接口,你们完全可以按照自己的思路先做,正常情况下,你们自己假想的接口和实际后端提供的,应该只是结构不同(字段名等)。如果有很多出路,很可能是你们的产品理解就不同,赶快开个会统一一下。

    反正我无论是做客户端还是服务端,都会积极推动接口规范。我觉得接口不是只是后端的工作,前端也要积极参与其中。
    rizon
        18
    rizon  
       2019-04-19 00:06:44 +08:00
    这种事情,事实话和你说:

    如果工期紧张,肯定是先出 mock 接口的(有各种 mock 接口平台就是为此而生的)。前后端并行开发。但是开发中,接口绝对改来改去的,这个不全是个人能力问题,总之接口变动是必然发生的。

    如果工期不紧张,那公司要是允许你们等到后台开发完再出接口,其实对你们有好处不用改来改去,踩的雷后端自己踩个差不多了没让前端一起跟着踩。但是等接口联调的时候,如果前端对接口不满意说是这种方式做不到,那后端就会很被动了。而且在这种时候后端接口还是会有可能发生变化的,原因很复杂,只不过不像先出 mock 接口那么频繁。
    metrxqin
        19
    metrxqin  
       2019-04-19 00:08:04 +08:00
    我是服务端。

    新需求首先由我这边出接口文档初版供应用端开发参考,之后将服务端实现部署至测试服务器,联调过程中决定是否迭代接口文档。
    Sanko
        20
    Sanko  
       2019-04-19 00:25:52 +08:00 via Android
    每次让前端给我写文档的后端小菜鸡路过~
    Chingim
        21
    Chingim  
    OP
       2019-04-19 01:15:17 +08:00 via Android
    @AngryMagikarp 所以先出接口文档,前端才能够从自身角度提意见,达成一致之后把坑都排除。
    如果后端一直闭门造车,到时不能满足产品需要,变动起来岂不是更麻烦。

    接口文档是前端参与接口建设的重要契机,如果开发完才提供,那就不是讨论,而只是通知了
    Sparetire
        22
    Sparetire  
       2019-04-19 01:26:17 +08:00 via Android
    以前公司都是前后端产品设计需求过完,后端花个一天设计接口,前后端再一起过一遍接口,定好接口文档,然后并行开发,接口偶尔有变动,但基本上变动不大,并且变动后及时更新接口文档通知对方
    就这,我当时还觉得协作不顺畅。。看完楼上我想是我身在福中不知福
    frandy
        23
    frandy  
       2019-04-19 01:34:37 +08:00
    前端:原型图扫一遍 -> 画页面
    后端: 原型图扫一遍 -> 抽取出给前端返回的数据和相关接口 -> 定义 VO->出 mock&实现具体逻辑
    上面两者并发执行,之后联调,查缺补漏。
    frandy
        24
    frandy  
       2019-04-19 01:36:34 +08:00
    上面有提到出接口文档,emmm,有了 swagger,还要什么文档,代码即文档,具体不清楚的字段具体沟通。
    dajj
        25
    dajj  
       2019-04-19 01:39:38 +08:00
    按照经验, 首先技术方案确定,难点解决之后才能出第一版接口文档,
    然后后期开发过程中,肯定要改动接口的。
    那种认为需求定了,接口就定了,简直无知。 需求难道还规定了具体字段名?
    举个例子, 页面中有个字段, 一开始想到用 英文 1, 后面发现其他人也用到,然后又改成 英文 2, 这是多么常见的现象。
    如果前端不肯跟着变的话,我是不乐意先出文档的。

    我觉得正常来说
    开始开发前,可以先对前端页面进行讨论, 大概页面给几个接口,接口包含哪些数据。
    后端做好开发设计, 解决难点和创建好数据库后, 可以给出大致的接口名和请求参数
    后端初步开发完成后, 这时候可以给出具体的响应格式
    最后联调阶段,再稍微调整接口
    scnace
        26
    scnace  
       2019-04-19 01:47:30 +08:00 via Android   ❤️ 3
    后端真是惨 明明是产品经理的锅 要被前端吐槽接口怎么老是改 /接口怎么还没给 还要被 DBA 怼这个人怎么老让我帮改表结构 被怼到可能还要被项目组 leader 说 block 项目进度…(互联网寒冬,请体谅下每一个还奋斗在一线的后端码畜 🌚
    akira
        27
    akira  
       2019-04-19 02:59:51 +08:00
    1000 多人的中型公司 ,不会就你们 2 个研发吧,这个后端是典型的个人开发作风啊
    fakeshadow
        28
    fakeshadow  
       2019-04-19 05:49:45 +08:00
    请问我这样前后自己来还不停改接口的,是不是逗逼。
    ackfin01
        29
    ackfin01  
       2019-04-19 08:01:32 +08:00
    怎么说呢,简单接口可以约定好定义,有些复杂的怎么给啊。所以一般是一部分给,让前端先忙起来,然后增量式开发完一个接口测的没问题给一个接口定义,这样增加效率,减少问题。
    johnhsm2333
        30
    johnhsm2333  
       2019-04-19 08:04:51 +08:00 via Android
    小外包公司提过无数次,但是后端接口写好了也不会写接口文档。每次开发都要被后端拖一拖进度。然后给骂。
    hantsy
        31
    hantsy  
       2019-04-19 08:36:26 +08:00
    参考 CDC(Consumer Driven Contract) 开发, 首先一起协商,定义好前后端一致的 Contract,生成 stub。 前后自己各自做自己该做的事,自己实现,写测试去验证 contract, 前后端的工作可以说可以完全分开。

    流行的 CDC 工具包括,pact.io 比较适合基于 REST/HTTP 的开发,语言支持丰富,另外 Spring Cloud Contract 比较适合 Spring 全家桶,支持更多协议,比如 AMQP,等。

    后端开发过程中,部分成果可以部署到公司内部 staging 服务器(当然你应该在用 CI ),应该很容易提供 Swagger UI 的在线工具来查询 APIs。文档是什么鬼?
    luozic
        32
    luozic  
       2019-04-19 08:42:42 +08:00 via iPhone
    码农,而不是设计或者软件工程师就是这么干的
    passerbytiny
        33
    passerbytiny  
       2019-04-19 08:43:00 +08:00
    请问,你们的项目经理 /开发主管 /系统工程师呢?没有这些,1000 多人跟 5 个人没啥区别。
    justfindu
        34
    justfindu  
       2019-04-19 08:44:54 +08:00
    我都是先给接口文档. 整理接口文档就是整理自己思路. 然后前端模拟.
    Antihank
        35
    Antihank  
       2019-04-19 08:50:15 +08:00
    请问阁下以前就职的小公司是哪家方便说一下吗,我准备一下面试材料。。。
    1000 人的公司确实不应该了,开发团队规模是不是跟得上另说,小公司产品改来改去的哪有文档这么奢侈的
    Cbdy
        36
    Cbdy  
       2019-04-19 08:54:26 +08:00 via Android
    我是一个“前后端分离”的反对者,前后端最好由一个人开发,效率高
    yxcoder
        37
    yxcoder  
       2019-04-19 08:55:20 +08:00
    表示一直做有接口适配,随他怎么改接口
    lihongjie0209
        38
    lihongjie0209  
       2019-04-19 08:56:07 +08:00
    @reus 一个需求可以有 N 种实现,具体选哪一种是由开发人员,开发进度共同决定的,并不是说需求定好了, 代码基本也确定了
    bojackhorseman
        39
    bojackhorseman  
       2019-04-19 08:57:55 +08:00
    我都是先写好页面,然后再和后端对接口。如果页面画完,接口还没出,就可以光明正大地摸鱼了(逃)
    reus
        40
    reus  
       2019-04-19 09:00:38 +08:00   ❤️ 1
    @dajj 需求确定了,后端就可以根据需求写接口,接口就是传什么参数,返回什么,字段名是后端决定的。接口写好了,后面不是十分需要的话,是不会改字段名的,因为前端可能已经把字段名写入代码里了,你改名字,就是给前端添不必要的麻烦。其他人用了不同的字段名,就是因为你不肯先出文档,所以你才会认为“常见”。不好意思,先写文档的,根本就不会碰到这种破事。
    另外,前后端分离的架构,接口应该是各种对象的 CRUD,加上一些特殊用途的,不是根据页面来的,根据页面那就是前后端耦合了。所以写文档,就是对业务本身的建模,主要是定义对象的字段等等,相当于后端的初步开发了,甚至可以根据字段定义自动生成文档。如果你的接口是按照页面来分,那页面需求变了你的接口也要跟着变,这就不是前后端分离的架构了,开发效率自然就低了,没法前后端并行开发的。
    lihongjie0209
        41
    lihongjie0209  
       2019-04-19 09:03:58 +08:00
    前端先写静态页
    后端先设计表结构

    然后就一个具体的功能点二者一同开发,这样后面的联调就比较简单了
    reus
        42
    reus  
       2019-04-19 09:05:03 +08:00
    @lihongjie0209 我说的是前后端共同遵守的接口约定,参数是什么,返回是什么,先定下来,怎么实现是后面的事情。例如一个加法接口,参数就是加数和被加数,返回另一个数,文档就是参数叫什么名字,例如 A, B,怎么传,post josn 还是 query string 还是都支持,返回的是什么结构,等等。至于后端怎么实现加法,这个前端不需要关心。
    如果你连要做的是加法而不是乘法,参数是两个而不是多个,都不能确定的话,那就是我说的“需求未明确”。
    Aprilming
        43
    Aprilming  
       2019-04-19 09:07:05 +08:00
    我们公司都是前端把静态页面写好,搞点假数据,后端负责后端开发以及前端的数据渲染。
    Godykc
        44
    Godykc  
       2019-04-19 09:08:10 +08:00 via iPhone
    服务端进度领先前端一个迭代周期
    前后端分离完全可以错开啊
    amwyyyy
        45
    amwyyyy  
       2019-04-19 09:09:48 +08:00
    @frandy 我前公司就是这样,效率挺不错的
    reus
        46
    reus  
       2019-04-19 09:09:58 +08:00
    @lihongjie0209 你把“表结构”换成“参数和返回”,写下来,就等于是给了文档了,前端就可以把字段写进代码了,表结构那是后端实现阶段的事情。
    lihongjie0209
        47
    lihongjie0209  
       2019-04-19 09:10:17 +08:00
    @reus 想多了, 你数据不按照页面的需求给, 前端不得骂死你?一个展示页面需要调用三个接口来组装数据?后端可以把接口设计的尽量通用,但是前端的复杂度就上升了。

    WEB 层和页面耦合那是必然的,WEB 存在的意义就是展示页面。

    我们要避免的是核心业务对象和展示层的耦合
    wweir
        48
    wweir  
       2019-04-19 09:15:37 +08:00 via Android
    没有任何技术难度的项目,咋搞都行,推荐做法是后端负责人写接口文档草案,前、后端、测试等所有相关部门审阅后人手一份,基于文档进行开发。

    有(后端)技术挑战性的项目,后端现行,开发出大致解构后,前端再参与开发。前端初期更多应该是理解业务、简单画界面、设计交互(划重点)。
    lihongjie0209
        49
    lihongjie0209  
       2019-04-19 09:17:04 +08:00   ❤️ 1
    @reus 你要把所有的接口定下来, 那就意味着你要做出很多假设, 而且这些假设会有依赖关系, 一旦其中的一个假设改变, 那么会导致一组假设全部失效,那也就是说你的接口全需要改。

    需求是确定的,但是开发员人对需求的理解是随着开发慢慢增加了, 你期望别人在项目开发前就理解全部的需求并且不产生任何误解,我能想到的也只有简单的 CURD 了
    a0000
        50
    a0000  
       2019-04-19 09:18:19 +08:00 via Android
    我们公司是需求确定好,后端先定义接口,客户端确认有没有什么问题,没有问题,后端造假数据,让客户端先用着。并行开发,10 几个人的小团队
    a0000
        51
    a0000  
       2019-04-19 09:21:11 +08:00 via Android
    我们不是所有的都列出来,按界面出接口,边写边出,理想状态是后端不影响客户端开发
    owt5008137
        52
    owt5008137  
       2019-04-19 09:21:31 +08:00 via Android
    一般来说我是会先给接口,再实现功能。不过不排除中间会调整的可能性。
    Chingim
        53
    Chingim  
    OP
       2019-04-19 09:22:15 +08:00 via Android
    @frandy
    @hantsy
    swagger 暂时没见使用。这个可以慢慢推,不用 word 我已经知足。

    @passerbytiny 产品和项目管理同意延长工期,所以就没再探讨了。


    @Antihank 以前公司确实开心,swagger/postman/zepin/Invision/asana/circleci/quip 各种服务各种协作工具,可惜产品赚不到钱



    @yxcoder 适配也是一种办法,但是不能推进接口的规范化
    reus
        54
    reus  
       2019-04-19 09:31:27 +08:00   ❤️ 2
    @lihongjie0209 那这就是你们的架构的问题,你们还活在前后端耦合的蛮荒时代。一个页面调几次接口也算问题?

    后端当然会组装数据,但这些数据是符合“模型”,而不是符合“页面”。例如时间字段,返回的就是时间戳,不是 YYYY-MM-DD 之类的具体格式,因为前端可能需要显示的是“ xxx 前”。关联的数据也可以通过复合的字段返回,尽量减少前端的组装工作。现在的前端复杂度本来就是上升的,早就不是单纯写 css + html + jquery 的时代了。有时接口数据不复合需求,需要组装一下,是常见的事情了。前后端耦合,整体来讲就是低效率的。根据页面分接口,那多个端的,你也另外做一套?

    后端服务的对象不是单纯的“ web 层”,web 只是前端的一种。移动端你另外写接口?小程序你另外写接口?内部调用你另外写接口?人力不是这么浪费的。
    ala2008
        55
    ala2008  
       2019-04-19 09:31:55 +08:00
    小公司,后台先出文档,前后端初步同意,进入开发。有修改或缺,及时补上。整个过程是保持沟通的
    reus
        56
    reus  
       2019-04-19 09:38:42 +08:00   ❤️ 1
    @lihongjie0209 你以为 CRUD 简单?能把复杂的业务模型整理成纯粹的 CRUD 接口,给前端调用,这就是后端架构功力的体现。

    要做“假设”,说明需求还没有厘清。厘清了,就不需要假设。整理需求直到接口显而易见,本来就是开发的正常过程。何况题主已经说了“产品需求文档以及设计稿已经具备”,设计稿都出来了,你还想怎么大改?产品设计可能改,这就是你不先整理接口的原因?
    yogogo
        57
    yogogo  
       2019-04-19 09:56:19 +08:00
    我们是前端先画页面,后端同时写接口,前端画完页面,后端也差不多写好接口了,然后联调。
    AngryMagikarp
        58
    AngryMagikarp  
       2019-04-19 10:12:47 +08:00   ❤️ 1
    @reus 接口完全不照顾页面,那么前端(尤其是移动端)用起来会很难受。比如一个页面有三张表的数据,可以使用三个接口,但那样前端就要考虑先调用哪个,先展示哪个,还是全部调完再展示。这个也跟 UI 设计有关系,UI 说要一个 loading 一起展示,还是三个 loading 分别展示?因此接口不可能不照顾页面设计,那样做的才是真正的坑货。

    多个端写多种接口很正常,很多应用多端的需求本身就有区别,就算当前没有区别,以后也很可能会有区别,分开容易维护。我遇到两端用同一个接口的情况下,我也会提供两个 URL 给他们分别用,但内部实现是同一套代码,这样方便以后改。内部调用更是一定要另外写接口了,都说了是内部调用怎么可能和外部接口用同一个?

    接口在正式上线前变更字段很正常,只是上线后不改。一旦上线,做的也一定是兼容的更改。

    你说的那些接口约定其实前端自己也能定,为什么必须后端定?前端就没有看产品需求?显然不是的,归根到底是市面上 90%的前端都不具备这个能力,因此就强依赖于后端。时间多的话,完全可以让前后端都出一套接口方案,然后开个会统一一下。那样就没有任何问题了。接口是前端和后端通信的方式,并不是后端说了算的,把接口设计的责任完全推给后端也是推卸责任的行为。

    就你说的那个时间戳格式问题,我遇到过多少个前端都希望后端替他们返回“ XX 前”格式的。现实中那种真正为技术考虑的人少之有少,大部分人都只是想减少自己的工作量。这点不分前后端。

    我的观点是:做一个“差不多”的接口文档是没多大意义的,因为这个东西开完产品会议前后端脑子里都应该有。做一个“完备”的接口文档则要投入很大时间精力,(前端也要参加!)并不值得,如果你们公司并不在乎的话也可以搞,不过这是公司上层决定的事,没必要针对后端程序员。
    Chingim
        59
    Chingim  
    OP
       2019-04-19 10:23:36 +08:00   ❤️ 1
    @AngryMagikarp 其实我也不排斥前端出接口, 但是很多后端的接口跟数据库是耦合的, 如果前端出具的接口跟数据库表结构 /字段命名 /字段类型相去甚远, 那后端能接受吗?

    我是赞成前端参与接口建设的, 但是如果没有开发前的接口讨论, 那么很难说什么接口建设.
    ety001
        60
    ety001  
       2019-04-19 10:24:04 +08:00
    @reus 把锅都推给需求不明确,的确是个好方法。。。
    guyujiezi
        61
    guyujiezi  
       2019-04-19 10:26:06 +08:00
    那个开发没有听说过 TDD 么?

    开发完再给接口,也太随心所欲了
    ryonanamizu
        62
    ryonanamizu  
       2019-04-19 10:45:24 +08:00
    @kevinlm 我宁可这样
    Alex5467
        63
    Alex5467  
       2019-04-19 10:45:44 +08:00
    @reus 能说出这种话的你怕是也是一种坑货吧,那你咋不说需求改了,产品也是坑货呢
    Gea
        64
    Gea  
       2019-04-19 10:46:18 +08:00   ❤️ 1
    小公司,小业务,当然可以先出文档了,如果业务足够简单,不需要看之前的代码,不需要调用其他服务,评审会上都能给出接口定义,如果你现在的公司是这样的,那喷一下后端我觉得有理。

    大公司,复杂业务,前端状态复杂,后端也要多服务调用,你一开始给出接口定义,到最后开发出来可能完全不一样,或者很大一部分不一样,再调再改的话,接口定义很没意义也很蛋疼。

    其次,写一个接口给一个接口文档提供给前端,你自己都不觉得很打乱开发节奏吗,后端要做的是: 看之前的代码=>结合需求,做业务 balabalabala=>提供文档,再循环往复。需要反复的思维转换,我觉得很影响开发效率。

    最后我觉得还是看业务的情况,公司规模大小。一个前端转后端,小公司大公司都待过的我是这么觉得的
    Alex5467
        65
    Alex5467  
       2019-04-19 10:46:55 +08:00
    @AngryMagikarp 同意加一
    AngryMagikarp
        66
    AngryMagikarp  
       2019-04-19 10:48:33 +08:00   ❤️ 1
    在某些人眼里,产品需求明确了,接口文档下一秒就应该出了,不出就是能力不行。

    在实际中,只要不影响开发进度,我并不关心他什么时候出。很多时候都是可以先作页面的,大部分简单的接口后端也能在前端需要之前就给出。一个项目的开发是多方面的合作,而不是谁要顺着谁。如果后端接口开发真的慢,也应该反应到上级,才能让他们调整开发流程。

    互相理解互相帮助,及时沟通才是正解。当然这是理想情况下。
    DavidNineRoc
        67
    DavidNineRoc  
       2019-04-19 10:50:01 +08:00
    我感觉楼上是不是理解错了? >>>前端不得骂死你?一个展示页面需要调用三个接口来组装数据?>>>
    一个页面只给一个接口的真是神人, 我只能这样说.
    我司的做法:
    UI 出设计图 => 前端画页面 && 后端写接口 ==> 后端给接口文档 && 前端渲染数据 ====> 稍后不同步, 前端做其他模块的页面, 后端开发其他模块的接口.
    reus
        68
    reus  
       2019-04-19 10:52:49 +08:00
    @Alex5467 瞎鸡巴改需求,当然也是坑啊,有什么问题?
    AngryMagikarp
        69
    AngryMagikarp  
       2019-04-19 10:53:21 +08:00
    @DavidNineRoc 我随便举了个例子,说一个页面三个接口的情况,你的理解就是一个页面必须一个接口?你的阅读理解才是神。
    reus
        70
    reus  
       2019-04-19 11:08:16 +08:00
    @AngryMagikarp 我可没有说完全不顾,像一个页面需要三个接口的数据,那一起发过来,一起返回,甚至做更复杂一些的处理,都不是什么大问题。一次请求对应多个接口调用,这个可以实现成通用的机制。

    内部调用和外部调用的方式可以有不同,但基本的参数和返回字段,难不成还用不同的?总得提前决定吧,后端之间也等实现了,才来改字段名或者加适配层?

    接口可以有通用的,就是一堆 CRUD 的,可以有非通用的,例如只给某些页面或者终端用的。通用的,在初期就给出文档,不难吧?非通用的,可以在后面根据需求增加。至于前端还是后端写,需不需要讨论,这些都不是重点。楼主说的是后端在“实现”了接口之后才给文档,你真的觉得这样合适?

    要加个格式化的时间字段,也不是大问题。注意是“加”,不是“改”,后端加了,你想用就用不想用就不用,不影响协作。

    这一套流程不是我发明的,这里其他人一样有使用同样流程的。我们用得轻松愉快,不然楼主也不会发帖了对吧?
    reus
        71
    reus  
       2019-04-19 11:09:17 +08:00
    @ety001 就事论事,连设计稿都出了的情况下,如果谁还说需求不明确,那这个团队的开发能力,绝对有大问题。
    Gea
        72
    Gea  
       2019-04-19 11:10:12 +08:00
    还有让返回 xx 前的?数据完全不复用?完全不能二次使用,只用来渲染?客户端性能全部用来渲染,不做一点计算,全部交给服务端计算?
    atonku
        73
    atonku  
       2019-04-19 11:19:32 +08:00
    @Sparetire 你这明显不是套路啊,应该是这样的:
    后端花个一天设计接口,前后端再一起花一天过一遍接口,定好接口文档,然后第三天上线。
    DavidNineRoc
        74
    DavidNineRoc  
       2019-04-19 11:20:09 +08:00
    @AngryMagikarp 说话不能好好说, 动不动就阅读理解有问题, 自己阅读理解有问题吧? 自己把 三个大于号之间的文字复制,搜索. 看我是和你说还是和另外的人说. 这是理解障碍?
    reus
        75
    reus  
       2019-04-19 11:21:42 +08:00
    @AngryMagikarp “大部分简单的接口后端也能在前端需要之前就给出”,这不就是楼主想要的吗??问题就在于楼主连这个都拿不到,完全等后端开发完接口了,才有!
    reus
        76
    reus  
       2019-04-19 11:34:29 +08:00
    @AngryMagikarp 我希望你能理解“能写出来”和“下一秒就应该出”的区别。
    siteshen
        77
    siteshen  
       2019-04-19 11:43:51 +08:00
    @kevinlm 我是后端开发,也遇到过这样的后端,也想拍死这种不负责任的后端。
    aa1072551507
        78
    aa1072551507  
       2019-04-19 12:01:13 +08:00
    在我的小公司 都是我前端写先完页面 然后我把需要的接口格式写文档给后台人员 最后后天才开始写接口哈哈....
    IvanLi127
        79
    IvanLi127  
       2019-04-19 12:04:22 +08:00 via Android
    这人数。。直接怼,没文档你没办法开发。或者你约定 api 文档,重新调整人员分配。编码明显是在这些东西之后的,他反驳你,你就质疑他专业能力
    947211232
        80
    947211232  
       2019-04-19 12:17:02 +08:00
    理应新定好接口再开发
    rockagen
        81
    rockagen  
       2019-04-19 12:42:05 +08:00
    前端还是图样图森破,对一个 http 业务请求到后端的复杂度一无所知,按你们的公司的人数来看的话,内部系统应该是解耦合的,后端拿到需求是要去其他部门沟通 RPC 接口的吧,只能说后端能先实现大体流程,保证业务能跑通的同时输出接口,细节部分放后面去优化。好了,我要上台拿衣服去了。
    lihongjie0209
        82
    lihongjie0209  
       2019-04-19 12:42:26 +08:00
    @reus 就一句话 多个接口怎么保证事务?
    后端把 post 拆分为 post1 post2 post3, 前端怎么做事务?
    lihongjie0209
        83
    lihongjie0209  
       2019-04-19 12:53:34 +08:00
    @reus 不好意思, 我们多端还真是多个接口的, 我们只需要保证核心的领域逻辑不变, 适配任何端都是可以的。

    至于你说的 web 和页面耦合, 我这套接口就是给 web 页面做的, 只要由这种需求,那么我也会把 xxx 前 返回给前端, 因为类似小程序你要改 UI 还需要重新发布。
    lihongjie0209
        84
    lihongjie0209  
       2019-04-19 12:54:46 +08:00
    @Chingim 套一个 DTO 的事情
    reus
        85
    reus  
       2019-04-19 13:01:26 +08:00
    @lihongjie0209 谁和你说要这样拆了?事务当然是一个接口啊。

    你钱多或者接口少,当然可以一种终端一套接口。后端完全没有文档的不也有么。
    xuanbg
        86
    xuanbg  
       2019-04-19 13:07:39 +08:00
    当然应该先定文档再来按文档实现咯,你们的后端太菜,缺少自信。
    sichuyoudang312
        87
    sichuyoudang312  
       2019-04-19 13:07:46 +08:00
    同 23 楼
    reus
        88
    reus  
       2019-04-19 13:08:43 +08:00
    @lihongjie0209 “套一个 DTO 的事情”,说得轻松,假如有上百种类型,每个类型平均 10 个字段好了,那就是上千个,一个个手工适配?本来不需要干这种活的,就因为后端不肯先约定接口,就要做无谓的工作。
    lihongjie0209
        89
    lihongjie0209  
       2019-04-19 13:14:00 +08:00
    @reus 那用户端的和后台管理的对于 事务 X 的定义是一样的吗?

    接口:

    /api/doX


    前端用户执行之后需要发送短信通知


    后台管理执行之后不需要


    一个接口如何实现这两个功能?
    lihongjie0209
        90
    lihongjie0209  
       2019-04-19 13:14:55 +08:00
    @reus 代码生成了解一下, 本来把数据库的结构暴露给前端就是一个很 sb 的事情
    alakey1989
        91
    alakey1989  
       2019-04-19 13:24:57 +08:00
    @Cbdy 可爱
    Chingim
        92
    Chingim  
    OP
       2019-04-19 13:27:22 +08:00 via Android
    @lihongjie0209 你太理想了,接口字段名称 /类型和数据库耦合是常见的(虽然很不合理)

    曾经沟通过接口字段的语义化,被“数据库里就是这么存的“搪塞过去了


    @rockagen 接口是对外的服务,应该隐藏所有内部的复杂性不是吗?如果因为技术不可行,那在产品评审阶段就砍掉需求了。如果有调研的需要,那这部分前后端都可以暂停开发这部分功能。其余部分的接口还是可以先协商的吧?
    kulove
        93
    kulove  
       2019-04-19 13:28:27 +08:00
    开发完再给接口定义,不然难免会有改动且会有考虑不周的地方。
    应该是后端对照产品原型开发,同时 UI 设计,基本 UI 图给到前端的时候后端接口也开发完了。
    Chingim
        94
    Chingim  
    OP
       2019-04-19 13:32:28 +08:00 via Android   ❤️ 1
    @kulove 那如果开发完发现对需求的理解有偏差呢,那岂不是推倒重来。开发前协商接口,其实就是统一了对需求的理解,双方都有照亮认知盲区的机会
    lihongjie0209
        95
    lihongjie0209  
       2019-04-19 13:34:07 +08:00
    @Chingim 字段名称和我说的数据库结构是两回事

    数据库结构是你的表结构是怎么设计的

    如果把表结构对于的实体类直接返回给前端, 那么前端拿到的数据会有很多冗余,并且嵌套层级非常深


    我一般的做法就是按照 UI 图单独定义一个 Response 类,返回一个扁平的对象,这样做的好处
    1. 网络传输的数据少
    2. 客户端只依赖于 Response, 不依赖于我的数据库结构
    3. 前端写起来简单一点
    reus
        96
    reus  
       2019-04-19 13:34:08 +08:00
    @lihongjie0209 你这个接口的逻辑,可以用一句话概括:doX,然后根据条件判断是否需要发通知。一句话能概括,那当然能一个接口实现,加个条件判断而已啊。前端有的用户想发短信,有的不想发,你也拆两种接口?有的用户想发短信,有的用户想发邮件,你也拆两种接口?这是一个功能,不是两个功能。

    我觉得你根本就没有理解,我说的是接口的参数和返回,从来没有说“数据库的结构”,接口字段和数据库字段,不是必须对应的。代码生成有什么用?你前端用了 gender,结果后端接口用了 sex,代码生成怎么直到这两个字段是对应的?还不是要一个个对。
    kulove
        97
    kulove  
       2019-04-19 13:36:08 +08:00
    @Chingim 肯定是前后端都开会过了产品需求再开发,开发过程中发现逻辑 bug 及时反馈。
    lihongjie0209
        98
    lihongjie0209  
       2019-04-19 13:36:17 +08:00
    @reus
    那安卓用户要推送消息并且同步记录到数据分析平台怎么实现?
    你这个接口的职责有多少?
    依赖关系有多复杂?
    单一职责原则忘记了?
    reus
        99
    reus  
       2019-04-19 13:38:10 +08:00
    @lihongjie0209 所谓的“给接口定义”,就是你把 Response 类的定义写出来之后,就给前端看,让他知道这个对象长什么样,就这么简单,后面你再实现。这样前端后端就可以达到题主说的“并行开发”。
    kulove
        100
    kulove  
       2019-04-19 13:38:23 +08:00
    事实上,开发完成后给接口文档并不怎么会产生偏差,如果经常有很大偏差,要么是默契度不够,磨合一段时间就好了,要么就是太菜。
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2728 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 03:53 · PVG 11:53 · LAX 19:53 · JFK 22:53
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.