我最近的项目，团队都是以前端、后端两个分离的形式。作为一个大前端，不论是在 Web 开发的时候，还是开发 Android 应用的时候，经常遇到：

• 后端 API 产能不免，供给不上的问题

• 后端 API 出现 BUG，需要等待修复的问题

• 后端 API 发生了修改，没有通知到前端，showcase 的时候发现了 bug

• ……

这一系列的问题，让我觉得特别不开心，我浪费了大把地青春在等后端写代码。而联想起很早以前的全功能型团队，我不禁要写一篇文章吐槽一下，WTF，前后端分离团队的资源浪费。

全功能型开发团队

全功能型开发团队是一个胶水团队，用一个更好的词就是精益团队，团队里的成员可以独立地处理大部分的前后端问题。它并非指每个成员都同时擅长前后端，而是在前后端里各有所长。但是，对于业务问题来说，前后端的编码并没有太大的区别。

当一个擅长前端的开发人员，遇到复杂的后端问题，就会找团队里相应的后端开发人员来解决。同理，当一个擅长后端的开发人员，遇到复杂的前端问题，就会找团队里相应的前端开发人员来解决。

我工作的第一个团队是一个全功能型团队，在这个团队里没有前后端之分：Only Developer。只是 Developer 分成了：

• 擅长前端的 Developer

• 擅长后端的 Developer

又或者是：

• 往前端发展的 Developer

• 往后端发展的 Developer

在这个 10 个开发人员的团队里，每个开发人员，即是一个前端开发，又是一个后端开发，还有些人充当了临时的 Ops 或者 DevOps 的角色。在一段时间里，我们还尝试着让开发人员拥有测试、业务分析技能，但是我们失败了——Developer is Deverloper，脱离一线就相当的困难。

前后端分离团队的资源浪费

与前后端团队相比，一个全功能型团队接触到新的任务时，他接到的是一个开发后端 API、前端 UI 的任务。而不是一个后端 API，又或者仅仅是一个前端 UI 的 story。

设计不当导致的浪费

两种不同的团队类型，意味着全功能型团队的成员：

• 节省了大量的时间在 API 沟通上

• 可以设计出符合前端 UI 的 API

• 遇到 Bug 时，可以快速地修复

而在一个前后端分离团队里，他们需要：

• 花费时候在制定 API 的接口上

• 设计出的接口，可能并不适合前端使用

• 遇到 Bug 的时候，修复完后，需要前端或者后端配合

进度不一致导致的浪费

可是当前后端进度出现不一致的时候，特别是后端进度落后于前端的时候，会在后期导致大量地返工，并且有大量地开发人员在等待另外一端的实现。

当后端完成开发时，前端去集成代码，遇到一些 Bug，又进一步地需要等待后端去修复这些 Bug。

沟通不畅导致的浪费

对于那些前、后端不在同一地方开发的团队来说，他们可能使用 API 文档或者契约来沟通。而在开发的过程中，有一些补充的修改，在即时通信软件上通知了，但是执行的人忘了这回事。那么，就会进一步地导致各式的沟通问题（撕逼）。

总之言之，全功能型开发团队好。

什么阻碍了全功能型开发团队

但是要实施全功能型开发团队一点儿也不容易，你要遇到合适的人、合适的项目，还要有适合的领导。

然后，团队就可以关注于技术沟通，和提升技术水平上。

技术沟通

在我司我们采用的是开放式办公，任何时候你遇到任何遇到，你都可以轻松 Touch 到团队的每一个人。

对，这种类似于网吧的布局。

那么，剩下的唯一担心的可能就是代码质量了。请注意两个点：

• 单元测试。即使是不擅长后端，足够的 Test Case，也能提升代码的质量。

• 适当地结对编程。当一个不擅长后端的成员，刚接触项目时，适合时间的结对编程可以提升他的后端能力。同理于前端能力。

• Code Review。代码检视，对于不擅长后端的人来说，仍然是一个相当好的成长机会。

在大部分的公司里，基本上很难做到上面三点中的任意一点，所以更难实现这种类似的团队。而当我们尝试去建立这样的团队，那么帮助他人成长就是永远的主题。

吐槽完毕