十日谈

一直想写这篇“十日谈”，聊聊我对Web前端开发的体会，顺便解答下周围不少人的困惑和迷惘。我不打算聊太多技术，我想，通过技术的历练，得到的反思应当更重要。

　　我一直认为自己是“初级”前端开发工程师，一方面我入道尚浅，只有短短几年，另一方面我自知对技术的钻研并不深入，可能是由于环境的原因，当然最重要的是，我幸运的参与到互联网崛起的浪潮之巅。时势造就了一批技能薄弱但备受追捧的“弄潮者”，这在很大程度上影响我们对“技术本质”的洞察力，多年来也一直未有成体系的“前端技术”布道佳作，以至于当下多数人对前端技术的了解，盖始于表述并不严谨的岗位招聘描述，而这正恰恰反映了Web前端开发对自身的模糊定位。对于很多Web前端工程师来说，初尝禁果的快感无法持续很久，就陷入一轮又一轮的迷惘，思索自己的职业规划，试图寻找到适合自己的成长道路、看清自身技能的瓶颈，寻找突破。但遗憾的是，Web前端技术被广泛接纳时日尚短，没有多少励志的成功样板可供遵循。然而情况不总是这么糟，毕竟Web前端技术是一门“技术”，和计算机科学系出同门，只是因为互联网的高速崛起而被蒙上了迷雾，遮住了双眼，让我们傻傻看不清时局。可以500%提高开发效率的前端UI框架！

　　那么，如何定义Web前端技术岗位边界？Web前端技术的价值体现在何处？前端工程师的价值仅仅体现在物以稀为贵吗？前端工程师的初级、中级、高级和专家之间到底如何界定？当前“我”处在什么位置？接下来的路子应当怎样走？何谓前端技术之“道”？我想多数人都思考过这些问题，本篇“十日谈”里的观点可能有些偏激，但抛砖引玉，读者权且把这些言论当作一个引子吧。

第一日：初尝禁果

　　【上帝说：“要有光！”便有了光】

　　万物生灵、阳光雨露盖源于造物之初的天工开物，我们无法想象上帝创造光明之前的世界模样。但幸运的是，前端开发没有神祗般的诡魅。这个技术工种的孕育、定型、发展自有轨迹，也颇有渊源，当然，这非常容易理解。不严格的讲，在杨致远和费罗在斯坦福大学的机房里撺掇出Yahoo!时，Web前端技术就已经开始进入公众视野，只不过当时没有一个响亮的名字。从那时起，“基于浏览器端的开发”就成了软件开发的新的分支，这也是Web前端技术的核心，即不论何时何地何种系统以及怎样的设备，但凡基于浏览器，都是Web前端开发的范畴（当然，这个定义很狭隘，下文会提到）。

　　在2000年之后浏览器技术渐渐成熟，Web产品也越来越丰富，中国有大批年轻人开始接触互联网，有一点需要注意，大部分人接触互联网不是始于对浏览器功能的好奇，而是被浏览器窗口内的丰富内容所吸引，我们的思维模式从一开始就被限制在一个小窗口之内，以至于很长时间内我们将“视觉”认为是一种“功能”，Web产品无非是用来展现信息之用。起初的入行者无一例外对“视觉”的关注超过了对“内容”的重视，先让页面看起来漂亮，去关注html/css，沿着“视觉呈现”的思路，继续深入下去。因此，这类人是被“视觉”所吸引，从切页面入行，着迷于结构化的html和书写工整的css，喜欢简洁优雅的UI和工整的页面设计，之后开始接触视觉特效，并使用jQuery来实现视觉特效，以此为线索，开始深入研究Dom、Bom和浏览器的渲染机制等，html/css在这些人手中就像进攻兵器，而JavaScript则更如防守的盾牌。可以500%提高开发效率的前端UI框架！

　　还有另外一群人从另一条道路接触Web前端，即工程师转行做前端，他们有较多的后台语言开发背景，从读写数据开始，渐渐触及浏览器端，接触JavaScript库，起初是在html代码上加js逻辑，后来开始涉及html和css，他们喜欢OO、逻辑清晰、结构悦目的代码，更关注界面背后的“程序语言”和数据逻辑。html/css在这些人手中则更像盾牌，而JavaScript更如进攻的兵器。

