明确告诉你，眼界不够，JS再好也成不了好前端

一般来讲，从陌生到基本了解一个新的行业，至少需要二年。你在任何一个行业工作超过二年之后，才能算基本了解这个行业的方方面面。

前端开发行业，也不例外，从零开始到真正熟悉，至少需要二年时间。众多的招聘简单所要求的至少二年工作经验，也从侧面验证了这一点。

但是，有没有想过，为什么非要二年呢？这二年时间能多出来什么呢？

简单的讲，“前端行业的大局观”。

就像我昨天写的文章一样，许多外行人对于前端开发的理解，只有二个方面，1，工资高；2，入门门槛低。只要搞定html，css，js就可以。所以他们的眼睛只是订着html，css，js，视野很局限。

但是现在面对的是一个新行业，必须要站在工作流程、产业链的层面上去看待这个工种。它在整个流程中是处于什么位置？它的上游是谁？下游是谁？你的上下游是如何影响到你？整个工序的层次和结构是什么？。。这些东西，在我个人主观看来，都属于前端大局观的一部分。

最早期讲前后端分离，那应该是2002、2003年前后的事情了，无非是要求php、java们不要写html、css、js了，当时是尝试让做设计的人搞这些。于是搞的那些做UI设计的人很辛苦，大概是从那时起，出现了专注UI设计和UI制作的区别。

后来的前端又开始提mvc大概是在2007年前后吧，那时也不过是说，把css、js从html里拿出去，叫“表现和结构相分离”。大概是这时起，出现了专注UI制作和专注js编程的区别。不爱写js的人只做静态页面，后来这部分人都被淘汰了。

现在又提出的前后端分离，就不止是代码层面的分离了，而是从业务体系、流程上进行了全面的分离。我个人感觉，应该是从nodeJs出现开始的。

主要是以nodeJs为标志，前端有了一套独立于后端的技术体系。因为有了node，所以前端可以订制自己需要的服务，而不必依赖于后端。这样的直接后果就是，前端的业务代码可以“抽离具体业务”，实现多产品线的复用。

在这个阶段，就需要前端开发人员要有全局视野，要关注整个前端体系的结构，包括它的支撑、业务、基础、组件、公共、第三方plus...等。

因为你现在在做的不是几个html页面，而是一个技术体系，我随便写写啊，也是瞎写，因为现在真正的业务体系都是各个公司自己内部保密的，也没人会拿出来说，但大体思路应该差不太多，

|--业务
 |--config配置
 |--message
 |--具体业务(不再向下细分)


|--支撑
 |--测试
 |--监听
 |--各种统计


|--基础
 |--各种资源(文字、图片、音视频、下载..)
 |--数据存储持久化


|--组件、脚手架
 |--UI
 |--各种功能


|--公共、第三方plus
 |--公共样式、功能
 |--UI皮肤
 |--第三方插件什么的

...还有什么数据、运维、灰度、自动化测试等等，这些东西，现在都算是前端技术体系内，以前前端哪有这些东西呀。

而上述的那些东西，每一家成规模的公司都会有一套自己的内部应用开发技术体系。所以现在前端中、大公司，他们在招聘的时候就要看你的基础知识，理解的是不是ok；二要看你的业务是否理得清；三要看你是否有前端的大局观意识。

现在前端搞的这么复杂，这么多工具，就是因为现在前端业务量、类型、层级的发展非常的快速。旧有的那种开发模式不能适应新的业务与行业需求了。

如果你的脑子里，只有html，css，js这三个东西，那么很明显是不够格的。

所以你在学前端的时候，要立足于在理解前端体系的基础上去学习技术；你在做前端的时候，最少也要在项目整体的层面上去看待你所负责的部分；而你在分析你所负责的部分的业务流程时，至少也是要在整个项目的整体业务层面上去理解你所负责的那部分内容。

总结一下吧，

1、技术，往多层次的方向去想；

2、业务&需求，往整个项目或产品的方向、战略上去想。

说到根上，还是需求。

为啥要这样做？

你不想快40了还写代码吧，这个话题不多说，自己多想想吧。