10,253被浏览881,487分享邀请回答1044 条评论分享收藏感谢收起&script type="text/html" id="adv_list"&
&div class="adv_list"&
&div class="swipe-wrap"&
&% for (var i in item) { %&
&div class="item"&
&a href="&%= item[i].url %&"&
&img src="&%= item[i].image %&" alt=""&
&script type="text/html" id="home1"&
&div class="index_block home1"&
&% if (title) { %&
&div class="title"&&%= title %&&/div&
&div class="content"&
&div class="item"&
&a href="&%= url %&"&
&img src="&%= image %&" alt=""&
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个电商项目（上）。==========================家里的事情解决后，我又得重新找工作。当然，技术和经验又涨了一点点，同时一些互联网求职的经验也涨不少（主要是在线教育这个项目有个UC出来的产品经理在这方面沟通比较多，偷师了一些经验），不再向以前那样白痴痴地不调研市场行情就傻乎乎地投简历。我学会了通过内推或猎头的方式找项目，至少行情比自己投简历要好很多。大家别笑话，可能还有很多人木有意识到这点，特别是像我这种半路出家没有在很像样的互联网公司呆过的同学，这方面的意识是比较滞后的，往往会落得同工不同酬的悲惨结局。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优化往往被忽略。我们却碰到了必须解决这个问题的点，业务场景发生在需要加入购物的按钮上。比如详情页的下单按钮。不好意思，我不好拿原来自己做的项目来做说明，就随便找一个电商的详情页来替代 因为大家的问题是类似的，比如这页面 如上图所示，两张页面是加载先后的两次截图对比。当用户打开页面时候，页面结构的渲染很快就完成了，但一些异步的请求较慢，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规范，开发调试环境、测试以及发布流程的设计，版本迭代回滚，以及性能监控等等一些列衍生问题。。。我可以负责任地告诉，不同的项目，前端架构设计是不太一样的，因为业务逻辑不同，前后端开发人员配比以及能力模型也不同，那么前端架构就可能得采用不同的设计方案。当你的业务发展要面临这些问题时，可能前端就没有大家想想中那样简单了？“一叶障目不见泰山”
“前端说白了只是语法糖，一种编写页面的容器api和程序语言的封装，是计算机发展的大树长出的小枝桠。”……
如果我说了这么多，举了这么实例和理论分析，如果大家还认同这样的看法，就当我什么话页没有说过。就此打住别再往下看，但我也劝你别再干前端了。对于这种似乎是很文艺的表达方式，咋一看，好像挺有意思的，但如果要想玩文字游戏，我们就得按游戏的规则来把问题说清楚：请问什么是前端的“一叶障目不见泰山”？请问什么是语法糖？请问什么又是计算机的大树？请问计算机的小枝桠又是什么？作为前端从业者，我对于这样的无厘头描述是表示反感的。因为这是一个很严肃的话题，而编程又是要求逻辑严谨的工作，任何意识流的或空泛的描述都应该是不被允许的。当然，如果我的文字伤害了答主，或违反了知乎的游戏规则，那么该对我关小黑屋的就关小黑屋。我没有意见。是的，前端从某个角度上看，业务本身的实现并不难，不会涉及太多深层次的算法问题，但是如果要将页面优化做到比较好，解决方案诞生的过程中一定涉及很多计算机底层的逻辑算法的问题。比如facebook这种的网站，是上万个AMD模块的代码规模，不同国家的用户进入同一个页面要加载的css和js组合可能是几百万种时，人家可是要找博士来研究前端架构的解决方案！当然，这个不是我说的，如果认为我在吹牛散布假消息，大家记得找张云龙大侠来问清楚——当然，绝大多数项目是没有到达这样的量级的，比如我们也就几百个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，比较早地看到了前端构建前端工程化的价值。不过，有时候一个人的价值往往不仅仅是看他的代码能力有多少，经验有多少，还要看你能号召多少人跟你一起干。就好比一个人的财富，并不只是他所拥有的银行存款、固定资产或者股票等等他直接控制的财富的总和，而是除了这些意外，他能调动多少资源，所有他能调动的资源页都是他的财富。技术人做到一定程度之后，再往上发展，需要有一定的号召力，因为绝大多数企业不会给你开那么高的薪酬，甚至给你股份期权。当有几个人愿意跟随你的时候，那么在找项目谈价格时，就会掌控议价的主动权。因为，你已经不是一个人在战斗，你的价值绝对不是以一个人的开发技能来衡量的，而是由跟随你的团队的整体实力来决定。当然，有人愿意跟着我，是因为这两年我除了一直站在代码开发的第一线外，还坚持了以下几样东西：1，从不藏私。把你知道的东西，毫无保留地分享给你周围的同学，记得是毫不保留。知道多少，分享多少，这样才会不断促使自己去知道的更多。技术层面不存在教会徒弟饿死师傅这种事情，如果你抱有这样的想法，那就太狭隘了。2，对代码要有洁癖。洁癖到什么程度？包括一个空格，一个标点符号，不要觉得无所谓，一定要觉得有所谓。要追求能力极限上的完美，包括逻辑判断的严谨、文档的完善、代码格式的完美。3，言出必行。一个需求来到我这里，只要我有答应别人的时间节点，不管如何也要想尽办法把它实现了。如果确实无法按时，一定提前沟通，但二次调整的时间一定一定要准时，下死命也要完成。事不过三，不给自己留任何后路或找理由。总之，言出必行既是项目管理能力问题，也是个人诚信问题，这样团队里的其他人才会愿意相信你，依赖你，跟随你。其实，很多时候技术和经验积累到一定程度之后，业务处理上的能力或技巧，大多数人的差距其实很小的，但拉开差距的往往不是技术本身，而是对待人，对待技术，或对待需求的态度不一样。我不敢说，技术层面有多厉害，即便是现在的项目给我的技术评级是P7，之前也有拿到的几个offer给我技术评级也是P6/P7，但我自认为没有到达这个水准。既然如此，可能是对待人，对待技术，或对待需求的态度上做得不错。举个新鲜的例子：前几个月我们有一个微信jsSdk分享有礼的需求，这个需求非常重要，我决定自己书写前端逻辑，避免耽误与外部的合作。但这个需求关键的点是需要获得两次微信用户授权，一个是交易授权签名，一个是分享授权签名。但由于后端开发同事没有经验，只做了交易授权签名，但他也已经非常努力了，基本通宵达旦了，但当我发现另一个授权签名没有服务端接口时，前端的逻辑是走不通的，等别人调休完成再做吗？但项目其实是务必在第二天提测，要不无法按时上线，而广告已经投放出去了。如果是你会如何处理？当时已经是凌晨5点了，后端的同事都疲惫不堪回去休息了，我决定自己来书写服务端另一个授权签名的api，但这里有一个坑，授权签名的算法里面要求前端post一个url，而这个URL必须是不经过转义，但微信jsSDK里面没有特别说明这个（可能是我没看仔细忽略了），从安全的角度我习惯对前端ajax的url字段进行了转义处理，导致一直调试不通，找了各种原因，还是没找到原因。。。已经是早上9点多，别人已经又来上班，而我还没有下班，但已经很困很困了，但知道这个需求很重要，咬牙再坚持，碰巧在这个页面
看到了问题所在，如图在php端对这一字段反转义，调试就通了，在那天中午前能够按时提测，最后没有太大问题终于是上了线。虽然还有不少细节没处理好，但至少别人接手可以轻易解决。那天我回家修休息已经是下午3点了。也即是，我从前一天10点开始，一直干到了第二天的下午3点，就为了完成当初承诺的时间节点。事实上，这个需求不是很难，但技术开发有非常明确的截止时间，而需求又是我自己亲自做的。如果是其他同事，看到api似乎是服务端的事务，其实作为前端开发的你，人家都走了，你也跟着走人，最后担主要责任的一定不是前端开发，对吧？但是，这不是我的做法，因为这个项目既然是由你来接手，并评估可以按时完成的，那么不管哪里出了问题，这都是你的问题。因此，我会去书写服务端的api逻辑，尽管这似乎不是我的责任。好了，说了这么多。其实快速通关可能是需要时运，但更多是个人的努力与坚持。这个没有什么诀窍的，而且很多时候和技术本身没有关系，而是对待困难的态度要有点点不一样。最后，回归到楼主的问题本身——到底前端的路可以怎么走？前面提过两点，如果当你要从中级跨入高级前端，这除了项目环境外，还需要你要有一定的坚持，并且选对前端未来的发展路线，至少我认为有以下几种路线可供选择：1，业务层面的高手，做到非常了解某个领域的业务逻辑。比如垂直类电商的业务逻辑，这样你其实可以尝试带队，做项目管理，最终发展做项目经理。2，前端工程化解决能手。就是我在第六章罗里吧嗦列举出来的一堆问题，你都能有腹案去解决，每个项目的工程化方案都是不一样的，这种人才的需求也很旺盛，尤其是哪些基础设施建设不太完善的项目。3，nodejs服务端方面开发。这个可能在岗位上更像是后端开发了，只是前端可以通过这个方向进入服务端开发的领域，做的牛逼，其实做一下CTO的梦还是可以做一做的。。。4，如果上面觉得都不适合你，但你对前端开发又比较了解，那么转行做产品页也是不错的选择。具备开发思维的产品，在很多时候是一个优势。5，创业。按现在的行情，前面4个方向任何一个方向做好了，作为打工者，你的收入都不会太低，一般不会低于25W年薪吧？如果第一点和第二点你都能做得很好，前端架构师这种岗位就可以去试试，35W以下年薪可以不用考虑；如果你连第三点也做得不错，那么系统架构师职位是可以去尝试的，50W年薪的岗位就应该在你的考虑范围；如果你连这4点页都做的比较到位，我觉得你最合适干第5点，这个值多少钱，就不知道了。此外，移动互联的前端开发也是一个很不错的发展方向，你也可以尝试做webapp和hybrid app的开发。。。多端的开发能力，也是前端开发人员不错的发展方向。=================================感谢，周末码的字能感动到人，还是比较高兴的。希望我的这份回答能成为个人在知乎的一个亮点，因此我决定继续分享一些东西，顺便预先挖一个坑。================================如果要说一个通行的经验，我会说——做一行就爱一行。我想以后自己不写代码了，经过这两年开发历程，自认为做其他职业其实也不会太烂。这可能很性格有关，就比如当初我做编辑，也不算差，还算是当时报社的第一打手，好多黑报道几乎出自我手，只是当初好单纯的说。=======================九，谈谈互联网项目环境对于前端开发者向高阶晋级的影响。=======================（上）我在前面曾经提到过一个观点——“技术人要明白，你能拿多少，在一定水位之前，基本和技术能力成正比关系的。”什么是一定水位之前？什么又是一定水位之后？这里我觉得要对这两个名词做一下解析，避免大家对我的这种说辞产生误解，以为是这位编辑是在玩弄文字游戏。所谓的“一定水位”，就是指当一个前端开发者的开发能力进入中高级之后，不同特点的前端开发者再往深入发展时将会出现后续发展路径上的选择差异的那个状态或时刻。名词解析总会是有点绕的，但这是我所能表述的最简单的一种解析了，希望看官你能明白我所指的是什么。但在这里，我应该要对中高级前端的开发能力进行一个定位，否则我们并不清楚这种“水位”到底该如何度量。当然，这个不同行业/企业对“中高级前端开发”的定位或理解是不一样的。单就电商而言，我觉得是基本上能够独立解决各种业务需求，独挡一面了。如果非要有一个衡量的标准，那么我们公司的定位是具备以下技能点：1，html、css和js较为扎实的基本功，尤其是js方面能力，要能脱离jq/zepto之类的工具类库也能干活，具备良好的面向对象编程的思维，能够书写和维护较大规模的前端业务代码。2，熟练使用Sass、LESS、Stylus等CSS 预处理器中的一款。3，掌握至少一种前端模块化开发规范及其相关框架，比如AMD（requireJS）或CMD（seajs）。4，掌握至少一款前端MVC/MVVM框架，并有一、两个项目实战经验。5，熟悉至少一门热门的后端开发语言，比如php,java。6，团队协作方面，有在具有较大规模的电商开发经验，必须具备至少一个有多人协作开发的项目参与经验，掌握SVN或Git中的一种。7，熟悉前端页面的优化原则，熟悉http协议的通讯机制，对静态资源缓存机制较深入的了解。8，熟悉HTML5和CSS3，有移动H5网站开发经验。把H5开发经验加上，是因为移动互联网已经是几乎所有的互联网项目的业务发展重心，随着时间的往后推移，以后这一点应该成为前端招聘JD的标配。但我之所以把这项列在最后，因为从PC端切换至H5端开发，其实并不是那么难，只要项目需要，给一点点时间，任何一个有经验的前端都能快速切入，如果连这点快速学习能力都不具备，Ta不可能是一名中高级别的前端。到了这一层面，按当前的市场行情，基本可以以20K为分水岭（就是这个话题——）。不同的公司略有差异，一流公司不差钱，这个阀值一般会更高一点。我没有在一流的公司里面呆过，但在三四流的电商项目中跑了一圈，了解到的情况就是这样子。当一个开发人员越过了这个分水岭，绝大多数企业都不太可能只会让他单纯地去写代码，而不要求他做其他事情。不同的环境，安排的代码外的事项一般这样子：1，开始要求带新人，负责项目需求的跟进与开发任务的实施。职位一般表现为主管或经理，或即便是没有职位上的直接提升，但干的活都是要求带人，日常工作就会涉及需求评估，分配任务和难点攻关，重要或紧急需求的实现（救火队员），等等。2，代码能力比一般的前端高了，也有可能被安排一些底层的前端工具研发，以提高前端的生产效率为主要任务的团队中去。后面这种情况，在规模大且核心业务已趋于平稳的互联网企业可能会碰到，比如百度的FIS团队，比如阿里蚂蚁金服的前端工程技术团队。了解Web开发的都应该知道，由于前端开发语言本身的局限性，导致前端开发工作的碎片化非常严重，重复的工作非常多，开发体验是相当不好的，规模化生产的效率低。企业的规模越大，这种糟糕的开发体验就对其生产效率的负面影响页就越突出。因此，像BAT级别的企业才会设立专门的部门来解决这个问题。但是，其他快速发展的项目则普遍是第1种情况，尤其是快节奏的电商，比如唯品会、聚美、蘑菇街，等等，还有N多。为什么？因为电商务必要快！那么人才培养成熟后（或招揽的人才具备同等水平），往往被优先安排到业务最繁忙的事务上。因为这样才能最快地出成绩，而前端生产效率低下这种负面影响并不是那么的重要，甚至可以说一点也不重要。因为中国的电商几乎都是以市场营销为导向的，满足业务需要才是最关键的。只要业务发展快，融资节奏跟得上，前端这一技术细分领域是否模块化，是否工程化，就显得真的不那么重要了。页面少几个连接数还是多几个连接数，并不会有立竿见影的影响，高并发上来了，顶不住的话，有大不了我多几台服务器就是了，但营销需求的开发一定要优先满足。而规模更小或创业初期的互联网项目，如果能用得起这样前端的，往往都是除了开发外，还有做更多的事情，包括招聘、培训、带团队、需求评估与跟进，书写业务逻辑，甚至还要自己切图，事情多，工作杂，加班加点是正常的，每天过得累死累活，比如我就是这么过来的。于是，有前瞻意识的前端leader才可能会去考虑前端构建、前端模块化以及工程化方面的事情，而把一部分精力投放到提高前端团队的生产效率的构建工具开发上面来。当然，我算是比较早就意识到这一点的前端之一吧，所以才能快速地成长。那么，这两种不同岗位安排，对开发者后续的影响又有什么区别呢？在规模越大的团队，工作划分得越细腻，专注的点就越深，但同时就可能会被限制在某个狭窄点上，成为某个角落的技术专家。但页会因为缺少去了解具体业务细节的机会，而让他的发展受到限制，那么这种人才往往是不太适合去做创业的，一直呆在大平台上才更容易创造高价值。就前端这个工种而言，如果它的发展都不跳出前端这个范畴，那么我的理解是这样的：在大平台的前端团队中，一般容易批量生产技术专家类型的人才，这些人才对他所在技术领域的研究会足够深，但也可能（只是一种相对较低的可能性，不是绝对）不太容易诞生前端架构类型的人才。为什么？因为做前端架构必须要深入了解业务，同时要务必了解业务团队的能力模型。比如：我们都知道，解决规模化生产的javascript开发模式有很多种，未必一定是AMD或CMD，还有以命名空间或类继承为原子模型的js组件化架构，等等。但是，不同类型的多人协作开发模式，对于前端开发者的能力要求是不一样的。很显然，AMD或CMD规范的模块化方案对于开发者的能力要求是最低，而以一个通用基类+继承的组件化方案，对开发者的要求可能是最高的。为什么我会这么说？因为很多初中级的前端还可能还不知道何为类，何为继承。js的类和继承并不是那么的直接，请问你要他如何在这种开发模式下书写业务逻辑？而AMD或CMD就不一样了，我可以不要求你务必理解规范的意义，但我可以强制要求开发人员严格按照规范的实施标准，依葫芦画瓢，让前端组员快速参与到业务逻辑的开发中。相比之下，AMD的规范更加死板，但也更加容易对入门的开发者进行强制要求，对于小成本的创业型项目，就能快速地通过简单培训，让初级的前端也能参与到业务的开发上来，这也就是我为什么一直使用requireJS作为前端架构的模块化方案的原因。因为它足够简单，入手的资料也齐全，我连培训文档都不用自己书写（像阮一峰这样的大神分享的知识、文档给创业项目太多的帮助了），而我所经历的都是创业项目，初期的给到手上的工程师质量是层次不齐的，从4k-5K到10K+++不等，请问这样的原材料，如果要像不缺钱的项目那样使用各种高档的性能可能更好的模块化方案，可行吗？换做是你会这么干吗？创业一定要压缩成本，以最小的成本做出价值，这才是一个合格的架构师该考虑的，性能啊，设计模式啊，这些都不是最重要的。请问如果一直是在高大上的项目打滚的前端工程化设计开发者，咱们花大成本挖他过来，给到创业项目的方案可能是无法落地的。我所在的第3个电商项目就出现了这样的情况，花大价钱挖来了一批来自BAT的前端高工，但是出来好多前端解决方案都是无法落地。当然，我从他们给出的解决方案以及相关的代码中，学到了很多，让我见识了淘宝、百度之类的一些内部前端开发模式。在这里，我可以给半路出家没有机会进入顶级公司的人，你真的想知道别人如何做的，或想了解细节是什么。说实在的，有太多的途径了。最简单的一招就是——比如利用招聘需求，发布一个高要求高薪资的岗位，让HR帮你把对应的人给约过来，多聊一聊，就基本能知道了。谁叫大公司的HR喜欢带有色眼镜看待半路出家的人，难道你就不能以牙还牙以眼还眼吗？这种招数我确实用过一两次，但毕竟是灰色手段，用多了对身心健康是有害的。最佳的方法是多看人家分享的演讲视频，多参加行业交流。比如这两年我通过自费参加的行业分享会的事情，报名费和路费没有万把块也有好几千了吧，当然如果能通过公司层面的企业间交流或引入高级人才来获得成长机会当然是最好的。越是高端的人才，掌握的核心知识点就越多，当然价值会越高。半路出家的和尚一定要把握好这种智力资源，务必要对高端知识有良好的嗅觉！！！对的，能力比你强的人，对你来说就一种活着的智力资源，而不是你的职场对手，做人别那么狭隘。比如我第1个电商项目，从2012年开始到2013年公司融资成后引入了一批优秀的人才，我当时是拿着8K的薪水，干着项目经理的活，而引入的手下却拿着你两倍甚至更高的薪酬时（我是主管，手下的薪酬我一定是有办法知道的，不管公司层面再怎么保密也是没法的，当然这种属于非常初级别的权力游戏，如果你连这点手段都不会使，你可能需要回炉去做最底层的开发者），作为主管的你是会不会觉得心里极度不平衡？不患寡患不均，这是人性的弱点。当然，我也没那么高尚，那时候也一样有些觉得不忿。但是，当你看到别人确实比你强悍，理念比你先进的时候，请一定把这种人性中丑陋的一面藏起来，敞开你的心胸去接受这种事实，并虚心向比你优秀的人学习。=======================（下）=======================打住，有点跑题了。咱们还是来聊前端这份职业的发展问题。职业发展其实是一个很虚但又很实际的话题，我其实给不了具体的答案。我尽可能尝试写出一点点有价值的看法。我认为，谈论任何一种职业的发展，都得先从企业需求的角度来分析，到底这个市场需要怎样的前端开发高阶人才，这样才有让我们这些开发从业者有机会去思考满足需求这个问题，进而才能正确地确立一个可行的职业发展方向。咱们做开发的应该很明白这个逻辑——先要有开发需求，然后才会有你去写代码，实现需求；而不是我先写一份代码，诞生某种需求，然后你要企业来为这个需求买单吧？很显然，这个逻辑走不通的。ok，让我们把时间坐标往前挪动一下。回想一下，10年甚至更高以前，有多少企业会需要前端开发这种工种？可能没有多少吧？比如我们耳熟能详的淘宝，一开始前端都是后端兼顾着去做的，不是吗？哪来前端一说呢？但是时间再往后推移一点，来到2010年前后，互联网进入了高速发展期，尤其是电商，除了淘宝天猫、京东等先期的玩家外，还大量涌现了如唯品会、美丽说、蘑菇街以及以美团为代表团购类电商等等一大批玩家，并很快获得了巨额融资而进入高速发展期，堪称野蛮成长。当然，从技术的角度，野蛮成长的背后是有代价的，前面我反复强调过，电商是以市场营销为导向的，绝大多数开发资源都要以满足营销需求为第一要务，追求极限的业务发展速度，而可能忽略了技术层面技术设施的建设。当然，这也是技术人的角度。从企业的角度并不是这么一回事，除非技术项目的管理者（最好是创始人）在一开始就意识到，前端技术精细化是有价值的，企业才会重视前端技术基础设施建设的问题，而预留部分开发资源来解决这一问题。当然，绝大多数现实并不是这样的，我们可以通过相关的前端代码来分析得出这个结论，但还是存在不少有这样眼光的企业，而在技术上的具备某种优势，比如天猫。当然，这还是技术层面的观点。但你不能否认天猫的前端基础设施建设是国内所有电商中做得最好的吧？因此，这个观点至少是站得住脚的。正因为有需求，所以才会有给我们前端从业者快速成长的机会，这一段时间涌现了大量的前端顶尖人才以及相应的解决方案，比如seajs、kissy等技术方案雏形就是诞生在这一个快速成长市场背后。所谓时势造英雄，说的就是应该是这个道理。那么，我扯这么多干嘛呢？和你我的前端职业发展有什么关系吗？当然有关系啦。在一线的互联网企业优秀的人才储备更胜一筹，顶尖人才对于未来技术的探索和思考一般会走在前面，包括前瞻性的开发理念和开发意识。比如，一般的项目（特别是外包项目）还采用前后端混合开发的时候，人家已经在探索前端模块化的解决方案，当你还直接把js写在服务端模板层上的时候，甚至一些js方法和逻辑还需要用后端语言来辅助做判断的时候，人家已经在实施前后端分离开发这个事情了……但问题是你知道别人在做这些吗？知道了，那么你又能意识到这些东西的价值吗？比如这种：我也就是随手下载的一个开源商业系统，随便一点就找到了这种‘漂亮’的模板，外包项目基本就是天天做这种活的，很多电商创业初期就是从这种模板系统开始的。请问这种项目该如何做重构，如何做前后端分离？我可以保证，绝大多数项目到死也没有把这个问题解决。不过如果你有能力做好这件事情，那么你的价值就不会太低的，当然，我觉得自己有这个能力，你呢？正是因为我曾经在外包或企业网站级别的项目中做过2-3年，但始终得不到很好的成长，表现在薪酬上一直难以寸进，甚至比不上写稿，当然我做外包项目的同时，为了生存只能坚持给媒体供稿，包括和编辑合作写枪稿，稿费很高，但很不客观，甚至自己都觉得恶心。不过这是为了生存，也不怕你笑话，谁没有过低谷呢？你说对吧？因此，如果大家有机会进入这样的企业历练那就抓住，这是快速成长的最佳途径。当然，如果你没有机会，那么也不用太沮丧。随着时间再往后推移（就是2012年左右吧，nodejs逐步稳定起来之后），越来越多的企业开始意识到，前端技术精细化的价值，包括二线三线四线的电商企业。那么，如果你没有机会进入一线的企业，在一些二线三线的电商里面也可以获得非常不错的发展机会。这样的机会依然大量存在，这两年新创的具备电商基因的企业实在是有点多。你会发现，我之所以能快速成长，其实是因为我一直呆在电商这个领域。这个领域的特点是技术会跟钱直接打交道，你开发的程序控制着钱的流向以及要负责它的安全问题。因为钱这个玩意，大家都是很在意的，少一毛多一毛都是敏感的。比如你抢个1毛钱红包都是很值得高兴的事情，正因为如此，涉及钱的平台，它背后的技术力量就需要更加小心而谨慎了，用户对此是非常非常敏感的。你一个按钮稍微反应慢一点点，就可能让用户对你的信任度减少那么一点点，而这个市场并不只是你一个玩家，更加极致的用户体验就可能成为分出胜负手的关键。那么，用户体验的最佳解决者的价值就呈现出来了，因此具备电商基因的互联网项目都必须对前端重视起来。其实，广义的角度，绝大多数的互联网项目都或多或少要和钱打交道的，间接或直接罢了。========================到这里我不想再说太多了，免得超越了太多人文字阅读的极限。因此，我需要对篇幅进行控制。不要误会，不是我没有东西可说，只是这里似乎已经不再适合。ok，还是从我自己说起。这两年的求职经历告诉我，当我转行前端并获得的高速成长的机会，事实上得益于互联网电商野蛮成长背后，一开始对前端精细化的不够重视带来的机遇，如果前几年企业就已经意识到了这一点，并对前端技术设施建设有一个良好的规划，并安排相应的开发资源，那么我这种野路子和尚是的价值就可能打一些折扣。可以预计得到，一旦前端技术设施建设完善，那么支撑前端精细化背后的工程化技术的价值就会被弱化。但是，现在前端精细化的进程才刚刚开始，甚至现在市面上连一本阐述前端工程化方面的解决方案的教育性书籍都没有（我建议
大侠出一本，但不要放入太多百度的东西，如果有行业的编辑看到，我建议可以组织这样一个话题书籍，会有市场的）。我这么说，你能感受到这里面的职场机遇吗？这是前端从业者的舞台，欢迎加入。十，关于我的转行和职业发展的超级野路子——准职业选手转编辑再转php开发再转前端先来一张大家很熟悉的图，后面几章我会聊聊此图与coder，可能会是不客观的，甚至是主观的臆断，但我可以保证话题还是有一点新颖性的。不过，我需要做比较长的转行铺垫，所以务必请客官您见谅。我还是建议能看则看，看不下去就真的不要勉强。但如果你对这个话题有兴趣，不妨将就一下看看。（一）如果有人问我，做写手、编辑的经历对我现在有影响吗？对我个人来说，是正能量，还是负能量？我会不假思索地告诉Ta，有深刻影响，并且是正能量。从某个角度，是非常大的一种优势，而且这种优势可能是从始至终的。为什么？当然，从刚开始切入写程序的时候，可能会有点点羁绊，毕竟从写文字进入到写代码，这是非常规的跳跃。码字是一个相对感性的过程，太过理性的思维是写不出让人拍案的文字的，那些文采飞扬的作品大多是那些性格忧郁、内心情感丰富的人留下，或在不太理性的状态下写出来的，比如酒醉之后，情感受伤之时，抑或是人生失意的那些时刻。这种作品很多很多，就列举了。。。当然，我的文字能力远远达不到这种级别，可能一辈子也没有这种能力，最多就是能用文字把自己的意思表达清楚的水平，这点自觉我还是有的。因此，我是做不了大众文化类的编辑记者的，没这个能力，但是有很多对文笔要求并不高的媒体可供选择，比如IT类媒体。当然，我并不是说IT类媒体就对文字能力就没有任何要求，只是相对低一些。而我所在的报社其实是具备完整的新闻采编资格的（那时候网络媒体还不被承认，网媒大多是没有新闻采编资格的），因此即便文字能力再烂，我也得努力去提高自己的文字水平，做一些参悟文学修养的事，要不老是写一些没什么修养的文字，你也不太可能有资格去做更深层次的内容，或去做采访这种高难度的动作，对吧。因此，我也曾经修炼过类似《如何提高新闻编辑的职业素养》，参阅各种文学作品，甚至也尝试去考取《新闻记者证》这种事情。当然，努力过但无奈能力太弱了，拿不到，简直就是失败编辑的典范。哎！经过深刻反思后，我觉得自己该转业了，否则一方面平面媒体下坡路的速度在加快，IT类媒体更为明显，另一方面文字修养的缺失，自己是走不好靠码字来生活这条路的。怎么办？当时我是很迷茫的，并不知道自己未来该做什么。但危机意识相对强烈的我，深深地知道，该重新找活路了，但我并不是特别明确具体的方向在哪里？那时我已经27-28了。如果有类似的经历，你一定能感受得到，那种内心的彷徨与挣扎。（如果你能看到这里，我想你应该给我点个赞吧？）但毕竟我所在的媒体和IT很近，很近，经常和各种IT软硬件人士、互联网人士有接触，包括帮他们写写枪稿什么的。我的客户譬如3721、阿里巴巴、百度、网易、搜狗、华硕、微星等，对的，没准某个xxxx平台商家入驻的成功案例就出自咱的手笔，只是你未必知道那是俺们这些文编的随意捏造，但做软件或互联网产品市场运营的人士一定一定知道这里面的猫腻。这是灰色的运营手段，但大家不也天天用吗？而且，很多互联网产品就是这么运作起来的。世界就是这么好玩，许多知名的互联网产品或平台也有它的原罪，也需要通过灰色的手段来完成原始的积累，甚至需要通过“坑蒙拐骗”的方式来教育市场，激活潜在的需求！打住，不能再说了，跑题了。这绝对是我个人的臆想，请别乱猜测，没根没据的，我只是写个故事，你不能当真。（二）得益于多年媒体的经历（其实也没几年了，3-4年吧，只是大学就开始写稿了，算起来也是码字生涯的一部分，所以对我自己来说是很长的了），或多或少让我具备了比一般人相对灵敏的嗅觉，特别是对行业未来的发展层面上的观察与思考——认定互联网是未来的必然趋势，里面应该有很多职业的机遇，就这样我想着去从事和互联网相关的事情……另一方面，也是因为我喜欢捣鼓研究各种自己不太擅长的东西，比如玩玩吉他（这样是觉得妹子会喜欢），捣鼓计算机软硬件，以及开发程序什么的，例如玩玩wordpress和自己弄一套模板，用phpcms/dedecms等内容系统建个素材站，也或者搞搞dz论坛系统，顺便业余借个企业网站外包的单子，当然还有很多。。。甚至，为了给电脑报、电脑爱好者写出高质量的稿件，我认真地去啃类似《 》这样的巨作，膜拜大神级偶像Mark Russinovich，经常去逛人家的博客 ，意外地锻炼了英文阅读的能力。当然，还会拆开电源、音箱、显卡甚至CPU，研究它们内部线路细节什么的。真的，什么是好电源，什么是烂显卡，CPU多核心与多进程的区别，这些我还算比较清楚的，不过CPU这个玩意真(TM)比较深奥。。。当然，为了努力提高自己的编辑/记者的素养，《如何成为顶级记者》这种作品是要读的。为了改善文字能力，或增长见识吧，还阅读了不少经济类、金融类以及品牌营销类作品，譬如《博弈论》、《货币战争》、《营销管理》、《定位》、《品牌之源》，甚至《资治通鉴》、《变态心理学》这种玩意都还涉猎过……其实，我还未曾告诉你，咱一度+差点成为了电竞职业选手，要不咱们来玩玩《星际争霸》，曾经水平大约在VS平台16/17级的样子，Terran选手，现在最多5级，老了打不动了，APM太低了，操作不了那么多兵种，TVP、TVT的机械化玩法或许还能搞搞，但极限暴兵流或TVZ的SK打法是玩不了的，对APM要求太高了，但给点时间，让我找回点点意识，或许跟你玩玩超低APM的意识流大招，黑死你……对，“意识流”，这个词上面我用过，这是电竞行业术语，我没有乱造词吧？如果没有记错，我似乎和魔兽人皇sky有过星际的对战记录，那时他还在打星际（真的他曾经打过星际，Home战队），每当我职业发展不顺的时候，还偶尔到浩方平台扮鸟，找心理平衡，当然也经常碰到被找平衡的。大家应该知道的，电竞是1万个人中可能只有1-2个人有饭吃，其他人都没得吃的行业，这明显不适合资质普通的玩家，比如我，电竞是玩不的了，那只有转行当写手吧。其实，那时我大学还没玩完，就出来做编辑了，也就是没毕业就做和专业无关的事情，码字的编辑。为啥？通宵练级是要钱的，没钱就给IT媒体写写稿子，挣网吧费。你说这个法子，可行吧？你知道的，电子游戏玩得不赖的人，电脑知识还是很丰富的，那就给IT媒体供稿其实不是什么有难度的事情，而且那时候IT媒体稿费比大众文化类媒体还要高一点，毕竟懂电脑的人真的不多，而电脑知识的普及初期就必然让拥有这方面知识的人价值高那么一点点。真的，如果骗你，那就让我的代码天天爆出bug，这么毒的誓言，你不会不信吧？？玩电竞游戏的，其实都是穷鬼，拥有一个游戏以外的谋生手段是必要的，所以我就开始多多写稿，写着写着就成了编辑，这个过渡还算自然的，对吧？尼玛，这位答主明显在吹牛了……都说了，这一章不会那么客观的，只是我的个人臆想，就是在努力说明我的路子有多野，仅此而已。再次，我真的要请你不要当真，权当这一章是答主我在写一篇半路转行当程序员的YY小说好了。因为连我自己都觉得，这样才是符合逻辑的。嗯，就是这样才符合逻辑，要不这样的职业路子，谁都走不通，形成不了闭环。不过呢，如果你想约我打星际，有空我们可以找个地方联机，比如QQ对战平台，没玩过星际的或只能和电脑玩玩的，我让你一个SCV或让你再加一家电脑玩家，输赢无所谓，就当娱乐，做个朋友也行，咱们“不能打一辈子星际，却能做一辈子朋友”，有兴趣私信约战吧。-------------------------------不说游戏了，我觉得这一章有点点乱，需要稍微简单整理一下，从大学开始之后的事情以及职业发展线路：大学与游戏大一 --&
--&开始变坏，玩游戏 --& 大三 --& 变得更坏，通宵玩游戏 --& 玩出花样了，参加比赛
--& 投入更多时间练习，烧钱（小钱） --& 没钱，挂科
--& 大四补 --& 没钱升级 --&
--& 白天写稿，晚上打联赛
--& 发现写稿似乎可以致富（大四上半学期基本每月可以拿到4K左右的稿费，别人找工作大多数是达不到这个水位的）--&卖力写稿 --& 大四下半学期被招安当编辑（非编制内的），结果是忙于写稿和打比赛忘记把学位这玩意拿到手里面了。。。甚感遗憾编辑与枪手上班 --& 写稿 ，玩游戏 --& 上班 --& 写稿 ，偶尔玩游戏，研究php系统 - -& 上班 --& 写稿，写枪稿，捣鼓php开源系统 --& 危机（06/07年），IT媒体日渐衰落，软件硬件厂商的广告投放开始缩水，并逐步向网络媒体倾斜，比如太平洋、zol之类的。。。怎么办？--& 痛苦中写稿，写更恶心的枪稿
--& 偶尔发现企业网站开发需求，用dedecms/phpcms/dz接单 --& 转行外包外包项目--&企业站开发、维护，可能包括运营+运维，此外还是要做外包……（痛苦的经历，不想再写了）电商 --&电商 --&电商 --&电商 --&now……（请回头看上面的章节）（这种路子够野吧？请记得点赞！！我需要鼓励，要不这程序没法继续跑下去了）十一，个人素养与coding（一）——我是如何反复“打怪”强化“代码素养”的？打住！一定要打住了。铺垫大约就这么多了。咱们还是回来说说素养和coding这两件事情。两个词，coding就不用解析了吧？咱们来谈谈何为素养？素养，谓由训练和实践而获得的技巧或能力。《·李寻传》：“马不伏历，不可以趋道；士不素养，不可以重国。” 宋陆游 《上殿札子》：“气不素养，临事惶遽。” 《·刘表传》：“ 越有所素养者，使人示之以利，必持众来。”[accomplishment]∶由训练和实践而获得的技巧或能力比如 军事素养[attainment]∶平素的修养比如 理论素养我的语文在高考这件事情上，是不及格的，所以我的解析也只是抄的，希望这个解析大家还能理解，这是能力极限了。不能理解也关系，我们把范围缩小一点点，只聊“代码素养”，毕竟我们是玩代码的。所谓代码素养，其实就是由demo训练和项目实践而获得的代码技巧或代码能力。这么说，还算通顺吧？代码素养越高，意味着代码能力或技巧越高，而这种高度是可以通过demo反复训练和项目重复实践来获取或提高。当然，你的代码素养越高，你的级别也越高，当然，能产出的价值也就越高，这个逻辑也还算通顺吧？是的，反复训练和重复实践，这两点非常重要，在相同类型的项目中反复训练，别人做一两次，我能力弱一点，就多作几次。简单列举一下参与过的垂直电商中必须要通关的，而反复训练的关卡：攒一套适合电商创业项目的前端工程化解决方案框架，前后迭代了5个大版本，包括pc端和H5端的，至少n个细分小版本。以成型的开源商业系统为雏形的电商项目中，做全站的前端性能优化、前端代码模块化，前后端分离开发模式设计，4次。其中，2次是全新项目，2次是已经跑起来的项目。登录注册找回密码等业务模块开发，页面形式的3次，全站通用弹窗2次，https协议的1次，最近一次就不想再搞了，把机会留给没弄过的小弟。电商首页首屏性能优化项目，3次。电商全站通用侧边栏切图+js交互逻辑开发，3次，（对，就像tmall、聚美优品、VIP右侧黑黑的那条东西，其中要求兼容IE6的1次）购物车、订单提交、付款等前端逻辑开发或重构，2次。最近这个项目，我实在是不太想再写了，不过代码review这种事情一定要好好处理的，这里涉及钱，很重要。商品详情页切图+前端业务逻辑开发或重构，3次（有一次还包括自己书写php端的部分业务逻辑），也是最近一次不想再写了，只负责review。后台专题发布和管理系统的专用编辑器开发，1次，这玩意实在太恶心了，很难搞。SPA项目开发1次，首次接触前端MVC，Ant.js+Underscore.js
有人用过这个玩意吗？当时还不知道存在backbone/AngularJS 这些更高大上的玩意。webIM项目开发1次，首次接触这个牛逼的库，但这是一个烂掉的项目。全静态html+restful api交互的H5项目开发，2次（1次是部分参与，1次是从零开始）。最近在写nodejs版本restful代理，打算再上一个能够解决SEO问题的但由前端完全控制的版本，后端只提供API，view层逻辑不想他们参合进来，页面优化这个事情还是由前端来主导的好。微信JSSDK接口开发，比如分享领红包、优惠券功能（类似滴滴打车那种分享有礼的营销需求），1次。我有预感，还会有更多这样的需求。此外，还包括创业电商项目的各种疑难，譬如全站兼容IE6，就是第3个电商项目，老板说了，人家淘宝、唯品会、聚美优品能做到的，我们也得做到，这个要求不算很过分吧？提出这个需求的时候，项目上线已经有2个月了，而我手下已经有3个前端人才了（都不用10K的哦）。还有秒杀活动、满减满赠、邀请注册送优惠券、首次登录送现金券，等等一大堆杂七杂八的，不记得多少了，反正不是自己写就是督促别人写，但遇到困难或解决不了的问题，还得你提供解决方案，甚至自己来写的需求还有挺多的，开发节奏太快了，一时半会想不起来了。ok，如果你要做垂直类电商，相信我，这些关卡你至少都要碰到通关一次，除非不用市场运营就也能玩出花样的，可能是例外。对了，差点忘记提醒了，记得短信接口被刷这个事情，特别是你有送消费券的时候，一定有人来研究获得更多优惠的法门的。。。切记，防刷机制要弄好，验证码别搞那么简单的。真实的惨案：我们曾一个晚上被刷过了几万块钱短信（创业项目一开始不会有太充裕短信接口费用预算，你懂的），导致手机用户一直无法注册，结果我们发现后快速上了新的验证码机制，结果人家半天就出了新的破解fa，最后……嗯，暂时不能没有最后的。-------一个小结--------上面是通过反复“打怪”强化“代码素养”的一些方法，大家可以参考着做，尽可能以最快的速度地通关一遍，你的代码素养一定能快速提升的。我足足用了2年的样子，挺长的时间，希望你可以更快速通关。十二，个人素养与coding（二）——电竞和编辑经历与开发基本功素养的关系咱们继续聊聊素养，希望把这个玩意能聊出点花样。素养，即平素的修养。嗯，咱们需要聊的其实是“修养”，聊聊程序员开发者的“修身养性”这个问题。这YY类文章着实容易写得很长很长。你还记得我上面曾经说过要“对代码要有洁癖”这个句话吗？如果不记得，你可以回去找找，大概在第8章的样子。嗯，不要误会，我生活中并有“洁癖”没这回事，老婆总是说我挺邋遢的，和洁癖有毛关系都没有。我只是要对代码有洁癖，这又啥好处呢？代码的洁癖是什么？嗯，我又想来对文字下定义了，这习惯必须坚持。所谓的代码洁癖，是对代码素养的一种形象化描述。这么说吧，当我们形容一个人有洁癖时，你会觉得这个习惯可能不太好，但你一定不会觉得这人生活中是邋遢的，只是这家伙很讲究卫生而已，包括个人穿着打扮，生活环境修理，等等。只是我们大多数时候并不太喜欢这种人，因为TA可能太讲究卫生了，而导致无法很好地与人相处，甚至要求别人和TA一样必须讲究卫生。而在这种人的生活习惯或态度方面，认为这是理所当然的，坐的凳子必须是一尘不染的，喝水吃饭的家伙一定要反复反复消毒杀菌后才能使用的……但是，如果拥有洁癖的人，当在与人相处时并没有强制要求别人与之一样，并适度容忍别人的不干净（ta眼里的），那么我们是否可以认为这种人是有修养的呢？相信你是有答案的。我的答案也应该和大多数人一致。是的，这是人有修养的一种表现。好吧，别跑题了，我们还来谈谈代码的洁癖。我还是习惯对抽象的进行实例化，实例的东西才容易理解，因此我尽可能列举所能想到的，并适当地展开加上我个人的理解和分析。我认为，程序开发者的素养包括代码基本功素养、战术素养、战略素养等三个层面的素养。这里先聊聊，第一个基本功素养。这个基本功的范围其实很大，但前端这一块就是css、html和js这三板斧。比如这些东西：js的变量类型，基础语法，又或者例如代码格式的统一，整洁等。如一个空格，一次换行，使用单引号还是双引号，这些都要按照自己认为的最佳标准来实施，并极可能地去坚持。如图：如图2：看到这种规范标准，你认为有多少可执行度？并且这种东西对于业务逻辑的完整有影响吗？当然是不会有影响的，当然知道没有多少人会去落实和坚持的，这只是我给前端团队设置的一种代码建议性质的规范。很显然，坚持这种东西，不会对你的能力有立竿见影的。但我自己会尽可能按照这样的标准去书写我自己的代码，仅此而已。在很多人，特别是越是低级别的选手，越会对这种规范嗅之以鼻，认为这种东西是很没有道理，何必坚持，甚至作为一种规范。但为什么我会这么做？这其实受我以前玩竞技游戏，做战队选手打比赛（在当时的战队我都是一线的打手），和大量高手对决而得出来感悟。如果你有一定玩竞技游戏（比如星际、魔兽、cs等）的经历，并能看懂高手之间的对决，你一定能理解高手对决，决定胜负的可能就是当初那个资源采集快那么一点点的那位选手。比如，星际里面4个采矿农民一开始是否同时被分配到分别去采集4个矿，而这种分配的操作手法是非常重要的基本素养，就是要反反复复联系并成为一种基本技能的，甚至对于不同出生点而带来的采矿距离的些小差距，都可能是决定胜负走向，战术选择的决定性因素，有兴趣大家可以去看看星际职业比赛录像（很多视频网站是有的），职业选手是多麽在意这一点的不一样，但许许多多的入门选手是不会这么做的。当然，我自己做得还不错，并获得了和许多职业选手对决的机会，负多胜少。很显然，普通玩家或低级别的选手是看不懂高级别选手是如何获得优势的，当你的玩家素养和对手有着不可弥补的差距时，别人想怎么玩你就怎么玩你，除非这种差距不大，那么战术选择、操作的好坏，抑或是运气才会成为决定胜负的关键，否则你可能觉得别人在作弊，或误以为你的战术不行或运气太差。别乱想，我告诉你这只是表面原因，深层次的原因可能就是基本功素养，这种很抽象的概念。然而，良好的基本功素养并不是一早一夕能养成的。这需要你一开始就要意识到，一旦养成了不好的习惯，这种习惯到后面就可能无法调整了，因为它已经成为一种习惯。例如你是用哪个手指来按shift+1、ctrl+1键的？当你习惯用大拇指而不是小指去按，这种习惯一旦形成就很难更改了。这样的实例你能明白吧？好吧，这种按键习惯就是职业选手要非常在意的，因为不同的按键方式在操作大量兵种作战时，连续操作的速度和细腻程度是不一样的！为什么韩国的职业选手那么厉害？就是因为别人在打基础的时候已经有意识并刻意地练习这些东西，而绝大多数人已经养成了不好的习惯，当你似乎到达某个高段位的时候会发现，在怎么努力也难以寸进，其实这是基础素养没有做好。我这么说，你能理解什么是基础素养了吗？其实我在一开始就意识到这个问题的重要，所以当我获得同样的练习机会时，哪怕我的年纪大一些，记忆力差一些，甚至精力也比你弱，可能就比一般的同学进步要快一些。这种基本素养的高低还和时间有关系，我转前端的时间并不长，所以扎实程度就是我和顶级选手的距离，这需要时间来弥补。不过，你不觉得代码格式这种基本功力，和平面媒体对于标题、文字格式、标点符号甚至大纲提炼等编辑规范或素养是一脉相承的吗？其实啊，一部分基本我很早已经练好了，但你未必知道而已，我缺少的是对于开发语言基础知识的了解，这个不会有多难的，对吧？“良好的编辑素养就是我做程序开发的先发优势，而这种优势可能是从始至终的。”这话说得并不是没根没据的，对吧！？--------------------个人素养与coding（三）——开发者的战术素养和程序的正与邪，开发者的道不同不相为谋（一）扎实的基本功需要长时间地做针对性的反复练习，这个是没有捷径的。但是战术层面的东西却是可以快速提升的，只要你获得足够多的项目实战机会。我通过哪些项目获得实战训练，这个上面才刚刚说了，并列举了好多电商领域必须尝试的对战“地图”和“关卡”，我就不再赘述。在这里，我似乎又得对战术这个词进行一下解析了。要不可能你无法理解这个东西与前端开发有什么关系，它们之间的相互又逻辑是什么？何为战术？所谓战术，就是指导和进行战斗的方法。主要包括：战斗基本原则以及战斗部署、协同动作、战斗指挥、战斗行动、战斗保障、后勤保障和技术保障等。ok，我们来造一下句子。尝试用“开发”来替代“战斗”，试试语句通不通顺。所谓战术，就是指导和进行开发的方法。主要包括：开发基本原则以及开发部署、协同动作、开发指挥、开发行动、开发保障、后勤保障和技术保障等。咦！还是很通顺的嘛！那么，开发前面再加一个修饰词，变成“前端开发”或“后端开发”。其实，都是通顺的，不是吗？这就是项目开发和战术的基本关系了。很多东西是相同。咱们这里既然是谈“术”这种高层次的话题。那么，我就不是从一个低阶的开发者角度来思考的了，请你务必要把层次提一提。好吧？我先说，不同的战役，指挥官要根据不同的地形、地貌，甚至是战斗人员能力结构，以及要攻克的目标特点，做不一样的部署，采用不同的战术或方法来解决战斗。这么说没问题吧？我认为，任何一种架构设计（战术设计），离开了具体业务场景（战斗场景）来谈它如何设计，或评估其价值的高低，都是不科学的，也是不理性的，甚至是耍流氓的。为什么可以这么说？还是从我的个人经历说起。就在今年年初，我还不是特别确定是否接手现在这个电商项目的时候，曾经被猎头推荐去面试过一家做邮箱系统项目开发的前端架构师一职。跟对方的中间层首席架构师聊，对方是做java的，而我是做js或php的，当我把我做过的电商前端架构设计方案或理念拿出来和对方沟通时，对方其实没有什么反应的，甚至我说电商对于用户体验的要求是苛刻的，但对方却很难理解这种苛刻到底是什么？而被对方问到，邮箱系统到底该如何做前端架构设计时，我其实是没有腹案的，我又怎么能有腹案呢？对于邮箱的业务我是一点点也不了解，但是他会认为前端架构不都是一样的吗？这种认知我很难在面试的过程中，用三言两语的方式描述清楚，更何况对方并不是一个前端，对吧？最后的结局当然是，我认为这个项目的前端架构职位不适合我，他们也认为我不是适合的人选，鄙视我做过的东西或项目，甚至我压根没资格来应聘这样的岗位。其实，我就是想了解一下邮箱系统到底怎么弄出来的，并没有想过获得这样的offer，对方是怎么想的，我其实一点儿也不关心。当然，如果真想去做邮箱系统的前端架构，我可能不会这样贸然地去应聘这个职位，而是降职的方式去做邮箱系统的一般前端业务开发，当我熟悉了业务，知道这里面和电商项目不一样的地方，那么我就会尝试给项目做一次架构层面的重构，进而把自己提升为事实上的架构师。ok，这就是技战术层面的选择。也就说，如果企业想要招前端架构，我是不建议跨行业去招聘的，最好的方式内部物色一个有潜力的进行培养（容许他犯错，只要不是根本性的），或者从同行那边挖人才是最快的。如果非要跨行业也不是不可以，但你可能要让人家拿着架构师级别的薪酬来做一般前端的事情，等他熟悉业务之后，再让他来做架构，否则是不可能有合理的方案出台的。很显然，不是每个公司的决策者都能有这种意识的，不是吗？谁傻啊！当然，我碰到的并不是傻子。（二）ok，我们再就战术中的“术”聊一聊。在这里，我尝试谈谈，何为开发者的道不同不相为谋？谁是光明正大的程序员，谁又可能是心术不正的码农？话题还是新颖的。术有正邪,道则一也。首先，我们要接受这个观点（不是我的，不知道那个佛学书籍或道学书籍中的一句）。也即是，术是有正术和邪术之分的。1，何为正义？何为邪恶？看到这个话题，好多同学可能会这么想——尼玛，写代码都写出正邪之分了，这个会不会太夸张了点？是的，代码本身并没有正邪之分，但人心却有善恶。如果你用善意的心态去书写代码，那么就可以定义为正，但如果你心存恶意地书写代码，那么就是邪。大多数情况下，这种东西是“只可意会不可言传的”，但越是高阶的开发者，你用善意还是恶意的心态去书写代码，这种影响是非常明显的，甚至是深远的。我这么说，你都还能理解吧？不懂的话，我们先来观摩两篇文章：这个话题相信不少人讨论过，对吧？其实，当一个程序开发者的开发能力进入到中高阶之后，只要你愿意，写出无法维护或很难维护的代码其实并不是很难的事情，不是吗？拿破仑说过，“永远不要（把自己遇到的问题）归因于（他人的）恶意，这恰恰说明了（你自己的）无能。”这话是非常有哲理的。但是我认为，这是伟人对自己的要求，这是没问题的，要时刻让自己保持强大，没有决绝不了的问题，即便遇到问题那也是自己能力不足。但是，我们要知道拿破仑这种牛人估计是千年一遇的，而在现实的生活中，绝大多数人都是很普通的，包括你我他，虽然很多人并不这么认为，但现实就是这样。ok，我就不把话题扯得太远，还是说会项目开发。我的意思是，在任何一个团队中，绝大多数人的能力是有限的，无所不能的人毕竟是少数。因此，“书写不可维护的代码”这种事情要尽可能避免，如果某个队员的能力比其他队员高，他一定能都写出更加简单易懂的更可维护的代码。当然，如果我们在书写代码时只是为了让自己看得懂，而不考虑他人是否看得懂，那么，我会主观上认为你是自私的，即便你是无意的。就好比意外伤人，那也是伤人，也是需要负责任的。如果，我说的是“如果”，你是故意书写不可维护的代码，那么这就是一种恶，虽然你可能只是为了保障你不被替代，不得已的一种选择。如果这个项目不需要任何其他人来维护，或许这种做法没什么问题，但是如果需要别人来维护，那么这种做法是我个人所不认同的。从维护代码的开发者角度，一旦碰到这样的代码，其实你只能像拿破仑说的那样，“不要把自己遇到的问题归根于别人的恶意”，否则只能证明你的无能，一旦项目交到你手中，你就得把问题给解决了，企业层面只会看结果，而不会问过程。但是作恶者就能逍遥快活了吗？我觉得，如果你碰到这种事情，在问题得到解决之后，必须向上一级反馈问题。至于如何处理，合格的上级会做出合理的响应。其实说了这么多，我还是很难对开发者的善恶下一个明显的定义，因为不同的环境，不同的团队，对于善恶的标准其实是不一样的。但是，我很清楚自己的善恶：善：代码书写要符合既定规范；恶：代码的书写总是破坏既定规范。善：代码逻辑的书写应该简单易懂，不书写高度抽象的函数，照顾维护者的理解能力；恶：常常定义各种高度抽象的函数，不考虑维护者的理解能力。善：根据团队成员的能力模型来做技术选型；恶：技术选型时不考虑团队成员的能力，盲目地甚至根据个人喜好来决定技术选型。还有很多，无法一一列举，也没必要列举，毕竟这只是我个人的善恶。这是从术的层面来探讨开发者的善恶，在我看来判断善恶的标准其实是，“善”的术其实就是要考虑他人（包括维护者和企业）的感受，开发者的“恶”则表现为不考虑他人的做法，不在乎他是否带有恶意。事实上，善恶是可以通过内部规范（企业法律法规）来避免或降低其影响的。在这方面，成熟的大公司往往做得更好，而创业项目或高速发展的企业往往忽视这方面的建设，进而让“恶”的开发者拥有了发挥的空间，甚至一些内部规定促使良善的开发者推向了恶的舞台。对于这种情况，开发者或许需要反思，但更应该反思的是企业！2，何为开发者的道不同不相为谋？首先，何为道？道，出自老子所著《道德经》”道可道，非常道，名可名，非常名“，又在另一段落解释说”有物混成,先天地生。独立而不改,可以为天地母。吾未知其名,强名之曰道“。在翻译《圣经》时，也借用这个词说"太初有道,道与神同在",道就是神.太初指的是，还没有时间，没有世界以前，道已经存在了，道是永存的。这是百度词典给出来的解析，其实我还是无法理解何为道。这个话题太庞大了，客官你只能自己去理解，就不纠结这个问题。但是，“道”这个东西其实是被实例化的。比如道路，通往“道”的路，指达到某种目标的途径，事物发展、变化的途径。那么，这里我想说的就和道路的“道”一致。在项目开发中，我们用来完成目标的方法和途径是很多的。但是，不同的道，对于同一个企业或项目而言，其成本和风险是不一样的；同理，相同的道，对于不同的企业或项目而言，其成本和风险也是不一样的。这是一个非常浅显的道理。如果你是“道”的决策者，只要真心站在企业或项目的角度其思考，我相信绝大多数决策者的选择都会是大同小异的。但是，不同的道对于个人而言，得失可能是不一样的，甚至是个人获得名利，而企业可能付出成本更大和风险更高。举一个开发者都能理解的例子：造轮子。前端开发领域的轮子很多，而且很多轮子是在反复制造，开发者往往不亦乐，并乐此不疲。但是，造轮子和道什么关系呢？我想说有关系，但要结合项目环境，因为不同的环境，不同的道，其影响是不一样的。这是我的亲身经历。在我经历的第三个电商项目的开发过程中，发生过这样的事情：我们有一个商家入驻平台需要开发，在技术选型上，由于后端所能投入的开发资源非常有限，只能提供API，而所有的业务逻辑主要由前端开发者来实现。也就是说，这是一个前端主导的项目，很重要，是平台商品的入口，但是这个需求其实也是限时实现，开发周期其实2个星期，开发人员是3个（1个后端，2个前端），如果项目交给你去负责，请问你会选择怎样的前端技术方案？当然，这种需求其实是一个管理后台，基于纯API的前端交互相对复杂，而且表单很多，因此双向数据绑定的MV*框架是最合适的，再考虑到时间周期较短，如果给我做技术选型，会选择一款开源的MV*（比如angular、avalon、Vue、backbone等）+jQuery，学习成本低，有问题也容易在相应的社区找到解决方法或思路。但这个项目并不是我负责，而是由另一位前端经理来做技术选型，他的方案是自己开发数据绑定的框架，重新实现一个可双向数据绑定的底层框架来搭配jQuery。当然，他造轮子的能力很不错，基本完成自己的轮子的同事，大约用了1个月的时间完成了项目的开发。事实上，1个月的开发周期是上面对这个项目的底线，因此这个项目还是很受领导认可的。当然，他选择自造轮子可能是出于对技术实力的自信，这是无可厚非的，而且从个人角度触发，有机会造轮子就别放过，这对自己技术的提升是很有好处的，而且有机会应用到商业项目中，这样的机会简直是千载难逢。但是，我不会这么做，并为此和他产生了冲突，吵了一架，搞得需要领导来调和。其实这个项目又不是我负责，别人的死活与我何干？与他的冲突是开发理念层面的，也就是我所谓的道不同不相为谋。因为我们还是创业型项目，而前端开发人员整体技术能力都是很一般的，不要说造轮子了，能够顺利完成业务逻辑就已经谢天谢地了。就在这样的情况下，他并不是选择成熟的、开发文档完善的方案，而是选择自己造一个轮子（开发文档是没有的，因为没有时间，单元测试更不要说了）。即便项目是完成了，但这样做的后果就是，以后这个项目除非完全重构，否则只能由他来负责到底，这完全是一种长期绑架的做法，和书写不可维护的代码有何区别？但是他用的是一种比“术”高层次的方式，实现了自己的“不可替代”，这就是“道”。当然，如果我们是一个大公司，有很多具备造MV*轮子能力的前端开发人才，其实多造轮子这种事情就不会是什么大问题，比如BAT级别的厂子，他们的前端就特别喜欢造轮子，企业层面也放心让这些开发者造轮子，因为轮子造好了之后，即便制造之人离开了团队，也有很多人能够替代、接管，但对于绝大多数创业或高速发展的项目而言可能是一种奢望。后来当我尝试去了解其MV*数据绑定的实现时，发现他居然没有提供源码，而是放在自己私人的代码仓库里面进行管理，对于这种做法，我只能“呵呵”了。我原以为他已经到了“道”这种层面，其实还只是一种“术”罢了。从技术实力上，即便给同样的时间我未必有能力去造一个MV*轮子，但是他这种做法对我而言基本上就是不相为谋，矛盾其实是难调和，也为第4个电商项目的前端团队分裂埋下了伏笔（后面的故事我增加一则后记）。这是我的“道不同不相为谋”。十四，个人素养与coding（四）——开发者的战略素养对职场嗅觉的影响这里谈的是战略，也是非常高大上的话题。对于这样的话题，我表示无法驾驭，毕竟不是什么牛人，也没有啥成绩，就是一个小公司的前端开发者。在这里谈这样一个只有成功项目CEO、行业大咖，比如这样的 ，甚至只有马云、史玉柱之类的人才有资格的话题。尼玛，我这种小虾米谈论战略，事实上就有点儿不自量力了，让大家见笑了。因此，我只限于一个非常狭窄的领域——前端开发。我觉得，上述这些牛逼的人物应该没有我这个小人物精通这一块，比如咱们的马首富和我切磋切图、写js，大伙觉得谁更胜一筹？（不能请外援）如果觉得小人物更牛逼一点，那就往下看吧。我们都知道，前端是一个相对年轻的工种，大家对此依然存着各种各样的疑惑：有人
而发愁；有人对于 而心存抱怨；也有不少人为
而伤神；还有人对前端心存不屑，认为更多的同学因为不知道
而迷茫；……从这些疑惑中，我们可以看出前端其实是一个比较有争议的开发工种，但是能够被人热议，至少说明了前端并不是一个不值得关注或讨论的话题。同样都是web程序开发，后端为何没有这样的疑惑呢？如果你有详细看这篇回复，应该知道我其实是从php开发转过来做前端的，可能已经在后端这里领域的经验或能力已经退化了，甚至就一直只是一个入门的开发者，从始至终都没有进化过，专做前端开发是不得已的选择，但至少我不会看轻后端，也不会觉得前端没有前途。从更长远的时间维度来思考，前端并不受重视是因为以前它确实不那么重要。这点很多前端开发者会极力否认，但事实就是这样。尤其是2010年以前，绝大多数项目都是后端兼顾着写js，而切图则是设计师的活，拥有专职前端的项目其实是极少的。但是随着互联网竞争不断深化，特别是电商领域的互联网项目不断兴起之后，激烈的竞争让这里面的玩家对于用户体验提出了更高的要求，极致的用户体验甚至成为了胜负的关键，也因此让前端开发走到台前，成为一个必须的开发工种。这一点我在前面已经反复强调，这就是我转型前端的主要原因。当我有机会介入电商开发这个领域，由于我尚浅的开发能力，从事后端开发其实有点儿不从心的。这是实在话，当我看到前端的无线潜力之后，就一直专注于这一个领域，并且选定一个快速提升的点——前端工程化解决方案。事实上，这深受我当编辑、做写手那一段经历的影响。尽管和很多大众媒体编辑相比，我的文笔能力是有所欠缺的，这是硬伤，也是转型的重要原因。但是对于编辑素养的要求，专业的IT媒体并不比其他媒体低，而我就是在一个极度专业的IT媒体中渡过了快5年。或许有人质疑我的专业，比如PC行业的发展对我个人而言基本上可以从诞生到现在，如数家珍可能说不上，但重要的变革一定和你聊得起来的。比如我们的对手书写的这种评测文章 ，，，请问有多少人能够看得懂吗？我基本上还是秒懂的，因为曾经写过快5年这类的技术分析和评测报告。可以说，能够书写这种技术评测、行业分析报告的编辑其专业素养一定不差。这里的专业素养就包括对于技术趋势的掌控力度，观察更深刻，而嗅觉也就比一般人要灵敏。很显然，互联网其实是PC硬件高速发展的延续，什么技术在未来会更有价值，作为专业IT编辑素养的一部分，专业的IT编辑一定比普通开发者要清晰。快速地解读专业知识，善于分析和总结，并且对于未来技术要足够敏感，这就是专业IT编辑最重要的素养，而这些东西和程序开发本身并没有直接的关系。或许有，毕竟我非常了解计算机底层的硬件及其原理，很容易理解为何寄存器是最快的，而网络存储则是最慢且最不靠谱的。但是，当程序开发还在入门阶段时，相对丰富的计算机底层知识并没有太多用处，只有到了开发能力到达一定层次之后，这些知识才会让我更容易理解那些更接近底层的程序逻辑和做法。比如一台nodejs服务器开启多少线程来对外提供服务才是最佳的，如果你了解CPU的多核心和多线程的原理及其区别，很容易得到答案。当然，这种专业素养对于开发者程序开发能力的影响其实是有限的，而善于分析和深入洞察这方面的素养则对我能够精确选择一个可高速发展的点，其影响才是最为直接的。只要你是超过2年的前端开发者，前端技术高速发展的机遇你也一定遇到过，比如：nodejs出来之后，或者requirejs或seajs出现之时，抑或是grunt/gulp诞生之后，reactJs开源之后，HTML5标准发布之时……面对这些前端领域变化，你会意识到它们会给前端开发者带来怎样的机遇吗？你会知道思考这些东西可能会改变前后端协作开发的模式吗？我只是意识到了其中一点，它们会改变前端的开发模式，让前端的编辑工作自动化，前端代码发布生产是需要构建的，就像传统的java、c、c++静态语言一样，需要经过编译才能用于生产！这就意味着前端已经演变成为和其他开发语言一样，具备了通用软件语言的特性，那么就意味着web软件开发不仅需要后端架构师，也需要前端架构师，而这样的职位就是我切入前端开发时，接触到nodejs、requirejs以及gulp之后就感知到了。那是2013年的事情了，似乎已经有些遥远。在我看来，任何一个人都可以谈战略，这并不是非得到达某种普通人不可触碰的境界之时才有资格谈论的话题，它其实很浅显，战略就是一种相对长远的目光来审视当前的一些细微的变化，多花一点点心思考虑这些细小的变化可能产生的价值，会带来怎样的连锁反应。当你长时间坚持这种行为，那么在某些时刻就会成为一种比别人看的更远，这就是战略素养。很显然，战略素养很多时候和你具体开发语言没有任何关系，更多是思想层面的感悟、想法等，这些东西需要你阅读很多与技术开发无关的书籍来提升，比如《博弈论》、《黑客与画家》、《定位》、《品牌之源》等等，甚至可以是《变态心理学》这种奇葩书籍。高阶的程序开发者一定要有自己的开发理念，而理念这种玩意一般和技术无关，而是和个人的其他修养有关。就好比在一大队流氓里面，当老大的往往不是武力值最高的，而是最有文化的那个，例如刘邦，例如刘备。战略素养其实就是要做一个有文化的流氓。---------------后记：第4个电商项目——分裂，生存，可能还有崛起。这是我个人进入前端开发后的最新经历，发生在2015年3月-现在。2015年农历大年过后，我所在的项目由于投资人打算退出的原因，整个团队面临解散，但我们所做的领域其实还有很多机会，而且技术团队的核心成员很多也认同这里面还有可为，于是我们在寻找机会。事实上，其他部门有相同看法的同僚不少，并且出手更快，他们很快找到了新的投资人，需要技术团队快速切入，于是我们原班人马的核心成员商量后决定跟着他们继续干。当然，我和他（之前提到过的另一名前端负责人）都是原班人马的核心成员，但开发理念上存不可调和的矛盾。我们之间应该是心知肚明的，只是其他人未必不明白这一层面的冲突意味着什么。随后在新项目的技术选型阶段，我在原来的技术上对前端开