　　应当说这两类人是互补的，他们各自了解浏览器本质的一部分，一拨人对渲染引擎了如指掌，另一拨人则将JS引擎奉为至宝，其实任何一部分的优势发挥出来都能做出精品。大部分前端工程师都能从这两条渊源中找到自己的影子。但，这两类人的思维模式和观点是如此不同，以至于形成了一些不必要的对抗，比如在某些公司，干脆将Web前端技术一分为二，“切页面的”和“写js的”。这样做看上去明确了分工提高了效率，但他对员工的职业发展带来巨大伤害。在第二日“科班秀才”中会有进一步讨论。

　　我应该属于第二类，即在学校正儿八经的学习C/Java和C#之类，以为大学毕业后能去做ERP软件、桌面软件或者进某些通信公司写TCP/IP相关的程序。校园招聘时选择了中国雅虎，因为当年（08年）雅虎还是有一点儿名气，而且我听说雅虎比较算技术流的公司……自此就上了贼船，一发不可收拾。

　　在雅虎的这段时间，我有幸接触到一股正气凛然的技术流派，也形成了我对前端技术的一些基本看法，这些基本观点一直影响我至今。

　　【优雅的学院派】

　　当年雅虎的技术流派正如日中天，拥有众多“之父”级的高人，所营造出的Hack氛围实在让人陶醉的无法自拔，那段时间我甚至宁愿加班到深夜阅读海量的文档和源代码，感觉真的很舒服，我深深的被雅虎工程师这种低调务实、精工细琢的“服务精神”所打动，而这种不起眼的优秀品质很大程度的影响雅虎产品的用户体验和高质量的技术输出。那么，何谓“服务精神”？即你所做的东西是服务于人的，要么是产品客户、要么是接手你项目的人、要么是使用你开发的功能的人，所以技术文档成为伴随代码的标配。因此，工程师之间通过代码就能做到心有灵犀的沟通。这是工程师的一项基本素质，即，思路清晰的完成项目，且配备了有价值的技术文档，如果你的程序是给其他程序员用的，则更要如此，就好比你制造一款家电都要配备说明书一样。因此，YDN成了当时最受全球程序员最喜爱的技术文档库，这种优雅务实的“学院气息”让人感觉独具魅力。可以500%提高开发效率的前端UI框架！

　　让人感觉奇怪的是，在中文社区始终未见这种学院派。甚至在具有先天开源优势的Web前端技术社区里也是波澜不惊，可见写一篇好的技术文案真的比登天还难。我所见到的大部分所谓文档索性把代码里输出数据的语句块拷贝粘贴出来，至于为什么数据格式要设计成这样、如果字段有修改怎么做、编码解码要求如何等等关键信息只字不提，或者开发者也没想过这些问题呢。因此，我们一直在强调代码的质量和可维护性，但一直以来都未见效，盖源于缺少这种“服务”意识的灌输。这种意识在下文中还会多次提到，因为它能影响你做事的每个细节，是最应当首先突破的思想纠结。

　　除了意识问题，另一方面是技术问题，即文笔。这也是工程师最瞧不上眼的问题，难以置信这竟然是阻碍工程师突破瓶颈的关键所在。我已看到过数不清的人在晋升这道关卡吃了大亏，很多工程师技术实力很强，但就是表达不出来，要么罗列一大堆信息毫无重点、要么毫无趣味的讲代码细节，不知云云。除非你走狗屎运碰到一个懂技术的老板，否则真的没办法逃脱码农的宿命。但大部分人还振振有词不以为然。而在Web前端开发领域情况更甚。前端工程师是最喜欢搞重构的，但在快节奏的需求面前，你很难用“提高了可维护性”、“提升了性能”这类虚无缥缈的词藻为自己争取到时间来搞重构，说的露骨一点，可能你真的对某次重构带来的实际价值无法量化，只是“感觉代码更整洁了”而已。我会在下文的“伪架构”中会展开分析前端工程师的这种浮躁献媚的技术情结。而这正是前端工程师最欠缺的素质之一：用数据说话，用严谨科学的论据来支撑你的观点，老板不傻，有价值的东西当然会让你去做。

　　当然，情况不总是这么糟糕，我们看到中文社区中已经锻炼出了很多写手，他们在用高质量的文字推销自己的技术理念，这是一个好兆头，好的文笔是可以锻炼出来的。而在职场，特别是对前端工程师这个特殊职位来讲，这种基本技能可以帮你反思梳理需求的轻重缓急，从凌乱的需求中把握七寸所在。因为当你开始认真写一封邮件的时候，这种思考已经包含其中了。

