Web前端开发十日谈：寻找适合自己的道路

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

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

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

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

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

　　【励志之本】

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

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

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

　　第四日，架构和伪架构

　　【代码设计的本质】

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

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

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

　　因此，变量和类的命名才是真正考验架构功力的关键(命名是否准确清晰、单元之间是否有概念重叠或盲区)，而和所谓“组合”、“继承”、“桥接”等模式化的“外表”无本质联系。

　　【伪架构】

　　实际情况是，程序员早早的就想让自己和“架构”扯上关系，并自封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走在了技术的前沿，也因此拿到了好绩效。

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