第四日，架构和伪架构
　　【代码设计的本质】
　　读到这里，你不禁会问，前端领域存在“架构师”吗？这个问题会在后面的“码农的宿命”中展开解释。这里先说下代码架构的一些琐事吧。
　　什么是架构？架构是由“架”和“构”组成，架，即元件，构，即连接件。因此，架构即是将总体分解为单元，然后定义单元之间的连接方式。架构的含义源自禅宗，而禅宗的基本信条则之一是真理是无法用语言来描述的。这个基本信条有其背景，即语言具有某种抽象性。而人们对这种抽象性的悟道则直接影响对事物的看法，进而决定了对客观世界的分解方法。
　　而在编程语言中，同样存在这种禅宗所隐喻的悖论。在面向对象的教科书中，通常举一些显而易见的例子，比如“水果”是一个类，包含有苹果、桔子、香蕉等实例，“蔬菜”也是一个类，包含白菜、冬瓜、茄子等实例。这两个类之间并无交集，因此很容易理解。但实际项目中情况要复杂的多，比如两个图书类目“文学”和“历史”，那么“明朝那些事”应当是“文学”类的实例还是“历史”类的实例呢？即一旦用语言说出了某一事物，即人为的割裂了世界，于是会陷入迷途。这在程序设计领域情况更甚，也是造成混乱的主要根源，也是说，如果你的程序可扩展性不好，一定是程序作者对“单元”的定义不够准确，即单元的概念之间不够“正交”。而这种架构终是徒有其形，根基不稳。
　　因此，变量和类的命名才是真正考验架构功力的关键（命名是否准确清晰、单元之间是否有概念重叠或盲区），而和所谓“组合”、“继承”、“桥接”等模式化的“外表”无本质联系。
　　【伪架构】
　　实际情况是，程序员早早的想让自己和“架构”扯上关系，并自封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走在了技术的前沿，也因此拿到了好绩效。
　　这件事情是一个典型的技术驱动的例子。谁不让你玩技术了，谁不重视你了，谁把你当工具了，谁觉得你的代码没价值？这世界只有自己把自己看扁，谁想跟你这个蝇头小卒过不去？用实力说话，用数据说话，用独到的见解说话，想不做技术驱动都难。
　　第六日：码农的宿命
　　【青春饭】
　　“码农”是IT从业者一个自嘲的称号，也有从事没有发展前景的软件开发职位，靠写代码为生的意思。但我认为码农是一个爱称，编码的农民，和农民一样有着执着纯真朴实豪爽的共性，仅仅分工不同而已。好比农业社会对粮食的依赖，工业化进程对计算机应用也有着很强的依赖，大量的需求催生出这样一群人。他们有智慧的大脑，对于编程，设计，开发都有着熟练的技巧，但多数人看来，码农的特点是：
　　1，收入低
　　2，工作单调
　　3，工作时间长
　　实际上这个描述非常片面，或者说是外行看热闹。第一，全行业比较来看，软件开发领域收入为中等偏上；第二，程序员一般都是有癖好的，沉浸在自己的癖好中是不会感觉单调的；第三，程序员有一定的时间自由度（如果你是一名合格的程序员的话），至少不会像流水生产线工人一样。其实，通过几十年的发展，我们对程序员的定义更加科学，比如很多IT企业都开始建立详细的JM（Job Module），即职级模型，程序员沿着专业方向可以走到很高，甚至可以说，程序员是可以被当成一生的事业的。
　　然而，有一个非常普遍的观点是，程序员和做模特一样是吃青春饭的，到了三十岁要考虑转行或者转管理。尽管这种观点颇具欺骗性，但至少它对一种人是适用的，即入错了行的人。如果你骨子里不想写程序，算年纪轻轻为了生计写几年代码，之后肯定会另有他途。心非所属则不必勉强，但问题是，即便如此，你知道你的心之所属吗？
　　我们知道，一个成熟的产业一定需要各色岗位来支撑，若要成熟，则需要时间的沉淀，比如实体经济制造业，创意、生产线、高级技工、技术管理四个方面都产出大量的高级人才。因为历史悠久，我们能看得到。而软件产业则不然，九成以上是刚出道的新手，并没有太多“高级”和“”的具体样板可供参照，在前端开发领域中情况更甚，绝大部分人根本搞不清楚什么样才是“”前端工程师，相比传统软件行业近四十年的进化，我不相信仅有几年光景的前端技术岗位能产出多少货真价实的“”。但互联网崛起速度太快，还没有等技术基础打牢，互联网形态又花样翻新了，这种变化是一种常态，而岗位的设定也在这种变化之中自然的优胜劣汰，比如两年前可能还难以想象数据部门会需要前端工程师，他们甚至不直接和浏览器打交道。前端工程师需要适应这种变化带来的观念冲击，不要以为自己只能做切页面、或者只会给页面搞重构、只会搞兼容性，要把自己放在整个软件行业来看。
　　所以，由于历史“不悠久”导致的岗位模糊本身不是什么大问题，岗位的演化本身包含在互联网的发展轨迹之中。所以，当今的互联网IT状况，好比移动终端的大哥大时代、云计算的肉鸡时代、或者桌面操作系统的DOS时代。因此，前端工程师当前要务是要想清楚看清楚，在互联网中我能做什么，而不是作为前端工程师我能做什么，所以，从这个角度讲，技术是一个工具，放大来看，技术也只是你职业生涯中很小的组成部分，而你的从业积累、和知识面的广度深度才是你随着时间的推移慢慢步入“”的原因所在，而不是写了个什么框架变“”了。如果有互联网形态固定了，它的岗位可能真正定型了，才会有真正清晰的职能边界，像蓝色巨人IBM中的各色岗位一样，边界清晰，权责分明，普通程序员只能实现接口而无机会设计接口、低层级的工程师也无机会跃进式的接触项目架构、技术经理人也不能轻易对产品有决策性影响，到这时，人的能力才真正的被限制在方圆之内，容不得越界，这种环境下人的成长非常缓慢。根本不会有像互联网乱局之中所提倡的创新、革命、成长和思想解放。简单讲，一旦产业定型，不太需要很多“创造”了，更多的是“维护”。所以，我个人宁愿互联网IT“黑暗”的中世纪越久越好，至少对于年轻气盛程序员来说，黑暗的丛林环境才是真正的自然进化理想的土壤，这时我想起了狄更斯在“双城记”中的开篇。
　　“这是好的时代，这是坏的时代；这是智慧的时代，这是愚蠢的时代；这是信仰的时期，这是怀疑的时期；这是光明的季节，这是黑暗的季节；这是希望之春，这是失望之冬；人们面前有着各样事物，人们面前一无所有；人们正在直登天堂，人们正在直下地狱”。
　　【半路出家的危与机】
　　然而，不管怎样，信心的树立不是一蹴而的，对于转行做前端的人来说更是如此。俗话说，隔行入隔山。每个行业自有其道，自然不是想做做。前端技术领域半路出家者非常多，我们来分析一下转行的心理。第一，看到前端技术入门简单、互联网对前端技术的需求缺口巨大；第二，前端技术所见即所得、感觉学习起来很快；第三，我身边的某某转行作前端看上去不错、我似乎也可以；第四，我不喜欢我现在做的工作、想换行业、正好前端技术上手较快，选他吧；第五，我真的喜欢做Web前端，为它付出再多都是值得的。
　　转行者的心态比较容易走两个极端，一是只看到新行业的好，二是只觉得原工作很糟糕。但不管是什么行业的转行，对自己的职业规划的思考都应当先行一步。即务必首先清晰的回答这些问题：
　　1，我能做什么？
　　2，我不能做什么？
　　3，我的优势是什么？
　　4，我的劣势是什么？
　　5，做新行业对我有何好处？
　　6，换行会让我付出何种代价？
　　7，如何定义转行成功？
　　因为面试的时候一定会被这些问题所挑战。如果支支吾吾说不清楚，要么是对自己未来不负责任，要么骨子里是草根一族，习惯做什么都蜻蜓点水浅尝辄止，也难让人信服你的转行是一个权衡再三看起来合理的选择。我无法帮每个人回答这些问题，但至少有两点是确定的，第一，Web前端技术是一个朝阳行业，值得义无反顾的坚持下去；第二，你将经历从未有过的枯燥、苛刻的历练，所谓痛苦的“行弗乱其所为“阶段。不过话说回来，经历过高考的人，还怕个屁啊。
　　有心之人自有城府、懂得放弃，看得清大势中的危机、识得懂繁华里的机遇。尤其当立足于Web前端技术时，这种感觉愈发强烈。因为国内外前端技术领域从2000年至今一直非常活跃，前端技术前进的步伐也很快，对于一些人来说，不管你是在大公司供职还是创业，不管你是在接外包项目还是自己写开源项目，从转行到跟得上新技术的脚步是有一些方法和“捷径”的。
　　第一，梳理知识架构
　　我们知道知识积累有两种思路，第一种是先构建知识面、建立技术体系的大局观，即构建树干，然后分别深入每一个知识点，即构建枝叶，终形成大树。第二种是先收集知识点，越多越好，后用一根线索将这些知识点串接起来，同样形成大树。第一种方法比较适合科班秀才，第二种方法则更适合转行作前端的人，即实践先行，理论升华在后。比如对“IE6怪异模式“这条线索来说，要首先将遇到的IE6下的样式bug收集起来，每个bug都力争写一个简单的demo复现之，等到你收集到第100个bug的时候，再笨的人都能看出一些规律，这时会自然的理解IE的hasLayout、BFC和各种bug的原因、你成为了IE6的hack专家了，当你成为100个知识线索的专家的时候，你已经可以称得上“”的水平了。我们知道，10个人中有9个是坚持不下来的，他们会以项目忙等各种理由万般推托，将自己硬生生的限制在草根一族，坐等被淘汰。所以，对于立志作前端的人来说，这种点滴积累和梳理知识非常重要。
　　第二，分解目标
　　将手头的工作分解为几部分来看待，1，基本技能，2，项目经验，3，沟通能力，4，主动性和影响力。想清楚做一件事情你想在哪方面得到历练，比如，我之前在做第一次淘宝彩票常规性重构的时候（正好是一次视觉和交互上的全新设计），我清楚的明白这次重构的目的是锻炼自己在架构准富应用时的模块解偶能力，寻找在其他项目中架构的共通之处，所以我宁愿加班或花更多精力做这个事情，当然更没打算向业务方多解释什么，这件事情对我来说纯粹是技能的锻炼。而经过这一次重构之后，我意外的发现对业务的理解更透彻深入、更清晰的把握用户体验上的瓶颈所在。如果一开始把这次常规改版当成一个普通的项目按部班的做，我只能说，你也能按时完成项目，按时发布，但真真浪费了一次宝贵的锻炼机会，项目总结时也难有“动心忍性”的体会。
　　所以，每个项目的每个事情都应当认真对待，甚至要超出认真的对待，想清楚做好每件事对于自己哪方面有所提升？哪怕是一个bug的解决，即便不是自己的问题也不要草草踢出去了事，而是分析出问题原因，给出方案，有目的involve各方知晓……，正规的对待每个不起眼的小事，时间久了历练了心智，这时如果突然遇到一个p0级的严重线上bug（比如淘宝首页白屏，够严重的了吧）也不会立即乱了方寸，这也是我上文提到的心有城府自然淡定万倍，而这种淡定的气场对身边浮躁的人来说也是一种震慑和疗伤，影响力自然而然形成了。
　　第三，作分享
　　做分享这事儿真的是一本万利。有心的人一定要逼着自己做分享，而且要做好。首先，自己了解的知识不叫掌握，只有理解并表达出来能让别人理解才叫掌握，比如如果你解释不清楚hasLayout，多半说明自己没理解，如果你搞不懂双飞翼的使用场景，可能真的不知道布局的核心要素。再者，作分享锻炼知识点的提炼能力和表达能力，我们作为工程师不知道多少次和强硬的需求方pk，被击败的一塌糊涂。也反映出工程师很难提炼出通俗易懂的语言将技术要点表述清楚。而做ppt和分享正是锻炼这种能力，将自己的观点提炼出要点和线索，分享次数多了，自然熟能生巧。档次也再慢慢提高。另一方面，逼迫自己站在公众场合里大声讲话，本来是提高自信的一种锻炼。
　　这时，你或许会问，我讲的东西大家都明白，我讲的是不是多余，我第一次讲讲不好怎么办，大家会不会像看玩猴似的看我“这SB，讲这么烂还上来讲”？要是讲不好我以后再讲没人听怎么办，我今后怎么做人啊？
　　老实说，这是一道坎，任何人都要跨过去的，谁都一样，你敢鼓起勇气在大庭广众之下向爱人表白，没勇气对自己的职业宿命说不？其实勇敢的跨越这一步，你会意外的收获他人的掌声和赞许，这些掌声和赞许不是送给你所分享的内容，而是送给你的认真和勇气。这个心结过不去，那老老实实呆在自己的象牙塔里遗老终生，当一辈子工程师里的钻石王老五吧。
　　【匠人多福】
　　如果你能耐心读到这里，心里一定有一个疑问，上面说的都是技术上能力上怎样怎样，那我所做项目不给力又当如何？如果项目不挣钱、黄了、裁了，我的努力不白费了吗？我又有什么绩效和价值呢？
　　没错，有这种想法的人不在少数。特别是刚出道的校招同学往往更加心高气傲，以为自己有改变世界的本事，一定要参与一个牛逼的团队做一款光鲜靓丽受人追捧能给自己脸上贴金的项目。如果你有这种想法，趁早打消掉这个念头，当然，我们这里先不讨论创业的情形。
　　第一，如果你刚毕业加入一个牛逼团队，说难听点，你是团队中其他人眼中的“猪一样的队友”，不创造价值且拖项目后腿（显然大家都要照顾你的成长啊），按照271理论，你没有理由不是这个1。至少相当长一段时间内是这样。
　　第二，你在所谓牛逼团队中的创造性受限，因为创新多来自于团队中的““和大牛们，你参与讨论但观点通常不会被采纳，他们只会给你这个菜鸟分活干，想想看，你如何能花两到三年超越身边的大牛们？甚至连拉近与他们的距离都难。
　　第三，如果身在牛逼团队，自然心理对周围的牛人们有所期待，希望他们能灌输给你一些牛逼的知识和牛逼的理念。这种思想上的惰性在职场生涯之初是非常危险的。要知道技术和知识本身是很简单和淳朴的，只不过披上了一个光鲜项目的外衣而让人感觉与众不同。
　　第四，由简入奢易，由奢入简难，做过一个看似光彩的项目，心理再难放平稳，去踏实的做一个看上去不那么酷的产品。这种浮躁心态会严重影响今后的职业发展和成长。
　　第五，光鲜靓丽的项目被各种老大关注，是难容忍犯错误的，傻瓜都知道犯错误在成长之初的重要性。
　　我所看到的情形看，一开始加入看似很牛的项目组，三年后得到的成长，比那些开始加入一个不被重视的项目的同学要小很多，而后者在能力上的弹性却更大。所以，道理很简单，你是要把一个很酷的项目做的和之前差不多酷，还是把一个不酷的项目做的很酷？项目是不是因为你的加入而变得与众不同了？
　　从这个角度讲，不管是转行的新人还是刚出道的秀才，好将自己当作“匠人”来对待，你的工作是“打磨”你的项目，并在这个过程中收获经验和成长。付出的是勤奋，锻炼的是手艺，磨练的是心智。因此，你的价值来自于你“活儿“的质量，“活儿”的质量来自于你接手的项目之前和之后的差别。做好活儿是匠人应有的职业心态。想通这一点，内心自然少一些纠结，才会对自己对项目的贡献度有客观的认识，不会感觉被项目所绑架。
　　做一名多福的匠人，拥有了金刚钻、不怕揽不到瓷器活儿。但对于人的成长来说，如果说“项目”重要但不关键，那么什么才是关键呢？这个话题还会在接下来的“伯乐与千里马”这篇中给出答案。
　　【若干年后】
　　现在，让我们回过头回答一下“青春饭”的问题。在“青春饭”小节中提到，“程序员到三十岁之后需要转行或者转管理吗？”
　　上文提到，工业化生产的四个领域，1，创意，2，生产线，3，高级技工，4，技术管理。Web前端技术也是如此，可以在这四个领域找到各自的归宿。
　　第一，“创意“
　　即和产品需求越走越近，拥有良好的产品感，对产品需求、设计交互把握准确，能够用适当的技术方案推动产品用户体验，属于“架构师”的范畴，因为职能更加靠前，偏“出主意”型的。这种人更贴近用户，需要活跃的思维、广阔眼界、厚实的项目经验。更多的影响产品体验方面的决策。
　　第二，“生产线“
　　即前端基础设施建设，优化前端开发流程，开发工具，包括开发环境、打包上线自动化、和各种监控平台和数据收集等，属于“技术支持”的范畴，相比于很多企业粗犷难用的平台工具，前端技术方面的基础设施建设基础还需更加夯实，因为这是高效生产的基本保证。
　　第三，“高级技工“
　　即高级前端开发工程师，专职做项目，将产品做精做透，用代码将产品用户体验推向，偏“实战”型的，是项目的中坚力量，直接产出成果，影响产品效益。属于项目里的“”。
　　第四，“技术管理“
　　即做技术经理，这才是多数人所理解的“管理”，其实是带团队、靠团队拿成果。这类人具有敏感的技术情结，在技术风潮中把握方向，能够指导培训新人，为各个业务输出前端人才，偏“教练”型的，促进新技术对业务的影响。并有意识的开辟新的技术领域。
　　可见，转管理可不是想当然，也不是所谓做项目变了能转管理，转了也不一定能做好。根据“彼得原理”，即人总是倾向于晋升到他所不能胜任的岗位，这时又陷入“帕金森”定律所隐喻的恶性循环之中，直到你带的团队整个垮掉。
　　所以，转管理应当是一件非常慎重的事情，不是所谓程序员混不下去转管理这么简单。但不管怎样，有一件事情是需要尤其要想清楚，即，转了管理，技术丢了吗？我们在第七日“伯乐与千里马”中再深入聊聊这个事儿。
　　第七日，伯乐与千里马
　　【师兄们的抉择 1】
　　千里马常有，而伯乐不常有。——韩愈，“马说”。
　　一个人这辈子能遇到一个好师兄是一种缘分，可遇不可求。很多人工作中的幸福感似乎也源自这种被认同，被师兄的了解和认同，有人能直言不讳的指出你的不足，帮你发现机会，并将适合你做的事情分配给你，这是莫大的幸运，但如此幸运的人十之一二，大多数人因为缺少伯乐的提点，渐渐辱于“奴隶人之手“，潜力渐失，毁于中庸。
　　在前端技术领域，这种情况很普遍也很特殊，当然有很多客观原因。即前端技术进入公众视野时间不长，有实力的伯乐更加是凤毛麟角。更何况，Web前端技术还有着一些江湖气，知识点过于琐碎，技术价值观的博弈也难分伯仲，即全局的系统的知识结构并未成体系，这些因素也客观上影响了“正统“前端技术的沉淀，奇技淫巧被滥用，前端技术知识的传承也过于泛泛，新人很难看清时局把握主次，加之业务上的压力，未免过早导致技术动作变形。而这些问题也无法全赖自己全盘消化，若有人指点迷津，情况要好上万倍。因此，前端技术领域，为自己觅得一个靠谱的师兄，重要性要盖过项目、团队、公司、甚至薪水。
　　这也是上文所说的“项目不重要，师兄才重要“的原因。说到这里有一个问题，每个人都问下自己，你是想当师弟呢还是想当师兄呢？当师兄有什么好处呢？
　　没错，很多师兄都是被师兄，甚至没有做好当师兄的准备，更进一步说，不少经理人也都是“被经理人“，没有做好准备被推到了管理岗位。带人是耗精力的，师兄要做很多思想斗争才舍得把这些宝贵的精力放在那些菜鸟身上，这不是一个技术问题，而是一个道德问题。要记住，没有谁应该无缘无故把自己所掌握技能给你倾囊相授，如此皆命也。读到这里，作为菜鸟，作为学徒，作为新人，作为师弟，你做到对这份命运的足够尊重了吗？
　　尊师重教的传统美德并没有在技术领域得以很好的延续。也正因为此，人才梯队难建立起来，但对于师兄来说，却是有更多机遇的。
　　【师兄们的抉择 2】
　　作为师兄，不管是主动还是被动，肯定会想当师兄对我有什么提升？对于初次做师兄的人来说，大的提升在于两方面，1，任务分解，2，问题分析。
　　第一，任务分解，作为师兄要给师弟派分任务，涉及到任务分解，分解这事儿往低了说，是派活，往高了说，其实是做“架构”，比如一个页面，按照什么思路进行模块划分，模块划分是否适合单人开发，如何控制共用样式和共用脚本，我需要为他提供什么接口，如何控制他的代码并入整个页面时不会影响整体页面代码的熵值，这些都是实打实的“架构“应该包含的问题，而从小页面开始做这种锻炼，做的多了，“架构感”自然形成了。
　　第二，问题分析，在之前自己写代码都是单打独斗，什么都是用代码解决问题，但一旦涉及协作，要强迫自己分析问题，或者说给徒弟分析问题，告诉他应当用什么方法来解决问题，当说到“方法”时，脑子里定形成了一个方案，按照这个方案路子走一定能解决问题。分析问题比写代码要更抽象、更高效，因为在脑子里构建方案要比写代码要快，思考也会更加缜密，当锻炼的多了，思考越来越快，代码的草稿也很快在脑海中形成了，这也是我们说为什么很多人不写代码但编码思路和水平都很高的原因。
　　这些工作方法对了，积累多了，是提高。对于技术经理人来说，也是同样的道理。所以，像在第五日的“得与失”部分提到的那样，转身师兄、变身管理并不意味着“失“掉技术饭碗，而是一种进步。
　　【做自己的伯乐】
　　那么，在前端技术领域里什么样的人才算千里马，其实人人都是千里马，人人都可以发掘自己的潜力，如果上面的文字你能读懂，能认可，这种自我发掘已经开始了，没有一个好伯乐又何妨呢？做一个勤快的小码农，少一些势利的纷争，很快会发现，自己才是好的伯乐。
　　但这并不是说，他人对自己的观点不重要，有时甚至要综合各种声音，所以，多找身边的大牛们聊聊天，多找你的师兄和主管，不管他们给你的建议是多么形而上，总有一些声音对你是有益的，多收集，有好处。
　　第八日，做地球上牛的UED
　　【谁推动了历史前进，英雄？还是人民？】
　　“做地球上牛的UED！”，这是淘宝UED创立之初的口号，现在被渐渐淡忘了，因为微博上的一些讨论，又想起了这份曾经美好的初衷。玉伯也感叹道：“这愿景曾吸引了多少好汉前往投奔呀。只可惜短短几年间，这愿景好像越来越远了”。问题是，要做好一个团队，靠的是个人、还是整体？愿景是越来越远了吗？
　　是谁推动了历史的前进，是英雄？还是人民？微观来看，是英雄，宏观来看，是人民。再放大了看，是互联网大潮之崛起推动了前端技术的进步，时势需要UED、需要用户体验。
　　所以，UED团队的创立发展受这些积极的外因影响，赶上了好时候，成员也跟着沾光。然而，我并不关心这个口号，我只关心体制内的关键人物，那些带动整个团队水涨船高的人们。往往我们发现，某些人的高度代表了整个团队的高度，个体的影响力代表了整个团队的影响力，某个人的水平代表了整个团队的水平。支付宝、淘宝、腾讯、百度、盛大，都是如此。而我们作为普通的个体，正是要励志成为这种人，成为真真用技术推动用户体验前进的尖刀人物。
　　这时我想起了很多人在知乎上的问题，关于跳槽、关于转行、关于创业、关于各种UED团队。我想，读得懂我上面的文字，你心理也许会有自己的答案。
　　【归宿】
　　后，还有一个不得不说的问题，即归属问题，前端开发应当归属于UED还是技术部门？应当说，当前Web前端技术的价值体现在“用户体验“上。是用户体验这块阵地后一道坎。也是说，前端工程师应当重点考虑我所作的页面的感官体验。这是需要一些灵感和感性的，应当看到帅气优雅的界面会心有所动、或者实现一款精巧的小组件时萌生一阵快意。这种所见即所得的美妙编程体验正是其他后端工程师无法体验到的。因此，这种精确到像素级的精工雕琢虽然不直接决定产品生死，但却是提升产品品味和时尚感的要素。物质越来越丰富的，大众的更高诉求不是品味和时尚吗？
　　如果将前端归到技术部门，一方面和“设计“离的更远，代码写的规规矩矩但渐缺少了灵性，另一方面作为工程师又缺少计算机专业课的功底，才真正丧失了优势所在，如果有，前端工程师的平均水平足够高，清一色的计算机科班出身，似乎更合适归入到技术部门。所以，Web前端工程师是“工程师“，需要科学严谨的编程能力，但身处UED所应当具备的美感和灵性是万不可被剥夺去的。
　　还有一点，Web前端工程师作为UED之中具实践精神和逻辑思维的工种，是能够将技术对设计的影响发挥到大，可以催生出大量的创造和革新的，这一点也是传统后端工程师所不具备的。
　　第九日，前端技术体系
　　现在越来越感觉到前端技术需要成体系的积累，一方面可以规范我们的前端技术培训，另一方面，作为知识线索为新人做指引，省的走弯路，避免陷入奇技淫巧的深坑之中不能自拔。
　　之前我整理了一下“前端技术知识结构”，罗列的比较散，但也基本表述清楚了我的观点。今年上半年也在整个研发中心组织了一次前端技术培训，对于前端技术的演化规律也有过整理，都放在了这个ppt中，希望对大家有所帮助。