　　所以，雅虎技术的推销是相对成功和远播的。关键在于两方面，扎实的技术功底和高超的写手。而真正的技术大牛一定是集两者与一身，不仅钻研剑道，还能产出秘籍。这也是Yahoo!优雅的学院派气息的动力源泉。国内很多技术团体想在这方面有所建树，应当首先想清楚这一点。

　　【规范的破与立 1】

　　雅虎的技术运作非常规范，刚才已经提到，包括技术、组织、文化，一切看起来有模有样，也堪称标杆，自然成了国内很多技术团队和社区的效仿对象。一时间各种“规范“成风、各色“标准“大行其道，结果是质量参差不齐。

　　我们到底需要什么样的规范？雅虎的技术规范到底有何种魔力？以何种思路构建的规范才是货真价实的？规范有着怎样的生命周期？想清楚这些问题，能很大程度减轻很多Web前端工程师的思想负担，看清一部分技术本质，避免盲目跟风。

　　我们的确需要规范，但好的规范一定是务实的，一定是“解决问题“的。比如针对项目构建的DPL可以收纳公用的视觉元件以减少重复开发、规定某OPOA项目的事件分发原则以确立增量开发的代码惯性。反之，糟糕的规范却显得过于“抽象“，比如页面性能指标、响应式设计原则。另外，尽管他山之石可以攻玉，但拿来主义有一个大前提，就是你了解你的项目的关键问题，你要优先解决的是些关键问题，而外来规范正好能解决你的问题。因此规范是一本案头手册，是一揽子问题的解决方案，应当是“字典”，而不是“教程“。可见规范的源头是“问题”。所以，当你想用CoffeeScript重构你的项目时、当你想引入CommonJS规范时、当你想在页面中揉进Bootstrap时、当你打算重复造轮子搞一套JS库时、当你想重写一套assets打包工具时，想想这些东东解决了你的什么问题？会不会带来新的问题、把事情搞复杂了？还是为了尝鲜？或者为了在简历中堂而皇之的写上使用并精通各种新技术？可以500%提高开发效率的前端UI框架！

　　规范之立应当有动因，动因来源于项目需求，项目需求则来自对产品的理解和把握，这是Web前端初级工程师走向中级甚至高级的一次重要蜕变，软件工程领域早就有“架构师”角色，而架构师往往存在于项目需求分析和概设、详设阶段。我看到的情况是，Web前端工程师的思维过多的限制在“界面”之内，向前和产品需求离的太远（认为这是视觉设计师的事）、向后和数据逻辑又隔离开来（认为这是后台工程师该干的事），因此前端规范也大都泛泛，无关项目痛痒，成了玩具。

　　雅虎技术规范的优秀之初在于它们解决问题。所以，学习使用规范应当多问一句，“他们为什么这样做？”其实，想清楚这些问题时，脑海中自然形成了一种“遇山开山”的创造性思维。

　　【规范的破与立 2】

　　如果说新技术的尝鲜缺少针对性，但至少满足程序员的某种洁癖和快感，那么“负担”从何而来呢？对于初学者来说，有价值学习资料可能只有这些规范，如果说规范价值不大，那又当从何入手呢？

　　刚才我说的不是依赖于规范，而是对规范的反思，摆脱规范灌输给我们的思维定势。新人们大概是看了Wiki中的很多指标、结论、实践，在做项目之初就附加了不少“八股式”的负担，甚至影响我们对项目关键需求和关键问题的洞察力和判断力，负担过重就无法轻装上阵，Wiki中提到的这些指标和规范是结论性的，是大量的实践之后得出的，也只有经历过大量实践才会真正理解这些结论，比如DomReady时间和http请求数是否有因果关系，http请求数增加是否真的会导致页面性能下降，什么条件下会导致性能下降？我们从那些条文和结论中无法找到答案。

　　举个具体的例子，Kissy刚刚出了DPL，也是一大堆结论，比如他的布局就采用了经典的双飞翼，使用容器浮动来实现，那么，这种做法就是不可撼动的“标准”吗？看看淘宝车险首页，布局容器齐刷刷的inline-block，只要顶层容器去掉宽度，布局容器自身就能根据浏览器宽度调整自然水平/垂直排列，轻易的适应终端宽度了。

　　再比如，淘宝旅行计划项目中的部署方式，也没有完全使用Loader管理依赖，而是将依赖层级做的很少，业务逻辑使用脚本来合并，这样就可以更容易在build环节加入语法检查和代码风格检查。

