我自己绝对是一个顽固的意识流的人。以往的各种内部或外部的分享，谈的最多的也是前端开发的各种concept。 2009.12 – D2上我说“库”时代过去了，以后不会再有类似jQuery、Dojo、YUI这种大而全的库了。堆积“库”的开发方式将会演变为按需加载更细粒度的模块（http://www.slideshare.net/kejun/yui2yui3）。框架提供的插件机制会把单一功能的库整合到一起。同年1月Mozilla发起一个叫ServerJS的项目，8月改名为CommonJS。CommonJS定义了一整套Javascript模块(module)、包(package)、promises、io等规范，目的用于服务器端、桌面应用的Javascript开发。它只是一套规范，没有具体实现。AMD(Asynchronous Module Definition)最初是CommonJS模块定义方面的一个草案，后来出现意见分歧，另立一个amdjs组单独发展，如今已被广泛接受，CommonJS也就接纳了它。 Javascript模块的理念发展到今天ES Harmony要把它正式加入到标准中，要向先驱Dojo致敬。 YUI3的设计思想也很超前，只不过走的是另一条路。透过这种演变的脉络，要看清它最初的需求是什么？细粒度模块的按需加载和依赖关系管理就这么朴素。YUI3的风格是把模块配置写在外面，AMD是写在模块里面。 辩论风格的好坏意义不大，就像讨论加不加分号一样无趣。关键是否有效解决最初的问题，围绕这个根源，可以有不同的思路。比如我们目前的做法是在build阶段设计一些伪语法导入细粒度的模块。前端用一个loader加载粗粒度的模块。我今年4月曾在杭州的D2沙龙上分享过(http://www.slideshare.net/kejun/ss-12148658)。为解决问题完全可以跨越前后端的界线，而且这样往往效果会更好。 开发如下棋，局局新，要观局、布局。如今国外一个新技术冒出来，国人就追捧。欠缺观局这一环，真正搞清实际开发遇到的问题了吗？独立思考过这些问题吗？还是在开发中试玩各种新技术、照搬别人的经验，还是觉得只有新技术才够fashion…… 2009.12 webrebuild北京的一次活动，我分享过“分层语义化模板实践”。也是很“意识流”。同年3月，我看到Y!的女前端工程师Nicole Sullivan在YDN分享的“Object Oriented CSS: for high performance websites and web applications”。可能同受雅虎前端开发意识流的影响，想法非常相似。2年后，Jonathan Snook提出SMACSS（ Scalable and Modular Architecture for CSS ）的CSS开发思想，并出了一本书（http://smacss.com/book/）。 在前端技术里HTML不像Javascript和CSS那么精彩，其作用最被忽视，但它又是最基础的载体。HTML的难点在结构的设计上，需要稳定、灵活、友好、易理解。其实HTML/CSS完全受意识流控制。如何架构好，源于经验而非知识。现在越来越少人在这方面做认真的追求了。 2010年7月的webrebuild年会上，我分享了前端基础架构（貌似这个词是我攒出来的，我还特地搜过）的想法，也是纯意识流的一次分享。之前前端开发的规范、工具都是毫无关联的个体，开发中各种工具的应用也是毫无目的性的，而且前端开发是脱离整个体系的（像外包）。实际上开发规范是让团队保持统一的代码风格和明示各种性能、安全、易用性原则，但文字本身没有约束力，需要工具保证。因此工具的职能，一方面检验规范，另一方面实现自动化。在这个线索下工具体系就形成了，而且目的性很明确，接下来把它们无缝的挂在开发环境下，成为开发流程的一部分。于是规范、工具、系统就形成了完整的前端基础架构的模型。前端team在这个平台上可以跑的更快。 有人觉得这种分享是浅入浅出，他显然没领会我的意识流里的线索。 11年我有两个针对前端基础知识的分享“前端开发理论热点面对面：从怎么看，到怎么做”和“永不止步的‘重构’“。内容都是前端基础知识。很多人看了很多前端开发方面的书，掌握了很多技术点，但在面临具体问题时仍然不能融会贯通。我们的生活充满大量碎片信息，很多人认为这样可以快速掌握很多知识。伟大的摇滚乐手兼作家Frank Zappa在一首歌里写到：“Information is not knowledge，Knowledge is not wisdom，Wisdom is not truth，Truth is not beauty，Beauty is not love…”。 意识流和技术流就像武侠里的气宗和剑宗。我不过多评价，根据个人特点和兴趣所向。但是在公司项目开发上注重意识流显然更有益处。现在这年头太多浮躁、盲从、缺少独立思考、务实求索之精神。我希望在以后国内技术会议上，能看到高质量的“意识流”分享。也希望更多人不要觉得这东西“水”而排斥它。

