一直在不规范的小公司工作，不太清楚正常的开发流程，请问接口都是后端定义写好文档给前端再开发的吗？

• 資深大佬 : imdong

  能给数据表就不错了，我们都是产品丢个原型给我，我就看着原型琢磨流程设计数据库。

  不过吧，我估摸着产品给的数据表设计仅供参考吧，还是要自己设计的。

  至于想得不够全面的问题，大概率是缺少经验吧。

• 資深大佬 : terrytang1

  流程每个公司不一样，但是改来改去就很正常了

• 資深大佬 : vtwoextb

  这样比较规范，对后续开发起来很有帮助，设计前尽可能的想好设计方案，中间的小改动肯定是有的

• 資深大佬 : chinvo

  一般是原型图出了之后, 后端和前端约定接口规范, 然后各做各的. 进展都差不多了进行调试

• 資深大佬 : xuanbg

  不够全面是什么意思？

• 資深大佬 : wolfie

  要是接口经常被打回，就拿着接口设计 跟前端聊 行不行，还差什么。最后再开发。
  产品竟然还有能力给表结构。

• 資深大佬 : cccp2020

  边开发边写文档

• 主 資深大佬 : erisfloralia

  @xuanbg 就是会有一些接口设计上的 bug，或者原型的设计用户使用起来体验极差的，甚至有隐藏 bug，只能否决掉的，我之前没有想到这种坑，直接按照原型写了。

• 主 資深大佬 : erisfloralia

  @wolfie 其实产品也写代码，不过写的不多，写一些简单的代码。数据库表结构有时会没有，不是产品写的，是另外一个大佬离职之前写的，新写的原型就没了。

• 主 資深大佬 : erisfloralia

  @imdong
  @vtwoextb
  @chinvo
  @xuanbg 好，谢谢各位的回复

• 資深大佬 : danielzh

  个人看法，仅供参考。
  1 、接口不全，前后端都有责任。但是一般如果是后端主导技术和交互方案的话，还是需要后端有一定经验，考虑好产品实现细节。
  2 、前端一般可以等后端接口出来再做。
  3 、对于比较大的功能或交互方案不一定能达成一致的，后端在接口设计阶段，就可以找前端沟通初步的接口设计和交互方案，确定后再出详细的接口文档。

• 資深大佬 : GameSheep

  接到需求的时候，就会前后端一起过业务流程，出一个数据库设计，后端也要了解前端需求和操作。
  然后前后端开始开发，后端写接口实现逻辑，前端写页面调试样式。基本上这时候对业务有了更深的了解，接口有改动很正常。
  想的不够全面，如果是需求没吃透那就多沟通，后端开发还是容易点的，不换框架，来来回回都是那些东西

• 資深大佬 : laminux29

  1.开发的本质，是解决需求。只要需求被解决了，就是好产品。

  2.如果公司只是经常做短平快的小型开发，不建议你过多去了解其他内容，容易跑偏。这种情况下，集中精力去解决需求会更好。

  3.不过，一旦公司要开始做大中型系统，需求规模变大后，那么，解决需求的效率，以及产品自身的管理，会逐渐成为问题，这会牵扯出一堆管理问题。

  软件工程就是这些管理问题的总结与经验，如果你是属于这种情况，建议找几本软件工程的教材好好看看，这些内容比较多，帖子里写不下。

• 資深大佬 : msg7086

  我前后端都写，主要写后端。最近一个项目就是我和另一个开发一起写，我写前端他写后端。我们是确定需求以后我先写一版协议，因为是参考 RESTful 所以基本没啥好争的。然后我们一起写代码，写完以后联合测试，再根据测试出来的结果改协议。

• 資深大佬 : guyeu

  一般是前后端商量好接口之后分别开发吧，一般是后端写接口文档，但也不是说后端一手包办。。

• 資深大佬 : ininjue

  最近在尝试前端写接口文档，后端按文档开发，不知道能不能好使。

  原因是我这边后端进度实在太慢了，出的接口文档也经常少字段扯皮严重，我前端先搞出来接口文档，然后直接写一些 mock 数据就开发了，一气呵成，需要啥直接加 mock 数据就行了，写完上测试环境让后端慢慢调去吧。

  还不知道会遇到哪些问题

• 資深大佬 : hxndg

  “满足需求就够了”我倒是见过几个代码满足需求，但是抽象层面不到位，层次不同的代码放一块
  最后不得不折腾好几个月重构的例子。

  好产品必须得是可发展的，可发展就意味着迭代，初代的风格会很影响后续开发。

  某个正在重构代码，一个劲 wtf,wtf,wtf is this shit?!的人留

• 資深大佬 : raaaaaar

  产品给原型图，后端自己琢磨写接口文档，写完之后大概让前端看一下，然后前后端并行一起写，写的过程中一般遇到问题就会交流，问需求自己理解是否到位，某个接口是否完善等等，之后写完后再对接。我自己的经验只是一些小型的产品，因此流程上肯定比不上那些大公司的，但是我认为最重要的是沟通，前后端之间的沟通，和产品间的沟通，遇到问题一定要问，看自己对需求，功能的理解是否到位，即时更改，这才是最重要的，因为无论什么流程都不可能一次性就完美的，肯定是不断修改，动态的一个过程。

• 資深大佬 : Huiao

  我所在的不规范的小公司产品连原型图都不出，他把设计的任务交给 UI，得我主动去和产品聊需求或者大家拉到一起开会聊需求，聊完需求 UI 画出几个页面，然后我后端梳理字段建表写接口文档，再和前端讨论

• 資深大佬 : lancelock

  你们表结构是产品设计的？

• 主 資深大佬 : erisfloralia

  @lancelock 另外一个大佬离职之前写的，新写的原型就没了。

• 主 資深大佬 : erisfloralia

  @danielzh
  @GameSheep
  @laminux29
  @msg7086
  @guyeu 请问在开发流程中小组的 Leader 一般处于啥角色，这种前后端开会讨论接口他会主导进行技术审查之类的吗

• 資深大佬 : han0101

  后台才知道数据结构，所以后台根据需求写接口文档。文档好了跟前段碰一下，补充修改。然后各自开发，开发过程中再完善逻辑。

• 資深大佬 : jones2000

  先确定前端要做几个页面， 每个页面 UI 定下来，　然后根据每个页面需要的数据，　后台开发数据接口。接口一般都是技术负责人定义好的，然后前后台根据接口定义，同步开发就可以了。

• 資深大佬 : msg7086

  @erisfloralia 看具体情况吧。我们的 leader 在设计阶段基本不管，但是代码和成品还是要审的。

• 資深大佬 : tony1890

  产品->需求评审->后端数据库评审->前后端各自开发联调。

  唯一的问题是，接口文档得等接口出来才会有（因为文档是根据接口注释生成的）。所以前端很被动。