　　类似这种摆脱原有编程思维，有针对性的用新思路新方法解决问题的做法显然让人感觉更加清爽，编程的乐趣也正体现在打破常规的快感之中，小马曾经说过：“制造规范是为了打破规范”，万不要因为这些规范标准加重负担，导致开始做一个简单页面时也显得缩手缩脚，无法放开身手。大胆的动手实践，才能真正得出属于自己的“结论 “和“标准“，才会真正深刻理解那些“结论”的意义所在。代码写的多了，自然熟能生巧，也容易形成成熟的技术观点。

　　在这个过程中，我们唯一的对手是懒惰，惰于思考，就无法真正发现问题，自然形不成自己的观点。还是那句话，任何规范、方法、结论、实践都是为了解决项目中的问题的，所以，我们所接触到那些看似“八股文”式的规范标准也是为了解决某些问题而提出的，想清楚这些问题，理解方法论背后的“因“，内心自然有“果”。

　　因此，“着眼当下、对症下药”的品质就显得弥足珍贵了，比如，双飞翼布局方法是为了解决一套（html）代码适应多种布局设计，这里的布局相对于固定的产品来说也是固定的，而无针对终端的自适应（适用于移动端的榻榻米布局似乎还没有最佳实践）。这是双飞翼产生的背景，如今终端环境较之5年前已经翻天覆地，问题早已不在“多种布局”上，而在“终端适应“上，这才是我们面临的问题，需要我们给出新的技术方案。

　　所以，勤于思考，轻装上阵，大胆实践，勇于创新，发掘问题所在，实打实的解决（潜在）问题，这才是我们真正需要的能力。放下思维定势枷锁，也会有一种豁然开朗的感觉。可以500%提高开发效率的前端UI框架！

　　第二日：科班秀才

　　【秀才仕途】

　　Web前端工程师是一个特别的岗位，只存在于互联网领域。最近几年随着互联网产业的火爆，对前端工程师的需求量暴增，兵源几近枯竭。各大公司技术掌门一定都有过类似的苦恼：“招一个靠谱的前端工程师、难于上青天”。

　　我想，一部分原因是，当前不少入道的前端工程师大都是转行而来，毕竟，正儿八经的学校里也不会教这玩意，觉得“切页面”有啥好教的，甚至不觉得html/css是一门语言。转行这事自不必详说，大家也各自瞄准当前市场需求，造成的现象是，初级前端工程师堆成山，中高级人才却一将难求，计算机系的科班出身就更加凤毛麟角了。一方面反映了教育部门的后知后觉，另一方面也体现了大部分人急功近利的跟风。当然最重要的原因是，所谓中国“第一代前端工程师”并未做好布道的工作。导致大家对于基础和潜力的态度从之前的忽视演变为如今的蔑视。所谓基础，就是在大学上的那些计算机基础课。所谓潜力，就是戒骄戒躁的务实作风。这些会在后文中多次提到。

　　对于科班出身的莘莘学苗来说，根正苗红本身就是一种优势，事实证明，这些人在前端技术上的成长轨迹有一定的套路，而且大都能如期的突破技能瓶颈。从一个人大学毕业到他最满意的工作状态，中间会经过几个阶段。

　　前2年是学习技能的阶段，这个阶段主要精力放在专业技能的提升上，2年内起码要赶上平均水平，即所谓“中级“，在这个阶段的人通常对软技能不怎么关注，沟通能力达不到平均水平，基本上是来啥活干啥活，干不完就加班的这种，对需求的合理性不甚理解，对项目也没什么把控，尽管在技能上有提高的空间，也不是公司最需要的人，但有不少成长空间。

　　工作2-3年的人在前端技能上趋于稳定，也就是技能上的第一次瓶颈，这种人干活熟练，切页面可能也很快，代码看上去也比较规范，属于熟练工，开始注重沟通技巧和一些职业技能的积累，比如带人带项目，至少有这方面的意识，并有过推动项目、和业务方pk需求的经历，这就达到了中级应当具备的职业技能，但应当注意的是，这时最容易出现偏科的情况，特别是对于那些“专门切页面的“和“专门写脚本的“人，毕竟html/css/js三者不分彼此，三者是一个合格前端工程师都必须要掌握的。如果你觉察到自身有偏废的嫌疑，则要小心了，要清楚的了解自身的差距，并意识到瓶颈的存在，为过渡到“中级“的打下基础。

　　过了这道坎之后，工作3年以上的人大部分技能也趋稳，有些人对前端新技术有钻研，能够熟练应对日常工作，软技能也ok，具备有针对性的“拿来主义“，代码也具有一定的架构性，开始突破“代码民工”的这一层瓶颈，对团队气氛、培训、工作环境有个性化的要求，一般来讲，这种人是典型的具有潜力的“中级”工程师，但很快会遇到职业发展中的第二个技术瓶颈。可以500%提高开发效率的前端UI框架！

