“全栈”这个词之前炒得很热，虽然之前我也写过文章说全栈其实不太靠谱（全栈之难），但细想回来却很能理解为什么这个词会呼声那么高。

因为，不同的技术栈之间的沟通成本实在太高了。

产品，设计，终端，前端，后台，运维，测试……似乎攒齐了就能召唤神龙了，但实际可能的情况却是人员之间相互扯皮的时间远大于实际做事的时间。为什么不能全部技术都由一个人解决，人力得到最有效地利用，哪里有坑就把人填哪？欢迎加入前端全栈开发交流圈一起吹水聊天学习交流：619586920

有意思的是，这样“什么都懂点”的技术人员还真的有，就算可能这个人从来没接触过某个领域，但给他一点点时间上手下，似乎还真能拿出些“还算可以”的成果出来。然后，众多 leader 发现，耶？这样的人用起来真 TM 顺手，而且让人少操很多心，因为很多本来需要别的技术栈介入才能解决的问题他自己可以吭哧吭哧地先拿个可能比较粗糙的解决方案出来，整个项目就会感觉似乎加了鸡血一样很顺利地得到推进。Facebook 大概就是学到了这个甜头，于是全公司推行如是策略，发现似乎还真能玩得转。

黑客精神是什么？
黑客究竟是什么样的人，我也难给出清晰的定位，《黑客与画家》中有足够多的讨论，但其实也没给出明确的定位。但至少，黑客有着一些许多其它普通技术人员所做不到的能力，其中我认为最核心的大概有两个：

事实上一个团队需不需要全栈？不见得需要；因为如果所有问题都能迎刃而解，谁管你是不是全栈呢？我想，这个才是全栈述求的本质。

前端的黑客

不知道其它人是否有同感，我总感觉“全栈”这个词多少都会牵扯到前端。大概因为，从产品层面来看，前端真的处在一个很中枢的地位；而近几年来，服务器、性能、算法等越来越往底层走，在计算越来越便宜的情况下，性能和算法变得越来越不值钱，大可以堆计算解决很多问题，计算搞不定靠存储和索引嘛，砸钱而已。欢迎加入前端全栈开发交流圈一起吹水聊天学习交流：619586920

但产品及其体验却不一样，有了良好的设计有了足够多的功能与性能，也都未必能造就一个良好的产品体验，更不用说产品诞生之间各种不断出现的细节问题，一个好的设计却实现不了的话，没有任何意义。这里就体现出了前端的价值。

在对设计侧时，前端能否实现设计稿，并与设计师良好沟通对接？在对功能侧时，前端能否针对实际情况做出各类的支持，并优化传输时的协议与方式？

这些问题其实本身是可能在设计侧或后台侧他们来直接解决的，但现实情况却是通常是由前端来进行调整与妥协。毕竟，这种灰色地带的事总得有人做，而似乎设计侧不懂代码，而许多后台侧则认为前端来做更方便或是干脆觉得这些不关他们事（比如传输，CDN，模板，数据处理等等）……

就更别说，一个产品终于大致完成时，提交测试时，最多问题的大概一定是前端：兼容性与体验的各类细节无比繁复，不像设计侧只需要管效果图，后台只需要搞定服务器。

这时后台或是设计侧想过来尝试做“全栈”时就会发现，我擦坑那么多，还是交给前端吧……而反过来，前端去尝试设计侧与后台侧时，却会发现，咦？这个世界好单纯，而且反正我不是专业的，弄个“够用”的东西说到底还是不难的，何况业界有那么多的素材库、后台框架、工具库等等，似乎还真能做到一夫当关万夫莫开。

逐渐的，这个前端就成了所谓的全栈：

你真说像这样的全栈是全栈？所以我没这个底气，也不太相信真有人能十字型发展，不仅前端牛逼而且后台/设计/运维等等都老在行，这让专业人士情何以堪？

问题在于，如果这些别人领域的能力都是半桶水，又没得到足够的积累，会给旁人什么感觉？大概就是上面所说的，大家就会觉得这货钻牛角尖，自己的事都没做好就老想着做别人的事；而他自己也委曲：你们设计或是接口没准备好，我这边做前端也麻烦啊，这真是让人左右不是人。然后结果当然是整个项目依然陷入焦油坑，各自推诿别人没做好，自己这边需要时间，整个团队变成只有一个人的效率。欢迎加入前端全栈开发交流圈一起吹水聊天学习交流：619586920

结语

感谢您的观看，如有不足之处，欢迎批评指正。