前后端分离

前后端分离

今天聊一聊如何做好前后端分离的项目？

解决方案

两个字： 扯皮

如果只是「扯皮」就没必要去写博客记录了。

扯皮是必不可少的，但是在扯皮之下如何保证项目正常的交付呢？

前后端分离 通常会有两个场景

• 前后端都是一个人。这样最简单，工作效率也最高。
• 前后端分别是不同的人进行开发的。这样搞不好工作效率贼低。

前后端分别是不同的两个人开发，如何做好交付速度保证呢

前后端两个人开发，通常会有三个场景

• 前后端两人速度一致
• 前端做的快，后端做的慢
• 前端做的慢，后端做的快

分别针对上述三种情况聊一聊解决方案

前后端开发速度一致

这种情况太好不过了，前后端交流起来会特别顺畅，因为同时在一个上下文中，此时对于问题的分析是最佳的。

前端做的快，后端做的慢

这种情况比较少见，通常的团队组成里，后端开发比较多，前端开发较少。

当出现这种情况的时候，需要前端提前和后端说明我需要哪个接口，是post，还是get， body是什么，queryString 是什么？ 这些东西最好一定有个地方去记录，

不然前后端不一致，有需要前后端拉回到一个上下文里，去进行讨论，这样无疑是低效的。

出现问题的时候，这个时候是高效的。

因为前端所有的交互和设计已经完成，后端开发可进行快速的验证。 而前端开发可以focus在其他问题上。

前端做的慢，后端做的快

这种情况是大多数团队所遇见的。我目前就是在这个情况里。

这种情况，最好后端写完接口之后，在一个地方去记录，前端要的哪个功能对应后端是哪个接口，body， queryString 是什么？

出现问题的时候，此时前端无力感很强， 因为他压根不知道后端发生了啥？

通常需要后端进行support，此时会block后端开发。

而且出现接口的改动，又需要后端开发进行处理。通常大家又比较懒惰，希望通过扯皮，去让前端用一种比较绕的方式去做。

总结

一定要做好接口的约定规范，如果没有做好规范，请在任何一方提前完成的时候，完成好契约。

多记录，多沟通。