　　有少数工作3年或4年以上，在不断寻求新的技能上的突破，最明显的一点体现是，开始关注“底层协议”，即HTTP、第三方应用、系统对接、制造工具、工作流程等，这时思考的重点已经脱离了“切页面”，变为“出方案“，比如要架设一个站点，能够搭建站点框架，预见站点后续（前端）开发中的所有风险，并一一给出解决方案。项目后续开发遇到问题只要翻阅你提供的“手册”即能找到答案。这种人是标准的“高级”Web前端工程师。

　　出方案是一件挺难的事情，它要求一个工程师同时具备经验、技术、气场等诸多硬技能。尤其是对技术底子的要求非常高。

　　【半路出家】

　　那么，转行做前端的人又当如何呢？其实发展轨迹和科班秀才们非常类似，只是时间跨度可能会长一些，你要花更多的精力、做更多的项目、更多的反思和总结才能理解某个知识点的本质（比如HTTP协议）。当然这只是一般情况。

　　此外，这些人还需要摆脱很多思维定势的禁锢。这里我推荐大家阅读阿当的《Web前端开发修炼之道》。当然，如果你有一个靠谱的师兄带你入道，自然幸运万倍。

　　但不管怎样，我始终认为应当秉承兴趣第一的原则，不管你是误打误撞、还是意欲为之，不管你是科班秀才、还是半路出家，兴趣始终应当是第一原则，然后才是你“想做好“。我对自己的要求无法强加于人，所以很多业界大牛在回顾自己成功之路时，提到最多的是：“热爱你的工作、拥抱它给你带来的挑战”。N.C.Zakas曾经这样勉励大家：

　　“我对Web开发人员最大的建议就是：热爱你的工作。热爱跨浏览器开发带来的挑战、热爱互联网技术的种种异端，热爱业内的同行，热爱你的工 具。互联网发展太快了，如果你不热爱它的话，不可能跟上它的步伐。这意味着你必须多阅读，多动手，保证自己的才能与日俱增。下了班也不能闲着，要做一些对自己有用的 事儿。可以参与一些开源软件的开发，读读好书，看看牛人的博客。经常参加一些会议，看看别人都在干什么。要想让自己快速成长，有很多事儿可以去做，而且付出一定会有回报。“

　　第三日，幸福感

　　【先精通十行？！】

　　兴趣第一，听上去很美，但现实却不总是这么酷。练就了一身本领，那也要找到对口的怪物来打一打才过瘾。

　　自然，每个人都想做出好东西，每个工程师也都渴求这样的机遇，用层次分明的设计、漂亮优雅的代码、精妙的细节雕琢，做出美观、安全、实用耐用的产品，不过现实是如此残酷，以至于工程师们一直都缺乏对产品的归属感。作为前端工程师，如何才能在江湖中把握住前进方向、步步走高？毕竟，在职位繁杂的大公司，缺乏人性化的工作流程影响着工程师的工作幸福感。产品从设计之初、到技术方案评审、再到实现，处处充满了妥协，大部分产品都是杂交的产物，人与人相互掣肘，每个人都对产品不满意……，大跃进式的敏捷开发早就被证明百害无一利。但，或许这就是成长的代价。年轻的工程师需要更多的了解需求和设计、产品经理更要懂得软件迭代规律。对于前端工程师来讲更是如此，多学习交互设计和UI，多了解网络协议和软件迭代模型，更能帮助前端工程师和需求方沟通、和后台的衔接、以及控制版本的迭代。

　　说来奇怪，前端工程师不是写html/css/js的吗，搞懂那些边缘知识有什么用？《Web前端开发修炼之道》中也提到，精通一行需要先精通十行。这里我来解释一下原因。

　　作为交互设计师的下游，前端工程师学需要习设计知识是很容易理解的，因为它能帮助你更准确的理解设计师的意图，在原型不完整的时候也能正确的反馈设计缺陷，将问题阻挡在设计的环节，会大大减少UI bug数量，比如说，设计师会给出理想状态下的容器样式，却往往忽略了文字溢出折行、长连续字符、容器宽高是否适应内容尺寸变化而变化，溢出部分是作截字还是隐藏等诸多细节，因为设计师不懂“边界值测试”的道理，而这些问题往往在测试阶段才被发现，所以，如果能在拿到UI设计稿时就提醒设计师补充完整这些场景，自然减少测试回归次数。可以500%提高开发效率的前端UI框架！

