web标准化交流会是去年11月，web标准化联盟群的线下技术交流会产生的一个组织。已经连续举办了6期，年后一期停办，已经开通了四个城市同步进行的类似与UCD书友会的前端交流平台。

Webrebuild.org是07年在深圳成立的以年为单位的线下座谈会，共同探讨web标准，推动web标准的发展。深圳已经连续举办三届，北京去年举办了一届。应前端者的要求，不能只在深圳举办，很多外地的同学没法参加，09年12月在北京开通北京站，并联合W3C 谷歌技术用户组，在谷歌成功举办。

我09年10月份来北京发展，作为webrebuild.org第一批会员，有责任把北京分站筹备起来，刚好遇到了做线下交流会的想法，就两个事情一起做了，也想过与其搞那么多分散的组织，不如集中力量以统一的平台推广web标准，就单方面沟通过，把交流会作为webrebuild.org的月会，webrebuild.org年会和月会相辅相成，这样效果更好一些，也有很多支持webrebuild.org的朋友参与进来，月度筹备交流会，年度筹备年会。基本上的想法就是Webrebuild旗下的交流会。然后我承担起了交流会网站的建设，提供了我的域名w3ctech.com和服务器支持，当时我作为蓝色理想web标准化版的版主，也大力在蓝色理想推广交流会。

没想到的是由于这些都是单点沟通，随着交流会名声壮大，很多人参与进来，却不知道两个组织之间的事情，导致了为什么要把交流会纳入webrebuild旗下的争论和不满，还有webrebuild年会主办方为什么不加入web标准化交流会。在我的想法里并不想弄出两个组织的，结果运作出两个组织的尴尬。而且出现了两个组织之间的隔阂，真是太失败了，对于这些误会，我应该承担所有责任，是我沟通和传达不利。

但是事情还得做，我就主动退出交流会组委会，把我来北京想做的一个事情做好，那就是Webrebuild.org北京站的组建。成立独立与交流会的Webrebuild.org北京组委会。让想为前端做点事情的同学可以避免这些争论，把交流会和webrebuild.org都做好，做强，而不至于到了最后因为这些误会两边都耽搁了。

对交流会，我还是一如既往的支持，就像深圳webrebuild.org组织以交流会的名义组织深圳站的交流会一样。希望这件事情大家有个清晰的认识。

最后，很多人都在为推动前端而努力，可惜发生了太多的因为组织不同而产生的隔阂，D2 Webrebuild.org Web标准化交流会 CSS森林，我也不知道百花齐放好呢，还是统一团结好。希望中国能有一个WASP，集中力量推广W3C标准，用草根的力量解决终端的混战，还前端开发一个统一一致的平台。

-EOF--

如果您是应聘HL1-页面重构工程师【http://hr.tencent.com/pages/position/detail.shtml?jobid=1997&location=0】，可以先发您的简历到ivane@qq.com，谢谢！

• twinsenliang——《一专多长》
• 张克军——《分层语义化模板实践》
• 阿当——《面向对象思想在css中的应用》
• 鲁超伍——《揭秘HTML5及CSS3.0》

座谈会费用：活动不收取任何费用，晚餐自愿（AA制）。
预定人数：100人。
活动奖品：由Google技术用户组以及华章出版社提供
与会者要求：
由于场地有限会议采取邀请制，筛选后统一发送邀请函，请持邀请函打印版进入会场。W3C标准爱好者，网站重构和前端开发人员，谢绝一切推销和推广人员参加。
报名表单：http://spreadsheets.google.com/viewform?formkey=dFJnRnZDQTN4OGlqZkJ0aERaay1QTWc6MA
报名开始和截止日期：
11月19日——11月30日
与会邀请发出：
在12月1号至12月5号，以邮件方式发送邀请函。
致外地同学：
如果你是非北京同学，请提前联系好酒店，大会由于人手有限不能负责住宿的预定，实在抱歉。
主办方：

• webrebuild.org
• W3C中国
• Google Technology User Groups (GTUG)北京论坛

详情页面
http://www.webrebuild.org

