相信很多同学学习 nodejs 都是为了应对面试，或者看别人学过会了，自己也要学。但是你有没有深入思考过，为何面试时要考察 nodejs ，为何 nodejs 逐渐成为前端程序员的必备技能？
有些同学可能会说，学习 nodejs 会让自己前后端都懂，慢慢成长为全栈工程师，巴拉巴拉 —— 就此打住！
不要一上来就说一些个人的技术理想，虽然能有且坚持技术理想的人也少之又少。技术的使用，永远都是为了解决问题，你自己的成长只有你自己关心，公司从来不关心一个普通员工的技术成长。公司也从来不关心你用什么技术，什么语言来实现需求，反正只要高效稳定的做出来，后续能保证扩展、快速迭代即可。
其实大部分公司号称有很多员工培养机制，各种技术分享，各种公款买书。但是经历过的人应该都明白，那些分享基本听完就忘，而且很多大牛的分享都是为了自己的技术 KPI 。公款买书和自己买书，也就为自己省了几十块钱，书买来看不看，还得靠你自己。如果你自己能主动看书，相比于学到的知识还差那几十块钱吗？
总之，公司面试时对于候选人的各种要求，目的都是为了更高效的产出工作，要符合部门或者公司的利益。
在日常工作中，一个 web 项目都会有前端和 server 端，而日常的项目开发，功能迭代，也都需要前端和 server 端配合完成。所以，server 端的接口人，是前端工程师的重要合作伙伴。
server 端的工作模式是什么，它的输入输出是什么，你如果了解甚至做过，那你们的合作将会效率大增。但是，如果前端完全不了解 server 端，同时 server 端也不了解前端，那双方合作起来肯定误会不断。特别是如果项目需求一天一变的情况下，而这种情况并不少见。我们无权要求 server 端必须了解前端，只能要求自己更多的了解 server 端。
例如，在一个项目做技术方案设计和评审时，前端和 server 端要确定接口，一般包括 method、输入和输出格式。还会讨论，某些功能实现到底是前端来做，还是 server 来做，哪个更合适。此时，如果你不知道 server 端如果工作，那在这件事儿上你只能听之任之，任人摆布。如果你了解甚至做过 server 端的话，其中有些不合理的地方你就能提出来，既能展示自己的能力，又能保证项目顺利进行。
再例如，万一遇到什么被甩锅或者撕逼的事儿（这种事儿也并不少见），你了解 server 端和你不知道 server 端，绝对是两种不同的“战争”方式。
nodejs 天生就是给前端程序员做 server 的神器，相比于 php python 等其他语言，让前端程序员更容易的入门并接触 server 端开发。做过 nodejs server 端，你就能知道用 php java python 开发 server 是什么套路，只是语言不一样而已。
因此，在 nodejs 出现或者普及之前，岗位招聘要求也一般会写上“了解一门后端语言者优先录用”之类的话语。
前端程序员只能且必须做前端页面吗？同时 server 端只能做后端接口吗？—— 当然不是，我有两个例子：
- 我呆过的两个大型互联网公司，都见过一些测试平台，是由测试人员开发并维护的
- Angular 最初就是几个搞 java 的人写出来的，所以很多概念前端人员都看不懂
其实作为公司，作为领导，他们从来都不会限制自己的员工或者下属部门的工作范围，返回会激发他们的创造性，恨不得什么事儿你都能搞定 —— 当然也得保证可靠性，不能胡来。
我们一个前端部门，难道所有的接口都必须依赖于 server 部门的人来开发吗？难道所有的产品也都必须 server 部门的人来配合吗？—— 这个是不一定的。一般来说，公司核心业务的接口肯定必须由 server 部门来统一维护，但是一些其他的工具性或者 CMS 类型的产品，业务复杂度不高，我们完全可以自己来闭环。一些事情能自己闭环，对于公司来说就是节省了人力，而且解耦了部门之间没必要的业务联系，也就提高了工作效率。
另外，在一些大公司，人员较多，组织层次较多，业务复杂，领导也多。这种情况下，领导之间占地盘或者抢地盘就很正常了，所以此时更需要员工是“全才”。有些比较看好的项目，只要上层领导审批通过，自己部门的人就悄悄做了，不需要其他组来配（抢）合（食）。
传统的前后端合作方式是
- 前后端分离，通过 http 接口连接
- 前端：开发页面，调用 http 接口获取、渲染数据
- 后端：实现 http 接口，接收和返回数据
这样做的好处就是前后端职责分明，各司其职。而坏处也很明显：http 接口很容易混杂。特别是系统比较大，业务复杂，开发新功能升级旧功能，一段时间之后，你会发现 http 接口列表已经混乱不堪。
因为上述 http 接口，其实就是业务接口，而且需要前端人员，后端人员都需要参与研发和维护。参与的人和角色越多，业务越复杂，业务变化也频繁，接口混乱的程度也就越大。接口混乱了，那么前端和后端的沟通也就混乱了，弄不好还要就某个历史问题撕逼俩小时，散会后再心理暗骂半天。严重影响工作效率。
我们无法决定业务复杂度以及业务变化频率，但我们可以从系统设计上来减少参与业务的人和角色。即让后端人员更“靠后”一些，不要参与到业务中来，而更多关注数据和底层计算层面。其中前端也会更“靠后”一些，负责开发业务相关的 http 接口，即大前端模式。大前端模式还可以无缝接入 SSR ，无论是 vue React 框架还是传统的 nodejs 模板引擎都可以。
- 大前端
- 开发前端页面，调用接口层
- 接口层开发业务接口 & 实现 SSR
- 后端：关注于数据和服务，提供 http 接口或者 rpc 协议，供接口层调用
大前端模式，让前端人员既开发页面，又实现业务接口，这样能最大程度的保障接口统一，也没有那么多的跨部门能沟通成本，也就提高了工作效率。而大前端最重要的环节，就是 nodejs 这一层，因为我们要用它来实现接口层。
俗话说无利不起早，公司也是无利不面试。也只有找到了面试的目的，和公司的需求，才能让自己有更明确的学习方向。
····························
欢迎关注课程：
随时随地看视频
热门评论
-
laywa2019-10-15 2
-
laywa2019-10-15 2
-
非凡哥大战哥斯拉2019-10-15 1
查看全部评论你自己的成长只有你自己关心，公司从来不关心一个 深有体会
你自己的成长只有你自己关心，公司从来不关心一个 深有体会
感觉微服务架构下大前端才容易推行