其实我的观点一直都是程序员没有前后端之分，项目才有前后端之分。我们可以看到很多优秀的前端都懂后端的，很多优秀的后端也对前端有所了解。
刚好我是个前端，经常被做后端朋友吐槽前端不懂业务，然后一直想写点来吐槽下，其实懂不懂业务和前端后端没关系，而是和你在在项目中所在位置和你在项目里的用心程度有关。就我目前来说，每天的扯皮，在扯业务的比单纯扯前端技术的多的多，对业务的了解也不比后端了解的少。
到底谁不了解业务？说说我遇到的一种情况：
前后端没分离的时候是这样开发的：
产品交互下来，开发需要对每个前端逻辑理清楚，数据库要怎么设计，接口要怎么设计，前端（其实是重构）只是实现ui设计的效果。
前后端分离经常出现的情况是：
一个项目启动，产品给了交互，后端会说你把需要的接口列个文档给我，前端把接口列完，后端一个一个写完，流程走通后发现缺胳膊少腿，然后接口添添补补，项目终于完工了。
这个过程后端都不考虑的业务的，业务都丢给前端和产品去考虑，后端甚至不管他给的接口用来干嘛，反正提供给前端要的数据就可以了。
有的时候前端只是要一个字段，后端把整个表都返回给前端，都不用考虑性能的。
所以这个时候出现的情况就是后端不太了解业务。懂不懂业务和是前端后端没什么关系。
一个项目最好只有一个负责人在实际项目中参与前后端分离项目已经有好几年了，在我这几年实际参与的项目总结出一个小规律：如果一个项目中，前端中没有懂后端的人，后端中没有懂前端的人，项目出问题的可能性会大很多。
前后端分离之后，普遍出现这样一种情况，前端有个负责人，后端有个负责人。这个导致的结果就是，后端负责人很多不会考虑前端的开发体验，前端会各种吐槽后端这不规范，那不规范，导致扯不完的皮。
在一个项目中必须有个leader，而且是唯一的leader，前后端分离不是一个leader分离出两个leader。
前后端区别？个人觉得本来没多大区别的，被大家搞得区别很大。职业规划本来都一样： 码农 -> 技术主管 -> 业务主管/资深工程师 -> CTO/CEO。
但实际情况多是一个公司做好后面后端的话语权会越来越大，毕竟数据库在人家手上，然后导致前端会显得不那么重要。如果你还是在一家不重视用户体验的公司，那前端只是实现效果的重复劳动者而已。
自我感知下来，我做后端会比做前端更加仔细谨慎；做前端的时候对产品的感觉更深，再体验上思考的更多，和产品的沟通会更多，这是做前端比较能找到成就感的地方。
解决方案我觉得可以试试轮岗