很多人写了D2的心得，都很精彩。整个一天，我感觉是在温习，只是对某些知识库有一些发散。大为的“模板语言”提到数据为基础渲染为上层建筑，这个基本原则在做雅虎关系的时候就烂熟于胸，YUI对这个原则的提炼要更加精辟一些。克军的“YUI2-YUI3的演变”有人觉得很泛泛，我觉得思路很清晰，大概是因为在我们还在yahoo的时候克军就分享过相同的话题，到现在克军的PPT内容改了不少，但思路没变，都是在说库到框架的演变，只是上次分享是面向咱们几个同事、更加专业，这次是面对鱼龙混杂的听众，必然要范一些，这里不得不提到早就成了炮灰的雅虎关系，最后两次改版使用预览版的YUI3做的架构，虽然性能做到了极致，同时也发现YUI3并没有我们想象中的完美，简洁接口背后的代码一样脏乱不堪，用YUI3做架构竟然将大部经历放在了hack yui上，杯具。下午的QQSevlight演示不错，让我回想起在学校做数码杂志的陈年旧事，通宵达旦的手写flash脚本，那时还没有zcom，falsh代码还是笨拙的手工编写……，不知道现在的先锋技术部还有没有这个传统。明成的演讲很有风范，只是前端安全这个话题本身就没什么深度，我觉得这和套页面差不多，只要细心就能做好，就怕你粗心。我在读研时的方向是邮件协议的安全，成绩不咋地，但也明白一个道理，真正的安全只存在于理论，越底层的安全防范越是健壮，web前端技术处在上层建筑的上层，只适合安全领域的初学和入门，看QA的时候问的菜鸟问题就能体会前端工程师对安全问题的无知和茫然。因为真正的安全一定是跨领域跨学科的，前端安全永远是“顺便”的话题而已。这次秦歌也很有派头，只是话题略显陈旧，整个讲了一遍yslow……
心不在焉的听着演讲，心不在焉的思维发散，整个会场一股浮躁之风，克军捅破了这层窗户纸，前端工程师技术门槛齐低，不意味着你很牛逼，wd需要学习设计、也需要学习架构、更需要一点点计算机理论知识的积淀，搞到现在整天牛X哄哄的瞧不起朋克搬的VD、也看不上黄牛一样的工程师，在自己的象牙塔中玩着html、css、js这些皮毛……
总之，前端技术就像九阴白骨爪一样，固然牛逼异常，但我们太过把精力放在九阴真经上了，忽略了九阳神功的铺垫，没有内功的修炼，最终炼成的白骨爪也只能和梅超风一样，根基甚浅徒有其形。
ok，心不在焉的说了这么多，又好像什么也没说一样，就当一场过眼云烟吧。看看D2上胡乱拍的照片，或许这才是这次D2最大的收获。
http://www.flickr.com/photos/lijing00333/
[ view entry ] ( 334 views ) | permalink |
( 3 / 199 )导语：如今的前端开发越来越OO，也越来越注重重用，娴熟的用js写出OO的前端代码已然是一个前端工程师的基本素质之一。与此同时，网站的开发过程也越来越类似于堆积木。模块思想也逐渐深入的应用在大型网站的开发之中，指导网站的设计和架构，在今天【珍珠奶茶帮】的分享中，我们来对基于YUI的组件开发做深入探讨。
模块化的前端开发
在web技术迅猛发展的今天，大型网站的前端开发越来越依赖复杂的团队配合，而模块化思想则能有效的指导团队开发的效率提升和成本压缩。它使得我们在项目中将注意力放在颗粒化组件的组装上来，而不用花费精力去考究每个组件黑盒内的实现，从而使得项目开发更加高效。类似于某些软件的界面开发，无非是用鼠标将控件库中的控件拖拽到面板中摆一摆罢了。而在YUI2.x的时代，YUI中的大量组件也极大的方便了我们的开发，而如今YUI3具有更加强劲的动力，但还未有太多widget可用，则需要我们手动开发组件。
组件的特点是高内聚低耦合，且一个完整成熟的组件不应当依赖于环境，这和插件有着本质区别。因为组件只需要对外暴露接口，共外界调用即可。
此外，组件有一些必要的组成部分:组件需要初始化、组件有其依赖的字组件、库和皮肤。组件也可被修改（也被称作重新初始化）。再进一步看，本质上，组件都包含样式、独立的数据和交互逻辑，这三部分也被称作M(Module)、V(View)、C(Control)。比如在淘宝杂志中的评论组件，MVC是如此分布的：
组件中的MVC
其中Module和View应当完全剥离，他们通过Control连接起来。而且从他们各自的稳定性角度来讲，Module(data)是在运行时才能确定的，View(UI)是半确定的，因为可以换肤，而初始化的时候则必须有确定的皮肤，Controller(逻辑)则是确定的，包括数据格式和交互行为。这里很清楚的表明了组件的三个部分，如果一个组件的功能不好抽象，则可以按照这个思路进行抽象。
设计一个组件
组件设计者应当熟知：组件源于项目而高于项目，不要对组件的使用环境进行假设，设计之初将精力放在丰富的接口和参数配置上，同时，要设计出完善的黑盒交互。按照这个原则设计的组件具有可重用、易用、健壮的特点。
对于开发者来讲，要想保证前文提到的可重用、易用和健壮性，则需要遵循如下三个原则
1. 注意配置项的优先级
2. 尽可能少的类
3. 保证源码可扩展性。
其中基础配置是指应当在具体项目中确定下来的配置，比如弹出框的行为，包括有无阴影、是否可拖拽、是否跟随滚动条滚动而滚动，项目中所有的弹框的这些属性应当统一，这些配置我们称为基础配置。缺省配置是指参数默认为空的时候的填补。必填的配置是强制传入的参数。
要使用尽可能少的类是为了保证代码的结构简单内聚，比如，我推荐使用原型单体来做源码的包装。而且在开发组件的时候，一定要区分最重要的两个方法，init和render，分别代表初始化和重新初始化，如果你的组件是可以被中途改变状态的，应当注意这一点。
另外，还有一些要诀是需要铭记在心的，这些要诀对于组件代码的可扩展性是很有帮助的。因为组件的生命周期很长，甚至要长过项目本身，这也意味着他的维护周期也很长，可能会有很多人不断的为这个组件增加功能，那么，做好组件的骨架以便后续的增量开发不增加源码的熵值则显得尤为重要，因此，能否搭建良好可扩展的组件结构也是体现开发者基本功的参照之一。这些要诀大致包括：
1. 属性属于对象、方法属于原型，
2. 基于原型的(显式)构造器，
3. 组件的自定义。
其中第一点是常识，但工程师在做类继承的时候往往忽略了这个简单的原则，导致代码组织混乱。第二点的灵感是来自dojo、mootools、 prototype等框架在类继承方面的设计经验和良好实践，第三点的灵感则来自于YUI3关于OO的设计思想。
熟练运用以上原则对于开发一个高质量可扩展的组件是大有裨益的。最后总结下组件的一生，组件来源于特定项目和具体的业务场景，开发者将通用功能提取出来，形成组件原型，并被更多的项目和业务场景使用，同时其功能随着时间的推移而增加，组件变的越来越完善，它的生命周期远超过某个产品的生命周期，因此，我们有理由高喊我们的口号：产品恒久远，组件永流传。
ps：ok，说了这么多，还没有提到正题，这些和YUI有什么关系？确切说是和YUI3有什么关系？YUI3脱胎于YUI2，可以说青出于蓝而胜于蓝，YUI3天然优良的架构为组件的骨架搭建创建良好的基础，这些内容包含自定义事件、YUI3教科书式的代码重用实践、以及其插件机制，由于时间关系，这些内容将在下期【珍珠奶茶会】上做分享，请密切关注。
本期分享的ppt：
http://www.slideshare.net/lijing00333/yui3-2728729
下期分享的ppt草稿抢先看：
http://www.slideshare.net/lijing00333/yui3-2563104
[ view entry ] ( 315 views ) | permalink |
( 3 / 178 )昨天参加了webrebuild，碰到了很多熟人，也听到了克军关于LSM的分享，包括克军在内，会上很多人怒斥前端开发糟糕的现状和不规范的流程，而且提出很多新颖的团队合作流程，都感觉这些流程太过新颖以至于有些理想化，因为他们忽视了流程中的最关键的因素，人。
这让我想起YUI团队的协作方式，yui的一个build到下一个build之间的流程是模糊的，甚至感觉有些混乱，但有一点是清晰的，两个milestone之间，任何两个人的合作关系是清晰高效的。也就是说，每个工程师清楚的知道他的前驱在干什么，也清楚的知道他的后继需要他做什么……因为，即使每个人的具体工作不同，但知识总是交叉相错的，工程师懂设计和架构，架构师懂设计和需求，设计师懂需求和开发，在这样一个高水平的人组成的团队中，再罐以复杂的流程约束反而会降低生产率。
因此，回过头来思考一下我们的初衷，不论如何改变流程、如何招人，目的只有一个，提高生产率。那么在人的能力水平没有提高的前提下，一味更改流程是没有用的。这就类似58年的大跃进，GCD试图带着一帮农民搞大跃进，就真的跃进了吗？封建制度一定是在土地霸权产生后出现的，资本主义也一定是在资本家萌芽之后发展起来的，人不改变，而将精力放在制度和流程上？无异于本末倒置，拔苗助长。
看我们的现状，企业往往为了降低成本，招了一群烂本科生进来，不懂信息架构、不懂设计、不懂工程化、对计算机基础学科的理解一瓶子不满半瓶子咣当，甚者仅仅会写一些HTML、CSS和JS……对由这些人组成的团队期望YUI团队的高质量的生产，这是五十步笑百步。在实际情况中，团队成员之间知识结构无交叉所带来的问题远远大于流程的问题。
在看看webrebuild里克军的设想，工程师和设计师同时去follow产品，我认为这个提法没有问题，但是这种流程的可操作性取决于一个大前提，就是产品经理能否产出一个高质量的PRD、PRD是否包含足够工程化的语言和足够丰富准确的内容，在工程师和设计师分别follow的时候不会产生歧义，而且可以合格的做一个设计师和工程师的答疑文档？实际情况是产品经理完全没有能力做到这一点，PRD粗制滥造、不反复修改需求就已经烧高香了。设计师和工程师遇到需求不明确的地方唯有使命的召唤，诉诸面对面的沟通，面对面的沟通看似效率高，其实很多临场的决断都是欠推敲的，会给产品埋下很多不必要的隐患。
ok,说了这么多，问题的关键在于人才的培养，使用健全的培训制度不断为成员输血，提高每个人的知识面和能力。我们不能捡了西瓜丢了芝麻。
另外，我们似乎有一种“流程优化”情结。我觉得完全过虑了。流程是完全可以用工具进行优化的。比如在yahoo，前端代码css、js、img文件要压缩上线，需要首先将js和css代码压缩一份，并将源码check in到svn中，再将其传到一个跳板机上（安全考虑、工作机是无法直接登录cdn服务器的），再传到cdn上。每次上线都会重复这个流程，其实这个流程完全可以用自动化工具搞定，同样提高效率，就没必要再去优化这个流程了。
工欲善其事，必先利其器。
其实使用工具辅助流程优化是一个提高生产率的思路。这里说的工具应当是一个抽象的概念，比如DPL可以是工具（至少他类似于工具书），组件库也是工具，UI设计指南和文档都是工具，我们要做的，就是去构建这样一个高质量的工具箱。
就像Yahoo DPL带给我们的谆谆教诲：构建DPL耗时耗人耗力，但一旦完成，后续开发效率会有飞速的提高！
以上YY，切勿当真...
[ view entry ] ( 406 views ) | permalink |
( 3 / 187 )克军：快加我！
克军：web重构是5年前的话题，这事儿整的……
克军：我们的关注点应当再回到HTML上来……
克军：分层语义话是一个大趋势……
克军：前端工程师应该做的是，向前兼容和向后优雅降级，为了ie6的重构不会解放前端工程师的工作……
克军：web产业已经进化到产业化的道路上来，企业不会因为工程师水平的参差不齐而产出质量有很大差异的产品……
克军：不要写类似<div class="cqfd"></div>的代码
克军：放大是zoom Out吗？哦，这就是英文不好的后果……
ps：
阿当：YUI扩展性远远超过jquery
阿当：使用jquery的人群鱼龙混杂水平参差不齐，有很多低级的代码充斥在jquery社区，严重影响jquery的品质
[ view entry ] ( 418 views ) | permalink |
( 3 / 171 )终于能抽出时间将cubee的实现的细节整理到了wiki里，大概不会有人有兴趣去读这些文字，有时间将cubee的来龙去脉整理下，做成ppt能更好看一些
http://code.google.com/p/cubee-js/
以上！
[ view entry ] ( 422 views ) | permalink |
( 3 / 182 )