　　另外，前端工程师必须要了解网络协议，原因很简单，我们做的产品运行在Web上。很多依赖于Ajax的实现，只有前端工程师才会提出实现方案，产品经理不了解技术瓶颈，后台工程师更不会在意客户端的用户体验，举个简单的例子：通过JS实现一个Ajax，如果Ajax抓取的数据源是一个302跳转，则需要在JS程序中多做一些事情，这就需要前端工程师了解一些HTTP协议。应当说，这是很常见的一个场景。

　　那么，为什么说前端工程师也要关注代码版本控制呢？因为web开发和软件开发本质无异，同样具有迭代周期，需求不是一揽子提完、一口气开发完的，是有步骤的开发，因此，每次上线开发哪些功能、为后续扩展功能留足哪些接口、代码在可扩展和可维护性上应当作哪些考虑……，这些应当是每个工程师关注的事情，所谓迭代就是指这种需求的叠加，这是软件开发的常态，也是web开发的常态，刚开始，前端工程师总会不断抱怨没完没了的需求，代码起初还算干净，但很快就越来越乱，代码的版本管理对于Web前端工程师来说有些困难，这也使得大部分前端工程师很难上档次，从这个角度讲，前端工程师是需要向后台工程师学习的，他们的开发量不比前端少，维护代码的能力要超过前端工程师。另外，对于刚入行的前端工程师，心态要放对，提需求是产品经理的职责所在，整理出有价值的需求是交互设计师的职责所在，将需求作版本控制分步实现是前端工程师的职责所在，前端工程师没必要去抱怨产品经理提一大堆没规律的需求，而更应当去理解需求缘由，将需求提炼成UC（用例），让需求在自己手中可控制。只是多数前端工程师缺乏提炼、整理需求的能力，一味的在接需求，才会搞的手忙脚乱，带着情绪堆代码。

　　所以，只有练就了一身本领，才会更有目标的去寻找对产品的责任感和对团队的归属感，不要误以为能切出漂亮的页面就是能力的提高，纯粹的写代码每个人都差不多的，要成为合格的工程师，眼界要进一步放开，前端工程师能做的，不仅仅是切页面而已，作一个精品项目，一定不乏专业的过程把控，这也是大多数人最易忽略的地方。

　　【励志之本】

　　其实，除了个人需要明确努力的方向，每个人都更渴望身处一个好团队，谁都不希望有猪一样的队友。我们都很羡慕处身这样的团队，可以放心的将精力放在纯粹的技术上，身边每个人都自觉的补充文档注释，代码也层次清晰解偶充分重用率高，精妙的设计实现可以更快的传播，bug得到的改进建议也是务实专业的，技术在这种良性互动中价值倍增。我想这也算是好团队的一种境界了，这有赖于团队成员水平水涨船高。不过，反观Yahoo的成长之路，他们的技术积淀也是靠点滴的积累，其实他们当初的状况不比现在的我们好哪去，10年的进化，才造就了Yahoo技术团队的专业性和Hack精神，我们每个人才刚刚起步而已。为了积攒工作中的幸福感，多付出一些是值得的。

　　但我猜，你现在的处境一定不会太过乐观，产品乱提需求、一句话的PRD、不被重视，被生硬的当作“资源“……反正，情况就是这么个情况，要么你选择抱怨下去，要么想办法去改变。“积极主动“是源自内心的一种坚韧品质，也是励志之本，有些人在现实中被磨平了理想，有些人却在黑暗森林中找到了方向，这就是犬儒主义和英雄气概之间的差别。这自不必详说，因为这让我想起了“大长今”，这简直就是前端工程师的励志典范：“这是一个可怕的环境，足以消磨任何人的斗志和信念，所有来这里的人都变得麻木和无所作为，‘多栽轩‘恶劣的环境没有改变长今，但长今却改变了‘多栽轩‘所有的人“。

　　如果你想做到“资深”，就一定要想清楚这一点，因为你是团队的顶梁柱（业务），也是幸福感的源头（士气）。

　　第四日，架构和伪架构

　　【代码设计的本质】

　　读到这里，你不禁会问，前端领域存在“架构师”吗？这个问题会在后面的“码农的宿命”中展开解释。这里先说下代码架构的一些琐事吧。

