Web 前端的路该怎么走？
这是一篇长文。 这篇文章主要是对我个人这两三年从事前端开发以来的“升级打怪”经历的回顾和总结，进而来回复题主对于“前端开发工程师”这一职业存在怎样的发展空间，而它进入高阶之后需要具备怎样的能力以及这些技能或知识可以从哪些地方、项目或企业中获取得到的，等前端coder职业发展上存在疑惑的问题，来发表一些我的个人见解。 然而，我是没权力也没有义务告诉任何一个人Ta未来的路该怎么走，但却可以告诉你我是如何走的，而且我的路子是很野，对于很多大咖来说，绝对不能说是成功的，但对于没有机会进入一流互联网项目历练的大多数程序开发从业者而言，或许我的经历会有那么一点点借鉴的意义。 其实我曾想过，是不是要把自己这个跳跃性如此之大的从业经历写下来，是持有怀疑态度的。曾经某猎头在把我推荐给BAT某家时，建议我不要把媒体编辑的经历做太详细的描述或直接去掉，而我确实也用一些编辑手段弱化了那段经历，还是将它放在简历里面。我觉得，这不是什么问题，写文字一直是我的兴趣，并且曾经是我的谋生手段，而且还做得不算太差，只是和程序开发的关联性少了一些。 当然了，是获得了电话面试的机会，但第一轮就被KO了，那只是1年多以前事情，但3个月等于1年的电商开发节奏，现在我已经忘记了当时的情形，只记得那个电话来到的时候我刚刚通宵完成一个项目的公关，那会儿脑子是一塌糊涂的。  当然，那时我的能力应该达不到人家的要求，但如果现在还有从来一次的机会，我觉得自己应该有能力拿下这样的offer，但暂时没有这个必要。  请别误会，并不是说BAT级别的offer对我没有吸引力，而是对于现阶段的我而言，暂时不能为了这样的机会离开现有的项目和团队，而且现在的项目可以让我做擅长的和感兴趣的事情，并基本都能够按照自己的意志去落实下去，而大公司一般只能是做螺丝钉，不能有太多个人意志的，而且好的机会已然被老人们占据了，只是为了去镀金而去当别人的打手或救火队员，这显然是不理性的。  另一方面，我其实发现了程序开发者要想快速成长，不一定非要进入BAT或一线的互联网企业中进行历练，创业项目一样可以快速成长，只要你把握好机遇和机会。请相信我，这是绝对是可行的，这就是我想把自己的经历写下来的原因。  ok，在开始之前，我觉得预先告诉各位看客，作为一个由平面媒体编辑/记者转行做互联网开发的Coder，本人的码字功底还是不错的，因此篇幅会很长。  如果你确实不感兴趣，建议不用浪费时间，聊技术终归是有些枯燥的，也可能存在我写得不够清楚而让你看不明白的地方。不过，如果你真的对一名先是由编辑大跨行转php开发，再由php转前端切图，然后是如何用2年时间从月薪8K涨到月薪35K的职业经历感兴趣的话，那就一直往下看。  此外，如果这篇文章有幸被某个单位相中，想转载的话，那么该给这篇文章起一个怎样的标题，我就不再代劳了，标题党的功力已经退化得差不多了。还有，我是知道有不少错别字的，但已经逃离媒体行业很久，好不容易不再为错别字太多而担心稿费被扣，那么我真的不想再为这个问题而烦恼。这不再是我的职责，而是你的。不砸别人的饭碗，这是做人的本分，不是吗？ 再劝一次，篇幅真的很长。  一，奇葩的转行。 ========================== 先var身份。 首先，前端一枚。30+了，是老猿吧，年纪不小了。 其实，我也不知道自己的水平在什么段位，年初拿到了两个一线互联网的offer，被定位在相当于阿里P6/P7样子，自己觉得最多P5的水准，自感能力有限和性格不适合大公司，主要是被现在领导忽悠说那些大公司政治斗争非常厉害的，我又特担心自己EQ值太低，经不起考验被扫地出门而颜面无存也就放弃了。  当然，不是本人逼格有多高，有些大企业还是比较向往，比如企鹅厂比如狼厂，但是人家看到我这种奇葩的半路出家的野路子和尚，就连HR初期的筛选都过不了，更别说去面谈做题什么的了。哎，说起来全是泪，伤心得一塌糊涂。不说这个，还是说开发经历吧。  在开发人员里面，我的经历应该算是比较奇葩的。怎么个奇葩法呢？  首先，做过几年的媒体编辑，对的，是平煤，客串过记者，曾经写过不少IT媒体的专栏，比如电脑报、电脑商情报、电脑爱好者之类的媒体，后来看到IT媒体日薄西山，就半路出家。当然，不是去少林寺做和尚，只是转行做了另一种和尚——程序猿。  嗯，跳跃似乎有点大，好多以前的同事不忍直视，其实自我感觉还好，因为业余就爱好博客，经常玩弄各种php开源博客系统，纯属自娱自乐，虽然没有参加过任何技术培训班（其实是因为写稿的真没几个钱可以用来交学费，都挺贵的），不过不管怎样，经过一通自我学习和努力，总算混进程序开发这一行当。  所以说，曾经是个文艺青年的我，在coder这个队伍里面，自我感觉文字控制能力还算是不错的，也不知道算不算个开发技能点？ 二，第1个电商项目。 ========================== 当然，奇葩的转型，那么开发的经历也就比较崎岖了。  先干了一段时间的php+前端混合开发的外包，就是那种用开源项目套页面做简单功能的二次开发类型项目，触摸最多的如wordpress、phpcms、discuz!，drupal之类的，框架也玩弄了thinkphp、CI，不过做外包的开发累死累活也没几个钱，技术也不会有太明显提高。  后来机缘巧合吧，前前前东家要做个电商交易平台，一时半会找到合适的负责人，感觉我还看得过去就被赶鸭子上轿转做了项目主管，负责整个项目基础设施建设，其实就是招人和分配任务等，不过干得最出色就是切图和切图，虽然当时开发方式还属于未开化的刀耕火种，于是乎将自己定位成前端是比较靠谱，而php的活就兼顾一点是一点。  还好，虽然技术比较烂，但是那个项目发展得比较顺利，拿到了A轮（号称3000W美金，水分可能比较大，不过那也是两三年前的事情了，按互联网的3个月=1年的节奏，感觉真的好遥远），有钱之后引入了一批更牛逼的开发人员（主要是前端和php），虽然是我的手下，但那波人能力在当时来看绝对是很强，我也从来没敢把人当手下，甚至很多问题都得向人家请教，技术不行就要虚心请教，这没什么好害羞的。  人家确实也比较牛逼，带来一些先进的前端开发理念，比如前端构建，前端MVVM，纯静态html+restful api构建web网站的开发方式。这些前端开发理念在2012年-13年那会儿绝对算是非常先进的玩意，那时nodejs还未成熟，而grunt也才出来不久，fis可能还在萌芽阶段，而各大互联网公司对于nodejs也只是内部尝试探索。  后来，随着项目发展，前端的需求越来越复杂，需要尝试MVVM、SPA的前端开发技术了，而我作为当时项目的前端负责人，也需要对前端代码做了重构才能适应项目的发展要求，就是做类似这样的事情——  如何将一个已经上线的项目前端部分平滑过渡至组件化和工程化？ - 前端开发  这是我做的第一个的大规模的前端项目重构，当时的技术总监评估给到我的时间是10天，但我拖到了20天才基本完成，基本天天9-10的节奏。从现在的角度看，绝对是一次失败的重构经历。但是，个人从其中获得了很多有价值的经验，让我有机会尝试了许多新的前端技术，包括：  1，构建工具使用gulp，那时才刚出来不久，之所以选择它也就是图个新鲜，这是前端开发的通病吧; 2，基于less预编译的css模块化，watch监控自动编译; 3，基于gulp.spritesmith的雪碧图自动构建，根据watch监控雪碧图目录，自动按目录生成sp图和一份less，less保存到CSS的模块中，进而自动触发less的自动编译; 4，js模块化是AMD方案，模块加载是用requireJS。我们只做了一点点小改进，那就是通过gulp自动生成require.config（开发和生产各一份），第三方js模块的路径根据一定规则自动构建，而不是手工配置。  js模块按目录的方式打包，打包后的文件带上MD5戳，非覆盖式发布，解决AB版迭代和缓存问题。现在看来那种按目录整体打包方式是相当粗暴的，代码冗余非常严重，但无奈当时的水平也就这样而已。不过呢，将需要重复手工配置的有规律的前端资源调度实现自动化，其实就是前端工程化的雏形，至少是给我打开了前端工程化探索的大门。  事实上，这种开发思维不是当时的我所能想到的，而是项目所引入的前端人才提供的开发思维。非常感谢这位同事，虽然一起共事的时间只有短短3个月，而我们也只是点头之交，甚至你现在还可能鄙视那时技术那么烂的我，但却还当着你的领导。不管怎样，感谢你让我看到了前端开发往深入发展的另一种可能。  应该说在很多大公司的互联网公司里面，前端开发在很多年前已经有成套的而且相当成熟的前端工程化开发体系，但对我个人或那个项目的而言，这种方式在当时绝对是非常非常新鲜的，以至于我们那个团队的人逐步离开后（那波人中的前端现在基本也是前端领域的能手了，有在YY的有在VIP也有在UC的），接手的前端无力接管这种不太一样的开发模式，而又只好用原始的方式来生产新版的前端静态资源。当然，绝对不是我留了什么后手，而是交接了一个月多，也找不到能够很好理解的前端。  大家别笑话，现在还有很多创业型项目的前端开发模式还依然停留在刀耕火种的开发模式下，包括很多已经名声在外的电商。在中国，电商从来都不是以技术为第一生产力的，技术很重要，但却没技术人想的那样重要，大家一开始都是以实现业务逻辑为前提，先把业务跑起来，领导管你用神马开发模式，老是不能按时出货就得滚蛋。  有兴趣，大家不妨研究一下一些知名电商的前端代码，没有模块化的知名项目还不少（包括上市的项目），而甚至还有各种裸奔的代码在线上跑的，当然这些其实是创业期发展过快的后遗症，发展太快就可能没有很好的契机做基础设施建设，那么现有的业务代码过于复杂，后来的人只能在原来的基础上改改改成能满足业务需求就万事大吉了。这其实是国情决定的，业务需求的实现大于一切，电商业务发展就像高速的列车，一旦开动起来就很难停下来。  这种情况下前端代码模块化和重构难度就非常非常大了，你见过哪个师傅敢说给一辆高速跑的列车换零件的吗？这种坑不是一般人有信心往里面挑的，谁碰谁倒霉。另一边却是代码生产和发布效率的日渐低下，可能只是改一段静态说明文字抑或是修正一个小bug，发布流程都要跑上个把星期才敢放上线，但是大家不也活的有滋有味的嘛。从业务的角度，技术真没那么重要了。  ========================== 三，一个阶段小结。 ========================== 扯太远了，回一下神。回归主题。前端的路该怎么走——  我个人认为初中级前端要想快速进步，最好的方式：  ①一定要在一个有多人协作的前端团队呆过。通俗地说，要和比你牛逼的人一起干过活，见过牛人长啥模样。 ②一定要找到一个在业务上对前端有较高要求的公司或项目，特别是各种奇葩甚至恶心的需求，对于技术人来说其实是快速进步的机会。  第二点很重要。重要的事情要念3遍，不去外包公司，不去外包公司，不去外包公司。当然，第一点更加重要。但是，有牛人愿意带，在很多时候这属于小概率事件。即便有机会进入这样的项目，你也千万别期待别人会手把手教你什么。我只能告诉你，耳濡目染的能量还是非常强大的。  因此，从两个角度看，楼主现在项目既对技术要求不高，也似乎没看到牛人，是时候换一家公司了。还是那个意思，技术的进步一定来自于业务的不停变化，当要求你必须实现各种奇葩需求，而你又把人家的需求给实现了，那么就意味着进步。  当然，如果天赋异禀，而且非常自律自学能力也牛逼，就当我没说。至于能否偶遇牛人，这就得看个人造化了。如果你发现某项目的确有大牛存在的，薪资要求甚至可以降低以求获得快速进步的机会。技术人要明白，你能拿多少，在一定水位之前，基本和技术能力成正比关系的。  ========================== 四，第2个电商项目。 ========================== 似乎又跑题了。咱们继续聊程序人生。  我的第一个电商项目的经历很不成功，但是可能由于公司管理和文化方面的原因，导致了那一拨我认为非常不错的技术开发人才来到项目后，均不到半年都另谋高就出走了。而我认为自己需要进一步提升，也就选择了离开。  说得直白点，就是技术能力/经验都涨了，薪水还是万年不变（本来就够低的，不知道有没有人听说过给技术经理级别的薪水定位是月薪税前8K的电商项目呢？™的我白痴痴的还一干就干了整整2年，虽然自己能力可能就值这么多而已，要么干脆点把我换掉要么给点点和岗位匹配的薪酬，对吧？），又没有更牛逼的人供你参考膜拜，离开是唯一的选择。你懂的。  这个时候时间来到了2014初了，我跳槽到了一家做在线教育的电商创业项目，月薪Double，title是前端项目经理（这叫法有点点怪怪的），做的事情其实就是前端那一块的事情，我在这个项目前后只呆了半年的样子，加入这家公司只是为了看看自己到底值多少钱，其实项目并不是很感兴趣，只是给我Double的薪资，也就加入了。  这个项目的总负责人其实是电信那边出来的，职业的资历可能比较牛逼，但对技术其实一概不通的，而我的直接上司是技术总监但感觉也不怎么懂技术，更像是个项目经理，只会催进度，而技术的细节怎么去实现，或者前后端分工协作的模式该如何界定，他并没有任何腹案。  也正因为他们对此没有概念，而我从上一个项目重构经历得出了一些前后端分离的经验，给他们分享了一些最新的前端开发模式的信息，告诉他们前端这一块必须尽早进行模块化构建，而那时项目才刚刚开始，我正好有机会从头做起。对我来说是很好的实验机会。  和上一版本相比，构建的流程没有太多变化，模块化只有css和js模块化，我只是对规范和文档要求严格一些，改善了一些构建工具的监控开发体验问题，比如gulp.watch监控文件编译，如果发生语法错误就自动跳出watch问题。  如果要说一个比较大的改变，实际是项目需求带来的变化，该项目由于需要移动端开发，而移动端需要用到前端模板引擎（artTemplate），我们在维护模板引擎的时候需要反复地维护类似这样的代码： html包裹在script内部，编辑器看起来不是很好看，而且多人一起搞容易冲突。于是，我就改进了前端mvc模板维护的机制，弄成这样子：  开发人员维护一份html，通过构建工具自动将html编译成AMD规范封装的js模块，模块id自动编译，比如tpl_index_flash就是tpl/index/_flash.html文件(加下划线就被编译封装在script标签内，如果不加下划线命名html文件，就直接转化为js对象)，而这个文件会被编译保存在js/tpl/index.js模块中。操作模板就使用AMD模块的实例对象，但开发人维护的html比直接放在html结构中要简单多了，代码冲突也几乎没有了，而且这份模板放在js里面可以借助js压缩优化，也可以方便地实现异步调用模板，做加载上的优化。   在这个项目中，我最大的进步就是项目需要前端mvc模式开发，使得我有机会进一步改善前端自动构建的htm模板维护机制（html模板编译js化），优化Watch即编译的前端开发体验问题。但是这时候，由于我的家庭原因，需要请长假（还少1个月），经过考虑后我办理了离职，但给这个项目的前端留下的前端工具和模式基本沿用了下来。  ========================== 五，第3个电商项目（上）。 ========================== 家里的事情解决后，我又得重新找工作。当然，技术和经验又涨了一点点，同时一些互联网求职的经验也涨不少，不再向以前那样白痴痴地不调研市场行情就傻乎乎地投简历。我学会了通过内推或猎头的方式找项目，至少行情比自己投简历要好很多。大家别笑话，可能还有很多人木有意识到这点，特别是像我这种半路出家没有在很像样的互联网公司呆过的同学，这方面的意识是比较滞后的，往往会落得同工不同酬的悲惨结局。  2014年6月底，经过猎头推荐来到了一家化妆品起家的互联网电商。这个公司的业务规模很大，我进入的是一个会包含PC、H5、APP(安卓和IOS)等多端并行开发的海淘项目，进去的时候是以其前端开发主管的身份进去的。咱们是现实的屌丝一名，在薪水的提升面前，其实title没那么重要啦，对吧？  这个项目在一个很高大上的，反正是和屌丝身份格格不入的地方办公。创始人是化妆品电商行业比较牛逼的，而且一直做的是电商，所以这家公司的互联网氛围还是比较浓厚，但也意味着快速开发迭代的节奏。我进入的时候项目的第一期已经上线，并且已经获得了千万美金级别的风投。  进去那天，上午是超级简单的入职培训，下午熟悉项目，第2天上午就来了一个紧急需求——3个专题活动页面需要快速上线，隔天就得见到东西，因为项目投放了一个演唱会地推，线上必须在演唱会开始之前见到相应的推广活动页面。  当时我所负责的组员有3个（其中1个，家人出事请假了），也就是能干活的包括我，就三个人。好吧，那时我其实还叫不全两名组员的名字就大伙分工，一人一个页面，用原始的方式切切切，把东西弄出来。那天，我们三个前端、两个php以及一个测试的妹子（可能是姐姐）搞到了凌晨3点多。  这是我第2天上班的节奏，现在还记忆犹新。其实，真的有点被吓到了。那时候（其实才是去年，但电商的节奏让我感觉已经很久很久以前的事情了），项目的后台系统很不完善，没有啥可供运营使用的东西，专题快速部署的系统当然也不会有的，那么前端的工作就被限制在一些生效效率极度低下的专题页面的开发上，而且没啥大多没啥技术含量，就只能靠人力维持。  随着项目的发展和投入的逐步加大，活动页面需求越来越多，人力维持是不太现实的，我们需要一个专题快速生产的系统。经过项目和产品需求分析后，务必要控制在2个星期内完成，而实际给到开发的时间其实只有1周。。。但主要工作其实对编辑器二次开发，后台编辑器上传图片时，可对图片进行二次修改编辑，我们二次开发就是要增加图片生成商品锚点定位、倒计时，甚至后来还提出了直接将锚点商品加入购物者的功能。。。  这其实主要是前端的要啃下来的活，php只是从属配合，把生成锚点代码和展示配置保存到数据库。如果有人问我前端有什么需求值得去每个前端都去尝试，那么我会将web编辑器列为其中一个。谁弄谁知道。  这个项目是我做电商前端开发以来的最难搞的需求，没有之一。当然，如果开发周期预计得足够长，一切难点都不是问题，难就难在限时实现，和参加奥数比赛类似。由于时间有限，项目经理帮我们找了个有类似功能实现的kindeditor编辑器插件，但是人家是加密了的，我们只能把代码扒了出来进行反编译，接入到我们的后台编辑器里面（ckeditor），接下来就是两个人接力coding，住了好几天7天连锁。。。尼玛，现在回想起来，没有在马桶上坐挂，那是命不该绝。后怕。  这个编辑器项目总算如期交付，虽然后期有很多兼容性bug，但还都在可控范围内，解决了专题发布效率低下的问题，而前端开发也由此从手工维护专题的漩涡中解脱出来。我也因此在不到1个月时间内被列入了核心开发的岗位，并提前转正加薪（税前应该大于20K了）。其实，我当时很想着离开的，毕竟开发的节奏太快了，压力着实有点大。只是作为已过而立之年而且转行跳跃非常大的一个人，这些年过得有点昏昏噩噩，没啥成就，如果在这里学会了放弃，以后可能会变成一种习惯。而且，这份经历可能成为职业污点，毕竟开发圈子其实很小，不是东家就是西家，也就坚持了下来。现在回头看来，是正确的。谁没有过放弃的念头呢？  ========================== 六，第3个电商项目（下）。 ========================== 但是，项目需求迭代的速度并没有因为我们程序开发经常通宵，也不会因为某个人可能存在放弃的念头而会慢下来。这才是‘正常的’互联网电商的节奏，因为去年开始做海淘的项目开始喷发，有点当年千团大战的感觉，如果你把节奏慢下来，可能意味着落后，一步慢就会步步慢。  Boss发话说，我们第一期发版后的UI界面和性能体验实在太糟糕了，而好多页面的首屏加载速度让人难以忍受，甚至有白屏情况，让要我们尽快出台优化方案。其实，上线只有1个多月，前期又没有太多时间做基础设施建设，整套系统都是在一个相对完整的商业系统上二次开发而来，能有多少好的性能体验呢？？  但是，在民营企业里面，Boss的话就是圣旨。就得立刻响应和执行。  于是，我们整个技术团队就对前端性能优化做了一次相对完整的评估，雅虎XX条军规，出台了一些优化方案。这个方案实施，我提出了要响应快速的迭代需求，前后端模式需要建立起松耦合的开发协作体系。其实，这个时候阿里前后端开发体系的一系列文章才出来几个月，对于业界的影响还是有的，至少这个项目来自后端开发的传统程序员基本能接受这种开发思维，但是问题是如何建立？  对于一个已经在线上跑的项目，彻底的打翻重构是不现实的。我又一次面临了一个有难度的前端模块化工程化、前后端分离开发体系建立的需求。但这次不同，这个项目代码规模更大，业务更复杂多变，而且一直是高速运行的。  入职后的1个多月里被专题和编辑器羁绊住了（中间还请了一个星期的假），网站的其他业务其实我没有太多精力去顾及，还好另外一个同事手脚麻利，维护性质的需求一般能很好地解决。当我有机会从头梳理前端以及服务端View层的代码逻辑时，还是被那些商业电商系统混乱的前端代码结构给震住了。  我就不说哪家了，国内的开源或不开源的电商系统，大部分精力放在后端的业务实现层面，而前端这边压根是啥没有模块化概念的。当然，为啥这个项目的技术选型要选这样一个系统？鬼才知道呢，反正我是不知道的。但是，既然负责这一块，别人挖的坑就得由接手的人来填。这是行规，你懂的。  在电商这个领域，解决前后端耦合的问题，主要要做好服务端模板层的规划，控制权尽可能只压在前端或后端，多方维护的情况尽可能减少。以PC端为例，这里是要求SEO的，那么页面的渲染必须在服务端完成。当然，这里会涉及页面性能优化和前端资源调度的问题，服务端模板层最好是由前端团队来掌控。然而，不是每个前端开发人员都是懂后端语言的，这个其实是提高了前端人才的准入门槛，但这又是必须的。  至少我前面几个电商项目都是这种情况，其他电商的做法就不清楚了。这里简单说我们的做法：  1，服务层按功能分层、分域，服务端view层独立开发域。  比如，核心底层基类分出一个开发域，通用函数或组件也可以一个开发域，后台各种管理运营或配置系统划分为不同的域，而前台的，比如首页、列表页或专场、搜索、详情、购物车、登录注册找回密码、会员中心也可以分别各一个域。此外，即便是服务端模板层的开发语言，无法前端团队没能力决定，也至少单独一个开发管理的域。这是前后端松耦合的关键。  当然了，不是各种开发域分得越细就越好，务必要根据按开发团队的人数以及实力来确定。如果分的太多太细了，代码合并管理的重复量会提升。每个人可能同时负责好几个域的开发，解决了代码耦合，但却降低了开发效率，而且增加系统间联调的风险，这是不合理的。  2，对服务端模板层进行公共页面、组件抽象。  比如全站的很多头尾部是共用的，变化的部分相对较少的，进行公共文件剥离和抽象。垂直类电商一般是以页面为颗粒度的，页面展示大多以大块大块的图文列表出现，太精细的抽象是没必要的，至少我所负责的项目大抵如此。其他大众类电商因为要展示的商品种类多，页面可能会做的非常细腻，以更精细的页面组件来组织view层代码结构才会显得有必要。  3，开发前端静态资源调度机制。  为什么要做这个事情？这个问题我就详细展开了，太多了。理论层面的，可参考 大公司里怎样开发和部署前端代码？ - 前端开发 当然，因为业务不同，我们有自己实现机制。但需要解决的问题基本上，张云龙讲得比较通俗易懂，我也就不班门弄斧。  4，我们遇到的问题——TTI延迟引起的前端构建框架重构  前端模块机制是建立在requireJS基础上的，但之前我做的是异步的方式，在以前的项目中其实对于性能优化没有那么苛刻，但是这个项目不一样。是当前竞争最惨烈的一个垂直领域——海淘。因此，任何一个可以改善用户体验的优化，对于项目的意义都是巨大的。  从用户体验出发的几个核心时间指标包括：Start Render、DOM Ready、Page Load、TTI。不同的性能指标对用户体验的影响是不同的，而指标本身受哪些因素的影响也是不同的。一般的前端优化都会考虑前面三个的优化点，而最后的TTI优化往往被忽略。我们却碰到了必须解决这个问题的点，业务场景发生在需要加入购物的按钮上。比如详情页的下单按钮。  不好意思，我不好拿原来自己做的项目来做说明，就随便找一个电商的详情页来替代 因为大家的问题是类似的，比如这页面 姬芮(Za)隔离霜聚美订制礼盒  如上图所示，两张页面是加载先后的两次截图对比。当用户打开页面时候，页面结构的渲染很快就完成了，但一些异步的请求较慢，SKU的计算也需要耗费一些时间，但问题用户可以看到加入购物车的按钮啊，大红色的很吸引人，让人点击的欲望是很强烈的。但是，有些时候网速稍微卡断一点，那么这个加入购物车的按钮就一直点击不了的。很多小白用户就可能会问，为啥不能点击加入购物车啊？我敢肯定一定有这样的投诉，只是看网站开发者如何对待这个问题而已。  这个就是典型的TTI问题。  什么是TTI?? 最好百度。简单滴说，Time To Interact指的是页面可交互的时间。这个应该越早越好，如果页面因为需要等待异步请求的结果才能计算，而异步的数据可能是回不来的，那么就不要让用户可以这么快地看到可交互的元素，因为它会吸引人去点击，但却没有响应，投诉就必然。  当然，这个问题发生在我们的网站很多地方，比如详情页、购物车以及生成订单的页面，要知道这些页面的交互分分钟对转化率产生影响的。然而，采用requireJS异步请求模块的方式，这个TTi问题就会更加突出。  因为页面首次渲染会发生在css加载完成之后，如果不做任何处理，加入购物车的按钮就会很早呈现在用户面前而触发用户去点击，但由于页面一方面要等待异步的js完成，还要等js发起的ajax请求返回的数据做进一步处理，即便是我们对按钮做loading状态处理，但require异步的js可能会发生很多意外，页面的购物车按钮区域一直在loading，而导致用户无法点击加入购物车。  也就是说，我们用requireJS框架代码的模块化管理，但却不能在生产环境中直接使用它的异步机制，因为它会对TTI延迟带来影响。怎么办？  ok，到这里你可能对js模块化有些很反感，有这么多毛病干嘛还要模块化啊？这个问题很深刻，但问题不能单纯从一个角度看待，任何事物都是有两面性的。  其实，如果用其他模块化方案，只要是异步加载js的，都会存在类似的问题，包括seajs。要知道模块化开发一定是团队配合的必然选择，既然已经选择了requireJS作为模块化机制，那么它带来的问题，我们就要着手研究解决方案。  5，前端模块化开发与TTI延迟问题的解决  首先，我们的前端团队已经熟悉了requireJS，基本都能掌握AMD模块开发要点。首次重构的代码已经发布上线后，必须先将TTI问题严重的几个页面，做loading状态处理，让用户等待。  但这只是过渡方案，更优化的解决方案是要对前端开发构建流程做优化调整，把异步的模块在发布生产时必须合并起来，作为同步加载的模块，放置在页面最底部，而且合并的文件应尽可能降低代码的冗余。  但是页面js资源不仅仅只是优化一个页面，将一个页面combo成一个模块就完事了，应该想服务端模板一样，js也要分层，将最底层最核心的类库抽离出来单独combo，多个页面之间共用的模块也要单独combo（这种形式的combo结果可能有多个，因为如果共用模块过多，按一定的大小来合并，我们的原则是mini化之后不能不要超过200K一个文件，如果超过了，就要另起一个文件，当然，这个要灵活处理），前面两者是在页面之间可以相互继承的，而只有当期页面私有逻辑的js模块则应该是一个单独的模块。  那么，网站js最终的形式可能是这样的: 这是我们希望得到的模块combo结果。我们采用的线下combo，然后将combo的结果发布到CDN，这样就需要解决以下的一些列问题：  1，如何区分核心js和页面共用js？ 2，构建流程上如何解决它们的修改，然后编译的版本迭代问题？ 3，对于开发的角度，在本地开发能够快速调试，包括源码调试以及combo状态调试？线上的问题代码，如何方便开发人员调试？ 4，私有模块化如何调用共用模块的方法，或采用怎样的机制来对共用模块进行单独的实例化？ 5，多个模块化之间，combo的先后顺序是什么？ 6，内嵌资源比如img图片引用，如果引用的图片发生了修改，如何解决它的缓存问题？ 7，如果业务模块很多，比如好几百个（电商的业务很容易达到这样的量），那么可能因严重影响代码发版的速度，是不是考虑增加构建的缓存机制，或服务端combo的机制？ ……  好吧，这些问题最终演变出来的，其实就是一整套环环相扣的前端工程化解决方案。  这里面，单独就js而言，要涉及很多代码规范问题，比如js通用模块开发标准，私有模块开发标准，私有模块提升为公共模块的机制，第三方插件的改造规范，js模块的碎片化程度如何掌握？这是一个度的问题，等等。   因为加入CDN网络后的，强缓存解决方案是更换URL路径，而对于访问量大一点的电商来说，非覆盖式发布是最佳的选择。前端架构的开发机制还会涉及服务端模板引擎的如何加载前端静态资源的问题，如果是纯静态的移动端网站优化，可能还需要你自己设计一套开发机制以及静态html开发的具备模块化能力的模板引擎，来解决动态变化的css或js引用问题以及开发调试的体验问题。  好了，这其实是业务逻辑开发以外的，高阶前端开发者需要面临上述的前端痛点问题。这会涉及方方面的调整，比如前后端边界的处理，前后端交互的API规范，开发调试环境、测试以及发布流程的设计，版本迭代回滚，以及性能监控等等一些列衍生问题。。。  我可以负责任地告诉，不同的项目，前端架构设计是不太一样的，因为业务逻辑不同，前后端开发人员配比以及能力模型也不同，那么前端架构就可能得采用不同的设计方案。  当你的业务发展要面临这些问题时，可能前端就没有大家想想中那样简单了？   如果我说了这么多，举了这么实例和理论分析，如果大家还认同这样的看法，就当我什么话页没有说过。就此打住别再往下看，但我也劝你别再干前端了。对于这种似乎是很文艺的表达方式，咋一看，好像挺有意思的，但如果要想玩文字游戏，我们就得按游戏的规则来把问题说清楚：  请问什么是前端的“一叶障目不见泰山”？ 请问什么是语法糖？ 请问什么又是计算机的大树？ 请问计算机的小枝桠又是什么？  作为前端从业者，我对于这样的无厘头描述是表示反感的。因为这是一个很严肃的话题，而编程又是要求逻辑严谨的工作，任何意识流的或空泛的描述都应该是不被允许的。当然，如果我的文字伤害了答主，或违反了知乎的游戏规则，那么该对我关小黑屋的就关小黑屋。我没有意见。  是的，前端从某个角度上看，业务本身的实现并不难，不会涉及太多深层次的算法问题，但是如果要将页面优化做到比较好，解决方案诞生的过程中一定涉及很多计算机底层的逻辑算法的问题。  比如facebook这种的网站，是上万个AMD模块的代码规模，不同国家的用户进入同一个页面要加载的css和js组合可能是几百万种时，人家可是要找博士来研究前端架构的解决方案！当然，这个不是我说的，如果认为我在吹牛散布假消息，大家记得找张云龙大侠来问清楚—— https://github.com/fouber/blog/blob/master/201508/01.md  当然，绝大多数项目是没有到达这样的量级的，比如我们也就几百个js模块，但是对这些模块的依赖关系处理，就已经涉及递归、排序、排重、对比以及插入等底层算法，只是很多人还没有接触到这一层面而已，并不意味着前端开发就不需要。此外，如果你的前端团队如果要用到nodejs做中间层开发，前端开发人员还会面临大量的服务端开发的问题。这是另一个话题，我就不再说了。  总之，在我看来，前端开发的难点不在于某个业务逻辑的本身实现，而在于规模化生产的前端工程化问题的解决。  ========================== 七，第4个电商项目。 ========================== 这是第3个项目电商的延续，因为是同一拨团队继续干的项目。这份经历暂时不方便透露太多，只能说这是以我原来的第3个电商项目的技术团队核心成员为班底的，又一个从零开始的项目，同样是海淘。经过半年多一点，现在已经走到了B轮，暂时只能透露这个消息。  对于做海淘的电商而言，因为我们属于后进者，节奏要比其他项目要快一些，要不是没有任何机会的了，也就意味着别人可能是半年或3个月就融资一次，那么我们就得基本上2个月就进行一次融资，至少在C轮以前必须是这样的速度，要么只有等死。可想而知，要能完成这样的融资节奏，那么开发、推广和运营是怎样的节奏呢？  作为参与者当然是非常非常辛苦的。这几个月不能说天天有发版，但基本上每周二周四会有一个小版本，1周或2周就得完成有一个中级版本，可能是多个版本交替迭代的，而一个月就一个大版本更新。竞争激烈，我们必须按这样的速度去迭代才可能有活路。  那么，单就前端开发而言，如果没有很好的模块化、自动化、流程化的控制体系，你能想象搞这种速度的开发迭代，哪个程序员会和你玩？还好，半年来30来号技术开发，技术团队的离职率基本为0，技术负责人的项目管理能力非常厉害的（我知道的就是，华为那边出接近100W年薪挖他，他没走，当然我也是跟着他混）。  ok，不能再说了。只是有感而发，差点停不下来。如果哪天这个项目有个完结了，比如我离开它，或项目走到了上市或被收购，或资金断流散场，我会回来把这份经历补充好。埋坑。   ==================这里是分割线=================  八，前端开发者快速升级通关的一些个人经验总结。  这纯属个人经验，不一定适合你。还是那句话，如果感兴趣就往下看，不强求。  在评论里面，我说了，从转行做全职前端，从切图开始升级发展到做电商前端架构，只是花了2年时间。不管你信不信，这绝对是事实。当然，我是有好几年php+前端混合开发基础的，不算是从白丁开始的，但转行那时候的前端技能最多就是初中级别，只会用jq插件完成逻辑。  我现在的好几下属，做前端的时间都比我长，有个已经5年了，但依然找不到方向。我平时在招聘前端时，面试的前端好多都干了3-5年了，还是那样。不是我想笑话这样的人，或绝对自己真的可以吹牛逼，我只是觉得可能是大家没有看清楚前端这个工种的未来，没踩准快速升级通关的节奏。当然，也可能你还不够努力。反正，种种原因吧，各有不同，我只能说我自己的。  这两年，我手机里面全部是前端开发书籍，没有100本页有50本，背包里面总有一本关于技术开发的书籍。每天除了上班干活，吃喝拉撒睡外，全部时间几乎全部放在看书写代码写demo上面。以至于忽略了很多事情，包括对家人的照料。这些努力是你看不到的。当然，除了自身努力外，我确实也踏对了前端开发迅猛发展的节奏，比较早地接触了Nodejs，比较早地看到了前端构建前端工程化的价值。  不过，有时候一个人的价值往往不仅仅是看他的代码能力有多少，经验有多少，还要看你能号召多少人跟你一起干。就好比一个人的财富，并不只是他所拥有的银行存款、固定资产或者股票等等他直接控制的财富的总和，而是除了这些意外，他能调动多少资源，所有他能调动的资源页都是他的财富。  技术人做到一定程度之后，再往上发展，需要有一定的号召力，因为绝大多数企业不会给你开那么高的薪酬，甚至给你股份期权。当有几个人愿意跟随你的时候，那么在找项目谈价格时，就会掌控议价的主动权。因为，你已经不是一个人在战斗，你的价值绝对不是以一个人的开发技能来衡量的，而是由跟随你的团队的整体实力来决定。  当然，有人愿意跟着我，是因为这两年我除了一直站在代码开发的第一线外，还坚持了以下几样东西： 总之，言出必行既是项目管理能力问题，也是个人诚信问题，这样团队里的其他人才会愿意相信你，依赖你，跟随你。  其实，很多时候技术和经验积累到一定程度之后，业务处理上的能力或技巧，大多数人的差距其实很小的，但拉开差距的往往不是技术本身，而是对待人，对待技术，或对待需求的态度不一样。我不敢说，技术层面有多厉害，即便是现在的项目给我的技术评级是P7，之前也有拿到的几个offer给我技术评级也是P6/P7，但我自认为没有到达这个水准。