互联网的发展的确太快，Web前端技术也在花样翻新

     互联网的发展的确太快，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走在了技术的前沿，也因此拿到了好绩效。


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