　　什么是架构？架构是由“架”和“构”组成，架，即元件，构，即连接件。因此，架构即是将总体分解为单元，然后定义单元之间的连接方式。架构的含义源自禅宗，而禅宗的基本信条则之一就是真理是无法用语言来描述的。这个基本信条有其背景，即语言具有某种抽象性。而人们对这种抽象性的悟道则直接影响对事物的看法，进而决定了对客观世界的分解方法。

　　而在编程语言中，同样存在这种禅宗所隐喻的悖论。在面向对象的教科书中，通常举一些显而易见的例子，比如“水果”是一个类，包含有苹果、桔子、香蕉等实例，“蔬菜”也是一个类，包含白菜、冬瓜、茄子等实例。这两个类之间并无交集，因此很容易理解。但实际项目中情况要复杂的多，比如两个图书类目“文学”和“历史”，那么“明朝那些事”应当是“文学”类的实例还是“历史”类的实例呢？即一旦用语言说出了某一事物，即人为的割裂了世界，于是就会陷入迷途。这在程序设计领域情况更甚，也是造成混乱的主要根源，也就是说，如果你的程序可扩展性不好，一定是程序作者对“单元”的定义不够准确，即单元的概念之间不够“正交”。而这种架构终是徒有其形，根基不稳。

　　因此，变量和类的命名才是真正考验架构功力的关键（命名是否准确清晰、单元之间是否有概念重叠或盲区），而和所谓“组合”、“继承”、“桥接”等模式化的“外表”无本质联系。可以500%提高开发效率的前端UI框架！

　　【伪架构】

　　实际情况是，程序员早早的就想让自己和“架构”扯上关系，并自封xx架构师。在项目中应用各种模式分层、解耦方法，每个项目都可以产出一套看上去很复杂的“架构图”，感觉很牛逼的样子，没错，实践这些方法论总不是坏事，但世界观才是方法论的基础，只有在概念上对产品模块有科学的定义，方法论便自然形成了，《编程珠玑》中一再提及数据结构就是静态的算法，在Web前端领域亦是如此，在页面的建模过程中，定义分解维度要比分解方法更加基础和重要。我想阿当可以在《Web前端开发修炼之道》的第二版里加上这部分内容。

　　真正的高手用记事本就能写出高质量的代码、用cvs就能做到完美的版本控制、用字典式的分解就能做好系统架构，我想，这正是剑宗一派的最高境界吧。

　　第五日：寻找突破

　　【动心忍性】

　　技术流派看上去是如此吸引人，高手就像侠客一般，来去如风潇洒自如。但反观自己怎么看怎么没有侠客那股范儿。尽管上文提到了一些道理，了解这些尽管不是坏事，但缺少实践总感觉是纸上谈兵。更何况，日常的工作又是枯燥无味、繁杂单调。每个人都盼望更高的目标、接触新鲜技术、将新技术运用到日常，在探索尝试之中寻找成就感。这种感觉可以理解，但却缺少更深层次的思考。因为越到最后越会发现一线的工作才是最有挑战的。当然，我说这话的前提是，你能如前文所说具备合格的软技能，需要一些技巧让工作变得工整有序、节奏健康，这样你才能将注意力放在纯粹的代码中，摆脱了外界的烦扰，方能从技术的角度思考突破。这也是从初级到高级的进化过程需要大量的历练的原因。正如玉伯所说，“枯燥是创新的源泉。如果你发现自己没什么新想法，做事缺少激情，很可能是因为你还未曾体验过真正的枯燥的工作”。

　　关于如何寻找突破，我的建议是马上动手做、不要等，相信自己的直觉（这里和上文提到的先思后行是两码事）。比如，Slide幻灯控件理应支持触屏事件以更好的适应移动终端，或许你在用的Slide幻灯版本很旧、或者时间不允许、再或者你害怕对Slide改造而引入bug，不要担心，大不了多花业余时间，只要想，只要感觉合理和必要，就去做。因为这个过程带来的编程体验才是工程师们独有的美妙体味。我现在还时常深夜写代码，没有打扰、思如泉涌、代码也更加工整严谨，不失为一种享受。因此，用眼睛去观察，用心去感触，“所以动心忍性，才会增益其所不能”啊。

　　【得与失】

　　互联网的发展的确太快，Web前端技术也在花样翻新，有人经不起诱惑，开始做新的尝试。前端技术虽然范围广，但各个分支都还比较容易入门，比如服务器端脚本编程、再比如纯粹的WebApp，我认为这两者都是前端技术的范畴，毕竟他们都没有脱离“浏览器”，或者说类似浏览器的环境。NodeJS依赖于V8，WebApp更是软件化的WebPage。只要打好基础，这些方向都是值得深入钻研的，因为，互联网的形态越发多元，新的技术总能找到用武之地，这就要凭借自己的技术嗅觉和产品直觉，寻找技术和业务的契合点。