主题： 文件管理讨论
官方：http://uicss.cn/club/
嘉宾：张克军，阿当，greengnn(张建斌)
照片：http://home.blueidea.com/space.php?uid=391214&do=album&id=2301

前言：对大家能在周末抽出时间来参加会议表示感谢，挺冷的天20多人如约而至，交流会不同于大牛分享，更能面对面的解决一些工作中实实在在遇到的一些问题，大家都表示比较有价值，收获挺大的。在此也非常感谢身边网[http://www.360side.com/]的友情赞助会场。

张克军分享和观点
不同公司的不同文件管理和前端模式造成对正确的对正确文件管理和学习的成本过高。
行业还没完全成熟，行业需要一个圈子，去学习UE和交互的那种交流模式。

一个网站一个css文件是存在很多缺点的文件的冗余过大，有用的代码很少。
认为应该这样部署：
公共样式
基本模块，布局，链接等
产品级别
继承模块样式，有特点的调整
页面专属

将文件分为三个级别进行管理，有同学提到YUI的css框架，克军的观点，YUI的分类是基于技术而不是应用的

对于js的管理
js文件的划分要减少依赖，不要存在依赖关系过于复杂，不同依赖文件的版本也不同。
YUI的use()按需加载模式，颗粒话很小，这样的模式就很优秀。

素材文件的管理
全站公用的图片使用css sprites合并。
可以尝试Data URI [http://en.wikipedia.org/wiki/Data_URI_scheme]编码做内容图片的展示。

建斌/greengnn分享
分享《大页面构想》ppt
ppt内容
小页面的观点，div+css等狭隘的理解前端页面重构工程师
大页面观点，从产品诞生的流程，分析页面人员的能力模型，应该具备一专多长，要熟悉项目管理，产品，设计，后台开发，产品运营等，作为研发中的一个衔接层，更好的像产品构想和设计付诸实施。通过一些方面展现页面的价值
1.高效研发
2.SEO，廉价的推广
3.换肤，增强个性化体验经济
4.速度：用户对产品的第一体验
5.流量：成本的节约就是收益

模块化的去管理文件
第一步画出sitemap图，梳理网站结构。
第二步划分站点模块，文件模块，代码模块

模块化的代码实现方案，通过后代选择符进行模块管理，实现低耦合低依赖，满足协同开发和版本管理
详细内容见ppt中。

阿当分享
三层架构
base层 纯语言层
css方面
reset，base，和公共rules(清楚浮动等)
js方面，底层库文件，实现基本的dom，event等操作，实现跨浏览器
comm层 公用组建，可复用代码
css方面 通过封装基本表现颗粒，fs14(font-size:14px) tac(text-align:center) fl(float:left)等
js方面 基本的功能代码，动画，异步请求等js功能代码
应用层 具体页面层
css方面，页面的公共模块和私有模块文件
js的页面应用文件和代码

对于css是否封装表现类的class存在争议，大家进行了讨论，部分同学赞同html代码的纯净，避免表现类的class引入。
对于后台开发的协作，也赞同html代码尽量的纯净和可拓展性强，将界面的任务更多的交给css去处理。

接下来大家轮流发表观点，大概罗列一些
css sprites的管理
关于合并方案的讨论，纵向横向和梯形三中的优点和不足
纵向和横向不利于某个图片突然高度和宽度的变化
css sprites的文件类型
不是动画类的，选择png-8 256色

css sprites的管理
公共的和页面级别的分开成不同的文件

王峰分享了他的css管理方案
给每个页面body定义id，给模块定义id，可以快速的通过id找到对应的代码。
根据body id可以区分不同页面的css代码，可以多个页面的css代码放到一个文件中。
css文件分为两层，公用层和页面层

其他一些讨论汇总
1.建站公司效率第一，对于一些常用的表现也会封装起来，比如左浮动，文本对齐等，可以快速实现页面，满足客户需要。
2.模版的分享，有存在一些前端开发同学进行模版的管理，采用的模版机制各有不同，有xml+xslt的模式，还有smarty模版等其他的模式
3.换肤代码管理的讨论，如何实现换肤的管理。讨论的结果，html结构固定，尽量可拓展性强一些，换肤的几种模式按需选择csszengarden的完全独立的换肤文件，还有把颜色，背景颜色，背景图片的可变部分分离出来实现换肤。都通过修改css文件来实现。
4.搜索类网站为了速度，使用table+style的方式是不是合理。

由于没有专职的人员记录，会议讨论有记录不准确和遗漏的还请见谅。
这次交流会的一些不足总结：
1.口头交流居多，演示方面不足
2.由于路途遥远和地方不好找，开始时间有点推迟。
3.流程不够明确，自我介绍环节做得不够好。笔记和在线直播没做好
4.设备不足，白板的笔没有水了，呵呵

其他人的会议总结：
张克军
http://hikejun.com/blog/?p=466&cpage=1
周裕波（忘记）
http://www.webchina110.cn/?p=303

拆分页面模块，从小到大的分解
1. 拆分页面模块
一个页面有很多个小单元模块组成，他来自有原始需求文档，比如
logo，导航，内容1，内容2，内容3，内容4，尾部导航，版权信息等等。
根据他们就可以拆分出基本的模块。
2. 拆分网站模块
将整个网站安排频道或者分类进行拆分，比如
首页，内容页，文字列表页，图片列表页，频道1页面，频道2页面，分类1页面，分类2页面，后台管理页面，等等
3. 每个网站作为一个模块。比如
商城站，支付站，论坛，三个站独立为三个大模块。

模块化实现
1. 高度耦合提取为一个模块，将模块代码作用域进行控制
代码1.非继承模块，通过后台选择符方式控制作用域

<div class="mode">
	<h3 class="title">title</h3>
	<div class="con">
		con
	</div>
	<a class="more">more</a>
</div>

.mode {}
.mode .title {}
.mode .con {}
.mode .more {}

<div class="footer">
	<ul>
	 <li><a href="" title="">关于</a></li>
	 <li><a href="" title="">合作</a></li>
	 <li><a href="" title="">招聘</a></li>
	</ul>
	<p>Copyright © 2009 某公司 版权所有</p>
</div>

.footer {}
.footer ul {}
.footer p {}

代码2.继承模块，提取众多模块中公共部分，具体模块通过优先级进行处理。继承模块方面整站某些模块的批量修改处理，也提高复用性降低代码重复。

.mode .title {}
.mode .con {}
.mode .more {}

<div class="mode mode2">
	<h3 class="title">title</h3>
	<div class="con">
		con
	</div>
	<a class="more">more</a>
</div>

2. 页面模块
页面模块代码作用域的控制通过css文件来控制。某类具有高度耦合的页面使用自身的css文件。
3. 模块间的公开接口
上面是模块的封装，公开的接口在页面中表现为什么？
首先是reset，base，可继承模块，这些代码是开放接口，必须根据这些代码进行页面代码开发，也就是你的页面代码必须在以上代码基础上开发。
其次是css文件，css文件名称和他作用于那些页面。
再次是布局、模块class，id命名，模块在页面的哪个位置。在CSS中的表现就是定位，布局，和部分盒模型。float、position、width、height等等。布局通常使用css作为接口实现，如果布局具有高度的逻辑性，完全可以通过html和css组合进行，比如960 Grid System，或者采用YUI grid.css。模块class和id的命名用于区分模块，不能在一个页面的所有css中出现不同模块同用一个class和id名。

规划整站模块
上文提到的基本的原理，真正实施起来还是存在很多问题，模块粒度问题，公共模块与普通模块的区分，继承模块是否值得继承等等，页面模块如何划分。
首先，了解你的项目，通过画网站树状图了解你网站的总体结构和页面模块
其次，理清结构逻辑和视觉逻辑，结构逻辑就是看你的页面由那些模块组成，视觉逻辑了解可继承模块，布局逻辑（网格布局或者非网格布局）

附图：

模块化就是为了减少循环依赖，减少耦合，提高设计的效率。为了做到这一点，我们需要有一个设计规则，所有的模块都在这个规则下进行设计。良好的设计规则，会把耦合密集的设计参数进行归类作为一个模块，并以此划分工作任务。而模块之间彼此通过一个固定的接口（所谓的可见参数）进行交互，除此之外的内部实现（所谓的隐参数）则由模块的开发团队进行自由发挥。

程序模块化的目的：

1. 减少循环依赖
2. 减少耦合
3. 提高设计效率

程序模块化的实施：

1. 把耦合密集的归为一个模块
2. 模块间通过固定的接口交互
3. 模块内部实现自由发挥

《宜家》

IKEA的研发体制也非常独特，能够把低成本与高效率结为一体。IKEA发明了“模块”式家具设计方法（宜家的家具都是拆分的组装货，产品分成不同模块，分块设计。不同的模块可根据成本在不同地区生产；同时，有些模块在不同家具间也可通用）。这样不仅设计的成本得以降低（因为基本每一种设计都是可制造的，不会因为大量的设计方案不具备可实施性而去莫明地浪费成本），而且产品的成本也能得到降低（模块化意味着可以大规模生产和大规模物流）。
IKEA的设计理念是“同样价格的产品谁的设计成本更低”，因而设计师在设计中竞争焦点常常集中在是否少用一个螺钉或能否更经济地利用一根铁棍上，这样不仅能有降低成本的好处，而且往往会产生杰出的创意。
可能IKEA是唯一能深刻理解“简单即美”的机构，他用“简单”来降低顾客让度成本，用“美”来提高顾客让度价值。

IKEA模块化目的：

1. 设计成本降低，都可实现
2. 产品成本降低，大规模物流和大规模生产

IKEA模块化实施：

1. 产品分成不同的模块，分块设计
2. 有的模块在不同的家具间可以通用

可以看出，两种模块化的实施都是类似的，耦合密集的区块分为一个模块，独立自由设计，提供开放接口。可以产生低成本，大规模生产和开发的效果。

互联网研发

互联网研发的流程，概念、需求产生，设计[产品设计，交互设计，UI设计]，开发[前端开发，后端开发]，测试，发布，然后第二版本 新的概念、需求产生，再执行一次研发流程。在这个环节中，概念的产生总是非常容易，研发的周期总是非常漫长，市场总是稍纵即逝。所以版本迭代的速度也就是提升的敏捷开发是一个企业竞争力的体现。

在前端开发环节中，如何运用模块化方法提升迭代的速度和开发效率呢？

首先，管理模块化，将流程进行模块化，分为策划，交互设计，视觉设计，前端开发，后台开发，测试，运维。每个流程都是高度耦合的，作为一个流程，流程之间采用公共接口进行衔接，也就是交付物。

其实是某一个流程中具体的模块化，就拿我熟悉的前端开发举例：

现在有某网站v 1.0版本发布，版本计划是这样的

• 产品策划 3人天
• 交互设计 3人天
• 视觉设计 3人天
• 前端开发2.5 人天
• 后端开发5人天
• 测试 2人天

共计 18.5 人天

为了在前端开发阶段提高效率，让两个前端负责开发，一人负责一部分页面，彼此没有沟通完全自由独立开发，1.5天后双方将代码合并，发现存在多处样式属性重叠冲突和js变量冲突，约定其中一个代码保持不变，另外一个代码进行调整，耗费1人天。

而如果两个人在开发前期使用0.5天进行沟通，约定好高度耦合的部分归为一个模块，双方按模块分工，模块内部自由开发，模块外部约定公共接口。然后1.5天后代码合并。提交后端开发工程师。

…

V1.0 版本发布

V2.0需求已经期待很久，又流程走到了前段开发阶段，需求是对局部功能进行改良优化，还是分两种情况

1. 非模块化代码设计，开发和解决代码冲突耗费2人天，其实开发只需要1人天
2. 模块化代码设计，开发耗费1人天

到了后端开发，进行后台开发，两种情况

1. 非模块化代码设计，页面html修改多处，模版文件进行多处修改
2. 模块化开发，仅仅这几个模块进行代码修改，修改模版工作量很少

从这两个例子可以看出，模块化在研发中版本的迭代速度是很快的，某公司产品以最快的市场应对速度赢得用户的认可和好感，获得可观的pv或者收入。

[未完待续..]