前后端分离可能的问题

如果前后端角色分离，此时前后端人员同时工作在一条故事线上，可能会出现一些问题。比如配合不够默契，这时会出现一方空转的现象。但是如果前后端同时工作在两条故事线上，又不能实现端到端验收成果，可能会导致先完成的一方结束后还要再次返工的现象，而且，这个时候需要两个人同时了解所有的业务细节，这其实是不必要的。

而且，bug 最容易出现在边界处。由于业务上并不能像技术那样前后端分出明确的边界，所以前后端的问题不那么容易隔离。

开发者在合作的时候，会包含很多主观的假设，我们以为对方身上会具备某些知识，但是这毕竟是假设，我们无法做到心灵相通。

如果这些假设中包含某些错误，双方又没有意识到这些问题，这时候 bug 就出现了。

解决的办法就是全栈开发，每个人都同时写前端和后端。他不必是前端专家也不必是后端专家，但是两边都要会写。他的关注点不是技术知识，而是业务知识。他的工作目标是贯穿前后端的价值流，对单个故事进行端到端交付。

技术选型问题

前后端都用 JavaScript 在某些场景下是有效的，但是在企业应用中是不够的。至少在目前，企业应用领域还是 Java 的天下，我们这里讨论的全栈也是 Java + JavaScript 的全栈。

对于一个后端程序员来讲，可能不太好适应前端 JavaScript 那种风格，好在现在前端有了 Angular + TypeScript。

TypeScript 可以给你一些类型的安全感。Angular 的设计思想和 Spring 很像，依赖注入甚至比 Spring 还要彻底。虽然前端的技术风格一直不太稳定，各种新词层出不穷，但是 Angular 替你封装好了一切，至于前端工具链如何迭代，那是 Angular 开发组需要关注的问题，我们只需要安装 NodeJS 和 Angular CLI。

一些最佳实践

我一直觉得前后端有很大的共同点，差异其实没有那么大。而且最近这些年，前端越来越往后端靠拢，比如越来越工程化，也越来越重。

前后端也有一些共同的最佳实践。事实上，很多优秀的框架设计思想会相互吸收。比如 Spring 和 Angular：都采用了依赖注入的方式进行解耦；都提供了函数式编程；都提供了面向对象的编程范式；都提供了 AOP 支持。

虽然技术细节有很大的不同，但是从设计思想上来看确实有很多共同点。