　　这看上去是一种放弃，放弃了自己赖以生存的铁饭碗（熟练的切页面至少不会失业），实则不然。这种想法是一种误区，新的选择并不会让你放弃什么，就像学会了开车，并不意味着就不会骑车了。其实改变的是思维方式而已，是一种进步，如果你能想通这一点，你也能跟得上互联网发展的脚步了，打开你的思维，让技术变成你的金刚钻，而不是包袱。

　　所以，所谓得失之间的权衡，其实就是“解放思想”。做到了这一点，那么你已经在做“技术驱动”了。

　　【误区】

　　但是，不要高兴的太早，“技术驱动”是需要大量的积累和经验的。在入行初期，很多人过于着迷与此，从而陷入了迷途。比如有人纠结于是否将dt、dd的样式清除从reset.css中拿掉，原因是觉得这两个标签的清除样式会耗费一些渲染性能；或者是否需要将for循环改为while循环以提高js执行速度。尽管这些考虑看上去是合理的，但并不是性能的瓶颈所在，也就是说，你花了很大力气重构的代码带来的页面性能提升，往往还不如将两个css文件合成一个带来的提升明显。就好比用一把米尺量东西，没必要精确到小数点后10位，因为精确到小数点后2位就已经是不准确的了。这种技术误区常常让人捡了芝麻丢了西瓜。

　　话说回来，这里提到的怀疑权威的精神是绝对应当鼓励的，但不应当止于表象，如果怀疑dt的清除样式会对性能带来影响，就应当想办法拿到数据，用事实来证明自己的猜测。数据是不会骗人的。而求证过程本身就是一种能力的锻炼。

　　【技术驱动】

　　说到这里，你大概对“技术驱动”有那么一点点感觉了。身边太多人在抱怨“公司不重视前端”、公司不是技术驱动的、技术没机会推动产品业绩、我的价值得不到体现？

　　什么是技术驱动？简单讲，就是技术对业务有积极推动作用。更多的是工程师发起、工程师影响、工程师负责。刚才提到的用数据说话只是一种“驱动”技巧，那么我需要何种数据，数据从哪里来？我来分享一个实际的场景吧。

　　工程师A被委派一个重要的频道首页，因为是新年版，所以要赶在年前上线。A学了一点点响应式设计，想在这次重构中加上，但谁也没做过响应式设计，需求方根本不懂，设计师也懵懵懂懂，交互设计师太忙，做完交互稿就忙别的去了。A纠结了，按部就班的把项目做完上线发布，尽管不会出什么问题，但总觉少点什么。这时A做了两个决定，1，我要按时完成项目，2，趁机实践我在响应式设计中的想法和思考，若成功，作为附加值赠送给需求方，若失败，权当技术玩具耍一耍罢了。所以A熟练的提前完成了项目，剩下的时间开始考虑如何将首页适应到各个平台中，视觉设计是一大难题，他用吃饭的时间找了设计师收集建议，对窄屏中的内容模块做了看似合理的编排，代码上hack一下，能够正确适配，就发布上线了。这件事情需求方不知道，视觉设计师也不了解，交互设计师更没工夫操心。A感觉挺爽，开始给工程师弟兄们到处炫耀这个好玩的功能，B看了问，手机端访问量如何，A觉得这个问题有道理，就去部署埋点，一周后拿到数据出奇的意外，首先，移动段的访问量稳步增加，趋势健康，再者，移动端首屏焦点广告位的点击率较PC端高了近一倍，这个数据让A喜出望外，兴奋的拿着报表找到交互设计师C和市场研究的同事D，D看了报表之后立即启动一个项目，专门调研公司全站响应式设计页面在PC端和移动端的点击率、PV、UV趋势方面的影响……后来发生的事情就都水到渠成了，设计师C开始注意设计页面交互时（至少是有条件的考虑）对移动端的适配，D的调研报告也放到了UED老大的案头……接下来的事情，你懂得。A被指派要出一套响应式最佳实践和规范，最终，A走在了技术的前沿，也因此拿到了好绩效。

　　这件事情就是一个典型的技术驱动的例子。谁不让你玩技术了，谁不重视你了，谁把你当工具了，谁觉得你的代码没价值？这世界只有自己把自己看扁，谁想跟你这个蝇头小卒过不去？用实力说话，用数据说话，用独到的见解说话，想不做技术驱动都难。