为什么前后端需要分离

首先，我对我带过的所有人都说过一句话：永远不要相信前端。不是说不要相信前端工程师，而是说不要相信前端提交的数据，换句话说，安全性肯定是后端的事情。

前后分离是必然趋势，考虑一个问题，你愿意后端渲染页面还是前端渲染页面？假设后端渲染页面平均需要 0.1 秒，前端渲染平均需要 2 秒，20 倍的差距。但是假如有 100 个用户，后端需要花 10 秒来处理，如果阻塞的话，平均个用户要等 5 秒；而前端渲染，每个用户只需要等 2 秒。所以从性能上来说，我个人是比较推荐将页面处理过程前移的。目前各种静态化趋势也在证明这一点。

其次，从设计的角度来说，前后分离可以实现呈现和数据(逻辑)的解耦，这也是一种 SOA 的思想。后端可以专注于处理逻辑和数据，把呈现的事情完全交给前端处理。前后端只需要约定好数据接口(通常是一定格式的 JSON 或 XML)，剩下的事情就是各干个的，互不影响；不仅前后端的开发轻松，测试也轻松，测前端可以做桩，测后端可以直接验证数据；如果客户对界面不满意，后端可以去休假，前端照新设计把样式表一换就能解决；如果是对用户体验不满意，前端脚本要做的事情就多一点……不过大部分都有框架实现。换句话说，前后分离大大减轻了后端的工作量，但前端工程师一定要顶得起。

接下来就是分工的事情。任何事情，只要是多人(或一人多角色也是同样)合作，就肯定存在分工的问题。分工，说白了就是职责，责任分不清楚，扯皮是迟早的事情。前后分离，从哪里分，分到啥程度，这些都需要预先做好约定，把责任划分清楚。就拿数据来说，几千条数据是应该前端处理的还是应该后端处理的？就按一条数据 1K 来算，几千条也不过就几 M，其实前端处理后端处理都可以。后端处理肯定快得多，而且有缓存优势，并不会造成多大的阻塞，而前端处理除了加载数据慢一点，内存消耗大一点，也不是多大的问题(没人会把几千条数据同时渲染出来吧)，那这个就要靠约定了，而约定也不是随便约的，要架构师说话，要不然架构师拿来干啥。架构师认为这地方，前端处理用户体验不好，分给后端处理，前端传参，后端把数据过滤后给出来，那就后端处理；架构师认为这地方前端处理无压力，后端是瓶颈，那就前端处理……分清楚了，自然不会扯皮。

如果前端压力过大，后端轻松得不行，那就是项目经理要负责的事情了，这很明显是人力资源安排不合理。就按前后各占 50% 工作量来说，1 个前端对 3 个后端(举例)就是很不合适的安排。而且前后分离之后，很明显后期前端工作量会比后端大得多，所以在不同的项目时期，人力资源如何安排，这是项目经理要干的事情。项目经理要做的事情就是协调好资源，控制好风险，把握好进度，再尽可能的少花钱——我一向不太赞成技术人员做项目经理，做技术和做项目管理思维方式都不一样。

总的来说呢，前后分离不是罪，架构师、项目经理、项目组各成员各司其职，尽量以契约的精神来办事，事情就好办得多。如果你现在认为跟项目经理沟通不下去，找你的上司去沟通，还是沟通不下去，再找更上一级的上司……如果怎么都沟通这不下去，那就没有合作的可能，留着也难受，还不如换个地方发展(如果你只是考虑生存，那就忍吧)。