首先，我要补充一些文字以向大家解释清楚，我之所以最终选择使用英文，并非有意为之。这主要是因为媒体平台对字数有严格的限制，只有30个字。如果用“为什么”这三个字来表达，就会超出这个限制。现在，正式开始。

在协同开发的过程中，相信大家经常会遇到类似的情况，例如一个问题出现后，产品方会联系前端，而前端则会表示这并非他们的问题，而是后端的责任，并建议后端进行“这样修改、这样修改、再这样修改”等简单操作即可解决。然而，当联系到后端时，后端又会提出疑问：“为何要后端进行这样的修改，这样做非常麻烦，你让前端‘这样修改、这样修改、再这样修改’不就得了吗？”改起来其实挺容易的，何须转向后端进行修改，那过程往往相当复杂。在这种情况下，通常需要技术实力更强的人或者CTO等管理层人员出面，从全局角度考虑，提出最优方案并作出决策。这种现象在开发过程中是极为常见的。究其原因，程序员们往往认为前端和后端的工作都“太简单”，那么，为何会产生这种看法呢？

若未通过职位调换意识到自身能力不足，那么对他人基本情况的浅显认识很可能会产生以下观点：

前端眼里的后端：

·99%都是增删改查，就是if else +CURD

·写那点api就觉得自己是整个企业的核心了

·为什么让你后端处理下你就非要我前端转换

后端眼里的前端：

·就只会写点界面都不需要思考的

·乱七八糟的框架看都看不懂，非要搞那么复杂

这不过是对接一个API罢了，却搞得像是编写浏览器程序一般复杂。难道你不知道我开放API的难度有多大吗？难道你不知道我在设计架构时需要考虑哪些因素吗？

这实际上是一个循序渐进的过程，只有成为全栈开发者后，才能真正领会。编程之路永无尽头，各行各业的学习、创新、更新、迭代，亦复如是。为何前端要使用框架？实际上，框架是前端行业发展的体现。试想，在没有框架的年代，要实现移动端与PC端的兼容，难度之大，您可知晓？那时的前端开发，只

能停留在div与css布局上，与如今能够进行复杂逻辑处理的情况相去甚远。

后端方面，一个产品一旦上线，面临的压力不容小觑，app可能会出现卡顿，甚至崩溃，接口也可能出现故障，mysql的连接数可能耗尽，cpu使用率也可能达到饱和。哎呀，这数据库的读写次数怎么这么高呢？总体来说，要么是这边出了问题，要么是那边出了问题，这时候才真正显现出后端技术的考验。从TCP协议、操作系统（如Linux），到数据结构、分布式处理、一致性缓存、跨域问题、负载均衡、nginx、IIS等等，可以说，学习后端技术往往需要一点一滴地积累，然后通过各种学习逐渐找到解决问题的方法。外包公司之所以很少遇到这类问题，是因为它们很少参与大型项目，除非是那些规模极大的外包公司。例如，为国家电网或12306这样的机构开发系统，后端技术也必然朝着集群化、集中化和微服务的方向发展。如果一直停留在中间件层面，早晚会被市场淘汰。毕竟，现在前端技术学得好，基本也就意味着后端技术也不成问题；反之亦然。总之，不做不知道，一试才知深浅。

实际上大家确实都不轻松，无论是前端还是后端，都不是简单的工作。只有真正成为全栈开发者，才能深刻理解这一点。不过，这种争论并非全是坏事，它有时能筛选出最优方案。然而，也存在问题，那就是如果领导者缺乏认识，可能会做出错误决策，导致错误累积，最终留下一个糟糕的局面，让下一轮的人来收拾残局。

要做到每个产品都达到完美境界相当困难，就像一块费尽心思堆砌起来的粪山，看起来似乎随时可能崩塌，勉强还能派上用场。接着，我们得不断地调整其形态，增添装饰，清除杂质，这个过程极为艰辛。除非只想草率收场，实际上很多外包公司并不会从零开始打造产品，因为从零起步就意味着高昂的成本。即便如此，即便给你一年的时间，也未必能将一个产品做到相对满意。为何许多公司在外包项目开发时一切顺利，但产品上线后却遭遇失败？为何外包公司与产品公司之间的差距如此之大？我们曾作为外包公司逐步转型为产品公司，对此问题有着深刻的认识，并进行了深刻的反思。当然，这里必须排除那些规模庞大的外包公司，因为它们的情况与众不同，不能以偏概全。至于互联网外包公司与产品公司之间的技术差距，我们可以另外撰写一篇文章进行探讨。