2011最后一个changeset调了一些无聊的样式，收官不够华丽。 总结一下自己一年做过的事： FM神秘实验项目 – 很好玩，因为是技术驱动的，我们尝试了node.js。当然少不了各种html5，css3技术混搭。背后还有牛逼的算法。node.js今年很火，yahoo!新一代应用开发平台就是用node.js。它的优势是处理高并发的微请求，这个项目里复杂的运算和数据存储都调service。到底效果怎么样上线后再看吧。 FM WebApp – 我决对是WebApp的拥趸者。但Android 2.2/2.3内置的Webkit就是渣，跟ie6一样招人恨。还好手机的换代更快，我觉得从iOS 5和Android 4开始WebApp的时代要来了。明年打算换个phone7，我喜欢反苹果美学的东西。 首页改版 － 2011年突然流行起“砖块布局”（YY的叫法）像花瓣之类的网站。但新的豆瓣猜布局将是正经的magazine-style布局，是溶合了前后端技术加设计的高级货。 今年还做了团购(已下线)、二手和部落 – 这些项目技术上平淡无奇，贵在开发方式上。比如做部落的过程高度同步，PRD出来后就着手开发，几天整个流程就跑通了，后面等设计出来后再改样式。这种完美时刻，就像比赛中偶尔出现的美妙配合一样。这里面也积累了一些代码组织上的经验。代码组织的三层：业务逻辑代码、通用功能代码，基本架构（类MVC式分层，model是ajax数据交互、controller注册事件、view是javascript template。注意不是single page app那种MVC）。 推荐改版事件 － 细节跳过（…惹了不小的麻烦）。这件事的经验是不要试图实现一个复杂和看似完美的方案，里面可能隐患重重。有时朴实无华是最合适的。像这种通用程度极高的组件，对复用、性能、响应速度都有很高的要求，用户使用上也极敏感。达芬奇说过”简单是极端的复杂“。 上半年主要做了新版FM。它是最适合实践响应性开发的项目，做的不好。明年接着来。国内的设计师对响应性设计无感。这篇文章反映了国外设计的主流思想，基本都在谈响应性设计：A Year in Web Design: How the Experts Saw 2011 在这些产品开发实践中愈加感触：过细过明确的分工会限制单位创造力的发挥，协调成本也高，从而拖缓产品发展，更甭提创新了。各个角色的人（PM、Designer、Engineer）应当通过扩展技能来弥补之间的代沟。也就是Designer应该有产品意识和工程开发意识、Engineer也应该有基本美感，同时，前后端工程师之间应当技术互补。前端问题并不一定用前端技术解决。典型就是静态文件管理，它对前端开发的帮助很大。没它前端代码重构和拆分基本寸步难行。但目前还是简陋。前端开发需要有一套完整的工具体系，闲来整出一张图，后面会谋求更多人支持。总之这是一件任重道远的事，我也有心理准备。 开发要追求高度的模块化，但是在普遍情况下，模块的依赖关系要简单、偏平。也许在很独立的应用或框架内部模块的依赖关系可能会复杂，但纯属个案。因此，前端文件按需加载的粒度不应太小，而在开发环境中维护的应该是粒度更小的模块。因此，后端的预处理和前端的异步按需加载混用是最合理的方案。我对Do也有了新想法，打算2012年重写一下。 今年参加的三个会和所做的分享： 淘宝的技术嘉年华 (slides) webrebuild年会 (slides) tencent北京CDC火山囗 (slides) 承办了一次web标准化交流会。这是目前北京坚持下来时间最长的民间前端技术沙龙。 今年还在知乎上比较认真的回答问题：zhihu.com/people/kejun 8月一个人跑到HK看Red Hot Chili Peppers的现场。所有好的东西都充满某种力量，甚至一行代码也是如此。今年还幸运的看了eels、black rebel motor club、envy的现场。稍稍有点后悔没看Bob Dylan，但我更爱Leonard Cohen，这个老家伙据说2012年出新专辑。顶马的十年和声音碎片的十年专场印象也颇深，对于上了岁数的人来说，有点时间厚度的东西就带感。声音碎片的一句歌词特别好：“顺流而下，把梦做完”。 新年快乐！

这两天大概面了5、6位应届的同学，最后往往忍不住聊的多了些，有点开复老师的感觉了。归纳下来有几个突出的问题。 1. 在公司实习学不到技术，学到的只是做事的方式 这些做事的方式（或者说技巧）有些是必要的，比如沟通方面。但更多是没有价值的，比如大公司繁琐的流程，各种毫无道理的开发规范，拖沓的做事风格等等。对于技术人员来说技巧性的东西千万不能太重。一个技术团队如果让实习生学不到专业上的东西，可以质疑其专业性了。应届生在学校，在公司如果都接触不到最专业的技术，那么他们又怎么能成长起来呢。一个恶性循环的开始。前端开发岗位的需求这么大，但始终缺少专业人才的一个根本原因吧。 2. 用的不是技术，更多是技巧 由于在学校里没有系统的前端开发课程，导致对html/css/javascript基本概念的理解非常薄弱。大部分人的学习方式是：先看书，然后觉得书和实践离得很远就直接实践，遇到问题就去网上搜，而搜到的基本都是“技巧”性的东西。或者是跟着学校里的“牛人”学，掺着各种好的、坏的经验全盘接受。比如实现一个左图右内容的显示效果，写出html和css（见下图）。这是我的一道笔试题，看起来很简单吧。但是还没有人答出最佳答案。如果去网上看，国内那些大网站们是怎么实现的，就不能怪他们了。 a方案 – 百度新闻首页： <table> <tr> <td valign="top" class="imgtd"> <a …><img …></a> </td> <td valign="top">…</td> </tr> </table> html结构丑陋，但css简单。 b方案 – 新浪微博首页： <div class="twit_item MIB_linedot2"> <div class="twit_item_pic"> <a href="" target="_blank"> <img src="" …> </a> </div> <div class="twit_item_content"> …. </div> </div> css实现： .twit_list dd .twit_item_pic{float:left;width:66px;padding-top:2px;} .twit_list dd .twit_item_content{float:left;width:316px;color:#666;line-height:18px;} 大部分应试者都是这个答案。用了浮动就必须定宽，结构就失去灵活性，同时必须解决浮动带来的一系列问题。 c方案 – [...]

这个话题是我一直以来思考的问题。其实4年前我在淘宝分享过一个基于ant的静态文件编译系统，但那时候对基础架构的全局还没有一个总体思路，现在看来它没有充分用在开发中，不是它本身做的不够好，而是因为它没有完全植入到整个技术体系中，只是一个单纯的工具，这样它发挥的作用始终是有限的。2年前我才真正意识到前端基础架构的意义，它是把技术更好的吸收、组合、应用出来的基础，也是一个足够专业的前端团队高效运转的基础。 我一直以来在追求前端团队职能价值的最大化。那么首先回顾一下前端职能经历了什么样的转变。我相信这些转变不需要过多解释，大家都能理解。但是又有多少团队真正转变过来了。职能和价值更多还是停留在页面是否高效的实现上。 区别只是人多了，分工过细，人被局限在一条流水线的各个环节上，被当成工具使用，没有发挥余地，也没有成长空间。前端工程师实际上沦为苦逼的‘码农’。所以需要一个更好的体制和环境把前端开发的职能作用充分发挥出来，创造更大的价值。同时，对于想上市或想创造奇迹的互联网公司们需要的也不是一两个技术牛人，而是一个更加专业的团队 首先角色定位必须清晰。前端工程师比设计师更懂得界面和交互的实现原理，所以要能弥补设计师或产品经理在技术理解上的不足，这是中国特色。开发的工程特点上跟后端开发非常接近，所以不能脱离整个技术体系，要尽量减少中间环节，共用开发环境，共用系统。前端开发在设计部门是过去时，现在更适合在技术部门。2是打造专业团队，这种专业性不是一两个牛人带来的，而是体制和长时间的技术积淀带来的。3也是通过深厚的技术基础和敏捷的开发方式带动团队高效运转，而不是通过行政管理手段。这个技术基础就是一个不断完善的向前演变的技术平台。最后是结果，带来技术上的持续创新。 今天要谈论的“前端基础架构”就是这个技术平台中的重要内容。什么是 “前端基础架构”？它应当具有这些特点和作用。要先做技术的布局，才能从大格局出发指导用什么和怎么用技术。细节可以先不够好，但整体要有，要能发挥作用。所有人不是机械的完成项目开发需求，而是创造性的应用技术，并且做好技术回收，有意识的积累下来。3是它有团结的作用，内聚所有人的智慧，调剂技术的活跃度，探索新领域。4是从体制上做到技术的大融合，让前后端开发无缝结合在一起。 总结我之前的经验教训，用这个故事可以很好的说明。不是片面做一个局部或放大局部的作用，比如做好一个工具或一个代码库，它的作用都是有限的。而要从大格局出发。所以，我整理了一张图。 这张图从下向上看，它就像一颗树，不断滋生枝干。基础架构的建设正是如些，也是一个不断生长的过程。其中主要的结点构成前端技术的大格局。最下面的是它的根结点，后面会逐一分解。 去年我在另一个活动上分享过同样的话题，不过那时候只做了2成，一年过去了，现在可以说做到4成。它就像一颗种子，需要所有工程师智慧的培育，才能长成大树。 工具、规范和系统看起来是独立的三大块，但它们之间是相互作用，紧密联系的。工具是为落实规范、保证品质定制的，系统又把工具有效的串联起来，建立一套有秩序的开发环境。mission是为了打造高品质的产品使用体验。工具体系由这些部分组成。代码管理是为了代码的模块化组织、提高重用、化繁为简的预处理，从而达到更高的可维护性和灵活性。品质检验的目的是保证代码符合我们约定的统一的代码Guidelines的要求。测试是为了避免异常，规避风险。上线后的运行监测是为了运营过程中的服务品质的持续性。这块是我们正准备做的。 我们在服务器端对无论是内联还是外联的js和css代码进行模块化的组织。使用这种@import的编译语法，在开发环境中看起来是这样的。上线后会将编译后的文件再部署到CDN css文件除了支持@import编译语法外，还会支持SCSS语法，并且引入Compass的CSS3 Mixin Library，简化开发，使CSS开发更像语言那样去组织，提高开发效率。除此以外，我们还会进一步引入OOCSS概念，称之为Douban-UI，它是对通用信息元素进行对象化的抽象，建立的一套基本样式库。 库和框架是工具中的重要分支。它的根本目的是为了代码资源的重复利用。从格局出发拥抱开源技术，从项目开发中回收技术，结合自主开发弥补空白。除了建立丰富的通用功能库外，同样会重视应用架构的设计，比如应用框架这个分支包括模板系统、前端MVC框架等。在移动开发方面，因为其性能敏感等特殊性，我们会组成更合理的方案，比如用Zepto代替jQuery。在桌面开发上，有洪强宁(豆瓣的首席构架师)开发的onering，它是基于webkit，支持html5的桌面应用开发框架 规范仍然是最最基础的。规范应当具备可操作性，同时要有配套的检验工具。测试部门帮我们在CI中集成了Douban-JSLint，这是根据我们的规范要求定制后的JSLint，同时，我们也会把它植入到开发环境中，很方便的自检。技术文档的积累也是不能忽略的，它是重要的学习资源，结合培训，帮助新同学尽快溶入到团队中。同时，我们也欢迎后端工程师写前端代码，正如我们也会涉足后端一样。这种技能上的重叠，会让协作更默契。我们也正在努力通过规范和工具降低门槛、扫除障碍 我们有三种开发环境，前后端在同一环境下协作开发，尽量减少中间环节。开发前，参与的前后端工程师一起制订一份开发文档，内容主要是URL和对应模板的规划，Ajax的接囗的说明等等。然后，前端部分直接开发出最终的模板和实现交互，用假数据摸拟输出，不好实现的接囗会利用诸如Charles此类工具映射到本地的数据文件上。前后端开发是非常平行的。在项目管理上，也尽量用工具辅助，避免囗头提需求，而是以Ticket的形式启动后面的开发流程，这个过程是简捷而默契的 开发流程追求的是敏捷高效。为了保证最终产品的品质，该有的环节还是不能缺的。所以好的流程是将工具、系统和各种子系统完美的串起来，自动化程度高，同时又操作性强。 正好昨天有人在知乎上邀请我回答一个问题。可见团队大了，技术应用复杂了，要提升它的职能作用，建设前端基础技术架构，是一件非常有意义的事情。 slides: http://www.slideshare.net/kejun/ss-9413262