连接
◆《重构之美》总目录

重构之美－跨越Web标准，拥抱语义网

　　我又开始了，现在是2008-8-3 14:55，四年前的此时此刻我怀着激动的心情在蓝色理想发表了第一篇《重构之美－迎接Web标准化设计的来临[在怀疑中选择]》，四年后的此时此刻，我开始连载《重构之美》最后一部分，希望能画上一个句号。

　　这篇文章写于2007-5-12 15:55，本想一年前发表，但是那时根本没有时间和精力来完成这一系列，也就埋了一年多。

废话先

　　这个标题在一年多前我就想好了，赶个时髦嘛，三部曲：迎接、在路上、跨越。蓦然回首，从2004年6月开始接触标准，04年8月到12月写‘迎接 ’，06年3月到6月写‘在路上’，现在开始写‘跨越’，三年三个阶段，时间一晃而过，我惊讶于自己在这个没有什么高科技技术含量的领域居然滞留了三年。有时想想，为什么是三年而不是三天？如果是三天多好啊，时间是那么的珍贵，尤其对我来说，年底即将面临人生年历的第三次十进一。

　　太多太多的弯路了，我走了。太多太多的时间了，我费了。常常面对一个细得不能再细的问题，站在原地，左脚向前跨出一步然后收回，身体转动1度再跨出一步，又收回。总是要无比耐心的伸出收回左脚无数次后，右脚才能跟上去一次，站定。面对就这样在旋转中被消耗浪费掉的时间，一直以为自己很聪明是黄金是天才的我只能无限唏嘘和感慨于两点：1、我的愚笨。2、摸索的艰难和前进的不易。

　　写下这个标题，其实我很惶恐。“跨越Web标准”我还是敢说的，但是语义网却不是那么好拥抱的，现在的我根本没有资格去吼“拥抱语义网”。当然我很喜欢这样的标题，很有气势，也希望自己能够有资格去“拥抱语义网”，因为Web标准从宏观上的意义我的理解中就在于衔接第一代的万维网和第二代的语义网，是所谓过渡。更重要的是在应用Web标准的这个历程中，我从实践上而不是书本上概念上感受到了这一点，感受到语义网的逼近。但是我仍没资格，无法拥抱，语义网在我的世界里仍是雾蒙蒙的一片，没有放晴，我只能继续的转动自己的身体，再次伸出我试探的左脚，期待着右脚的跟进，期待着穿越迷雾，感受晴空万里的互联网II。

　　所以本来我是没打算在雾中动笔，但是可恶的是我在一年前信誓旦旦白底黑字地写下了“Promise”，唉，读者或许早忘了，但作者却没法不记住。当时停笔的原因很简单，写书。不得不坦白的交代，正是因为写书，我停止了写技术博。哎呀，我继续写博，都来看博了，谁来买我的书啊，书卖得不好不就没钱可赚了嘛，不写博了，写书去，然后大卖特卖，然后就发财啦，呵呵。当时的“Promise”是“Promise back with my book”，结果本来还很远的一年后就到了，而我的书仍遥遥无期。忙工作、人懒惰、写作水平差，总之一直是思想上豪情万丈的“我要写书”，而行动上始终处于“等明天”。等着等着，“明天”就到了，而我仍双手空空。

　　标准群里的兄弟，样式之美的嗷嗷也在写一本和Web标准相关的书，甚至为了完成这本书五月开始辞职在家专心“做作业”。知道他的水平，看过他的目录提纲，很是期待。他问我：“你又专又兼，书呢？Y的你就不能专心点写书……”我也无比的郁闷，我不仅又专又兼，还琢磨着创业，还要泡吧K歌弹琴旅行写游记生活博玩WOW和长时间专注地发呆，Y的时间为啥只有24小时？丫的为啥我爱好那么多？和人家辞职写书的魄力简直无法相提并论，我只能恨恨的说：“你就不要当我还有写书这件事了……”。

　　这一年发生在Web前端的事情不少。《设计心理学》《Don't make me think》等将UE推向了一个前所未有的高度，言必UE，貌似在前端凌驾一切。Flex2开始发飙，接过MM公司接力棒的Adobe打出了脱离浏览器的牌：Apollo。年前不断吊胃口的WPF一个多月前终于正式命名为Sliverlight，并迅速展开地毯式的轰炸和推广，1.0都还没开始，1.1 alpha又继续吊胃口。阿弥陀佛，vista终于发布了。最近Web标准领域又一件大事，本来一直属于地下组织的html5闪电浮出水面力压xhtml 并成为下一代的html。三年来一直统帅前端的xhtml一夜之间就显得极为尴尬，同时还有建立其上的Web标准。Dreamweaver CS3正式发布，据说能完全基于“div”进行可视化设计，连ajax都可视，拖拖拉拉填填属性页面就搞定。于是，RIA携着html5的冲击，再加上 DW CS3的助阵，似乎Web标准摇摇欲坠，即将轰然倒塌……

　　怎么看待呢？怎么说呢？展开的话会让这篇废话很长，最后再提出来单独说吧。这里我简单用一句话表达我的观点：RIA无疑是一种进步和革命，但他不属于现在，而html5和DW CS3给我的感觉是倒退回2004年以前。

　　写书真的是一件痛苦万分的事情，尤其是技术书。写老东西是痛苦的，因为成熟所以缺乏激情。写新东西同样是痛苦的，因为不成熟所以怀有顾虑。技术的路是学习的路，一路走来新旧交替，便成了恶性循环，死循环，一想到写书就不知道怎么办。尤其对于Web标准这种个人认为是强思路弱技术实现的东西，什么意思呢？就是很不稳定，学习的路更多的是自我否定的路，我06年写得文章对04年的文章是有否定的，而现在回看一年前的系列文章，又有不少否定。如此的反复和不稳定叫我如何能下笔去成书？从04年《程序员》找我约稿以来，“怕自己不成熟而误导读者”是我一直的心理障碍（现在庆幸当时拒绝了，否则若‘迎接’那部烂文章登上《程序员》，爆牙齿就会多出很多来，笑爆的）。我一直希望自己能冲上顶以后再捧出一本书来，所以在去年答应了周筠姐姐写书以后，这一年来我把更多时间都花在冲顶上而不是写书上。愿望是美好滴，结局是悲惨滴。一年后的今天，不仅仅书的进度缓慢，而且山顶仍然湮没在渺渺云雾之中，靠，这山咋就没顶呢？

　　从去年年初有了结构化的感悟后，严格的说此后整整一年都没啥质变和突破，一直都是coding、coding、部署、部署，对理论的实践，结构化的实践。虽然完整搞定了一次从零开始的团队应用部署，虽然在团队应用和项目管理方面获得了不少收获，虽然坚持抗下来的繁重编码工作中也让我在技术细节上获得了不少收获，但是……但是这些都是在领悟结构化后基本已经预见的东西，不过是用实践验证了理论一次，不过使得我更为熟练一些，更快一些，能够很忽悠的为个人简历添一笔“有大团队成功应用部署Web标准的经验”，仅此而已。我一直都清楚的知道也这么认为，在Web标准这个面上，这一年我一直以来的各种大小收获都没有一个能够和领悟结构化而产生的意义相提并论。这种在思路上期待突破的精神折磨终于在今年年初结束了，我好像终于又摸到了什么东西，好像终于又上了一个台阶。到底是有所突破还是哗众取宠，是骡子是马，拉出来遛遛……

　　最后，我决定从下篇开始，将此次标题修改为“触碰”，虽然“拥抱”的愿望是美好的，但是实际上还是在触碰、在试探、在蜻蜓点水……

爆牙齿

[ 本帖最后由 blank 于 2008-9-23 10:21 编辑 ]

重构之美-跨越Web标准，触碰语义网

回锅文，写于2007-5-23 12:21。

开门见山：Microformat

　　Microformat，认识它的时候很神奇。我查了一下在标准群里的聊天记录：

    2006-06-23 16:42:45 爆牙齿郑旻()
    晕，标准就标准嘛，微软又偷换概念了，微格式（Microformats）
    http://www.xml.com/lpt/a/2005/03/23/deviant.html
    2006-06-23 16:44:46 old9()
    http://microformats.org/
    2006-06-23 16:51:49 爆牙齿郑旻()
    看了几个hcard的实例，真TMD乱来
    懒得理
    2006-06-23 16:52:52 爆牙齿郑旻()
    居然还可以堂而皇之的冠名：hCard
    确实牛
    2006-06-23 19:25:30 Realazy.org()
    这是微软的吗？
    2006-06-23 19:26:45 Realazy.org()
    看清楚哦

    2006-06-26 22:05:10 Realazy.org()
    嗯，对，最近谁在关注microformats没？
    2006-06-26 22:05:21 old9()
    暴牙？
    2006-06-26 22:05:35 Realazy.org()
    Yahoo已经用上了。http://upcoming.org
    2006-06-26 22:05:48 x5.liu()
    最近看到太多人提microformats了
    谁能给我简单解释一下
    2006-06-26 22:06:11 爆牙齿郑旻()
    我没关注
    2006-06-26 22:06:21 Realazy.org()
    简单的说，是在兼容当前XHTML的前提下组织信息的一种方式
    2006-06-26 22:06:47 Realazy.org()
    通过这个标准的格式，方便于各种不同的用户端来处理
    2006-06-26 22:07:00 爆牙齿郑旻()
    定个小规矩取个名字就OK了
    2006-06-26 22:07:09 jjgod()
    Microformats 要有一些比较漂亮的演示才会有人关注阿 XD
    2006-06-26 22:07:43 Realazy.org()
    http://upcoming.org/ 上有一些不错的例子
    2006-06-26 22:07:45 x5.liu()
    恩，近期我研究研究这个东东
    2006-06-26 22:08:09 爆牙齿郑旻()
    Microformats的XHTML结构就不好，烂，依赖class算啥，我简单这么认为的哈
    2006-06-26 22:08:44 Realazy.org()
    当前只能做到如此了
    2006-06-26 22:08:51 Realazy.org()
    http://corkd.com/
    2006-06-26 22:08:59 Realazy.org()
    这里也有些应用
    2006-06-26 22:09:32 x5.liu()
    我上upcoming.org了，具体哪个地方是microformats的应用？
    2006-06-26 22:09:39 Realazy.org()
    如果使用单纯的XML当然好，但是会提高门槛
    2006-06-26 22:09:49 Realazy.org()
    http://upcoming.org/event/46123/
    2006-06-26 22:10:18 爆牙齿郑旻()
    XHTML它也用的很烂啊，还没说xml呐
    2006-06-26 22:10:26 Realazy.org()
    Export...那里有简单的应用
    2006-06-26 22:10:42 Realazy.org()
    怎么个烂法？
    2006-06-26 22:11:18 爆牙齿郑旻()
    还没看

　　之后群里不时的对microformat的一些讨论就不发来凑字数了，我只是想说当我第一眼看见microformat的时候极为不齿，甚至没细看，肤浅的因为“micro”就想当然的认为它是微软的东东，我大概记得当时还说过这么一句：“不就是一套class命名规则嘛，老子也定义一套 class命名规则，然后叫它爆格式。”但是3个月后，当我在部署标准过程中遇到了一个很棘手的问题时，我猛然想起了microformat，可惜当时自己身陷在繁琐流程、大小会议和沉重的编码设计压力中无法静心思考。今年年初的时候，我终于有机会安静下来，带着自己一直的困惑再度审视 microformat后，终于感觉上有所斩获。具体怎样下次再表，我们先还是来认识一下曾被我鄙视的，大名鼎鼎的Microformat。

　　Microformat到底是什么东东？上面对话中，其实Realazy已经做了简单总结：是在兼容当前XHTML的前提下组织信息的一种方式，通过这个标准的格式，方便于各种不同的用户端来处理。这个比较抽象，我们把它扩展开来。

　　google了好一阵，都没能找到Microformat的起点，能找到的最早的文献就是我上面的那个链接：http://www.xml.com/lpt/a/2005/03/23/deviant.html。从时间上看是2005年3月23日，发展至少都两年多了，我是在一年多后才接触，两年后才思考，真不合时代节奏，落伍啊。

　　对Microformat的解释大家可以通过google进行了解，英文强的兄弟可以直接访问Microformats.org了解和学习，中文资料方面比较零散和缺乏，我也没什么好建议。

　　文字没有实例直观，就像文档没有设计稿直观一样。那么现在我们先直接来看一个实例：将“<cite>Dr. John Philip Paul Stevenson, Jr., M.D., A.C.P.<cite>”格式化为hCard Microformat。

格式化后的结果是：
<cite class="fn n">
    <span class="honorific-prefix">Dr.</span>
    <span class="given-name">John</span>
    <span class="additional-name">Philip</span>
    <span class="additional-name">Paul</span>
    <span class="family-name">Stevenson</span>,
    <span class="honorific-suffix">Jr.</span>,
    <span class="honorific-suffix">M.D.</span>,
    <span class="honorific-suffix">A.C.P.</span>
</cite>

　　怎么样？感受如何？我的第一个反应，第二个反应……反应无数次后就是放在现在仍然是两个字：夸张。至于嘛，一句话用这么多的标签来格式化，每个都有 class，每个class都很大方，长长的。当然这里我例举了一个比较极端的实例（晕人的专例^_^）。其实Microformat在大多数情况下相对而言代码上是没那么冗余的。下面我们来看另外一个不极端的Microformat。

　　这是常规的一个页脚呈现，来自http://microformatique.com/：
© 2007 John Allsopp | Thanks, WordPress | Barthelme theme by Scott Allan Wallick | Standards compliant XHTML & CSS | RSS: Posts & Comments
在这个页脚里面有两个微格式：

1、John Allsopp
<span class="vcard">
    <a class="url fn n" href="http://westciv.com">
        <span class="given-name">John</span>
        <span class="family-name">Allsopp</span>
    </a>
</span>

2、Scott和上面类似我就不写了。

　　我加粗部分就是为了微格式化而必要的代码，这么一看好像也不怎么常规，如果不使用微格式，同样的表现只需要短短的<a href="http://westciv.com">John Allsopp</a>就可以完成。看起来冗余代码依旧很多，那么是否冗余呢？其实这也是我一直迷惑的。其实我也一直在试图说服自己和他人包括现在的读者你：这是有用的。但是……这个这个先暂且放下。

　　为什么要这么做，增加这么多的标记？Microformat曰：语义化、API。通过这种方式申明数据的语义，形成API，将数据开放出来。问题又来了，需要吗不需要吗需要吗？研究研究？我相信未来的互联网，语义网一定是开放的互联网，不会像现在这样数据无法畅通无阻，存在大量的信息孤岛和信息盲点。但是我们不在明天我们在今天啊，今天需要吗不需要吗需要吗？……靠，不研究了还是先暂且放下。

　　好吧，增加了这么多代码，好处在哪里？给我一个应用实例。Microformat曰：firefox的Operator插件。耐着性子下载下来，再打开http://microformatique.com/，Operator 工具栏上的Export Contact有了数字“3”，他识别出了页面上的3个hCard，选择John Allsopp，Operate提示Outlook打开或下载，下载下来一个hCard.vcf文件，vcf是一种通用的电子名片文件格式。可以被导入各种识别该格式的设备（如手机）和软件（如Outlook）中。打开这个hCard.vcf文件，看见如下代码：

BEGIN:VCARD
PRODID:
SOURCE:http://microformatique.com/?p=160
NAME:microformatique - a blog about microformats and data at the edges : some finer points of hCard and n optimization
VERSION:3.0
N;CHARSET=UTF-8:Allsopp;John;;;
FN;CHARSET=UTF-8:John Allsopp
UID:
URL:http://westciv.com/
END:VCARD

　　我加粗的地方是可以从页面中获取的数据，而其他部分是Operator按.vcf标准对数据进行的转换，可不可以这么理解呢：Operate充当了 xsl的角色，将“xml”转为“xhtml”，将一种标准转为另一种标准。这么一看，要实现这种转换确实需要添加代码申明每个数据的语义，否则无法使得程序读懂数据从而匹配的进行转换。

　　好了，有所理解了，也对为此增加的额外的、大量的标记有了理论上的认可……可是但是以及But，理论终究是理论，放到实践中，根本没有多大的意义嘛！

   1. 目前支持microformat只有Firefox的Operator插件。
   2. Firefox市场占有率对于中国，即便它在发展壮大，还是奇低。平均高估一下：FF占有率10%吧。
   3. 使用Firefox的人群能有几个人知道Operator？连我都一直不知道，更不要说其他人了，更不要说人民群众了。再平均高估一下：1%吧（100个Firefox中有1个装了Operator）
   4. 装了Operator的人已经处于领域浪尖了，好了，有几个人真正在使用，而不是看着Operator上出现的识别数字YY？坦白的说，我装了 Operator后，行为上属于后者，纯粹YY。去导出hCard？然后干嘛呢？我疯了，我有病！……继续高估：1%（100个安装了Operator的人中有1个人在真正使用）
   5. 好了，你突破了上述种种关卡，成为了浪尖上冒泡的水花，精英中中奖的英雄，骄傲吧……请问你访问100次网站，能用几次？你雄心壮志的以为中奖，结果是什么都没有，安全期……TT，最后的结局是：1%。

　　计算计算：10%×1%×1%×1%等于多少？千万分之一！！！那个使用microformat的家伙、用户，是千万分之一的恐龙人。为了这千万分之一的应用可能，我们有必要去学习和应用吗？我们这些打工仔们跳槽的机率，几个数量级的高于我们应用的microformat被用户所使用。……

　　什么是梦想，什么是现实，什么是梦想照不进现实，诠译得多么准确。microformat……

　　开门见了山，横在路中间……登还是绕？

爆牙齿
2008 08 11

[ 本帖最后由 blank 于 2008-8-11 10:12 编辑 ]

分离：程序员请“远离”Web标准

　　分离，这个美丽的词，自从Web标准出现后，便梦萦魂牵的围绕着我，吞噬着我的脑细胞，一百遍啊一百遍。

　　《理解表现与结构相分离》，多么古老的文章；分离，多么诱人的词语！作为Web标准的核心理念，理论上是那么的干净，透彻与清晰，可为何放到实际操作中却那么的棘手和困难？直到四年后的今天，我仍挣扎于其中。

　　我第一次真正以团队角度去尝试分离是06年《重构之美》发表完后，我开始以结构化的理念去实施。结果是我基本成功的分离了原本纠缠在一起的前端和后端，但是在前端却没有完成分离，甚至一度我成为了团队的一个瓶颈，因为虽然我解放了后端，却没能让解放出来的大量工作协调的分配给前端的每个人，我只能一个人扛着，我分不出去，06年下半年，我几乎天天0点离开公司，每天12到14小时的工作。那时廷廷对我反复说的两个字是：放下！叫我不要把所有的事都揽到自己手上，哪有下属准点下班双休，而主管天天熬夜还包括周末的。我一脸沮丧的望着他：我分不出去……放下的前提是拿起，我没有拿起，我就没有资格放下，我也放不下。所以我必须先奋力去拿起。

　　前端和后端的分离相对而言是最容易的，只要后端放弃对结构的编写即可做到，其实在这最容易的一点分离上我也走了一年的弯路。通常而言，一个大团队，后端的人数远远高于前端，不少公司在前端的定义上仅仅限于界面设计，而交互、结构甚至样式其实都放在了后端上，由程序员完成。因此我曾理想的希望每个程序员都能够熟悉Web标准的理念，能够统一思想写出标准化甚至相同的结构，这样可以将结构的编写由众多程序员来平均分担，避免压力全部集中在前端。但是半年多的几次尝试过后我放弃了，首先编写一份合理的结构所需要的附加能力，都是程序员不应该投入精力的前端工作，其次结构的编写是个仁者见仁、智者见智的工作，想统一每个人的思想，何其难！而当我放弃后，当程序员不再参与对结构的编写后，前端和后端的工作就清晰的分离了。这里要特别强调，后端放弃对结构的编写是指每一个标签的确定都不参与。这对一些控件形式开发是个打击，比如 asp.net的一些控件，如果前端确定的结构是“<div>数据</div>”，后端这么操作 “<div><asp:label /></div>”那么就错了，因为最终输出的是“<div><span>数据< /span></div>”。

　　博客园里大部分都是程序员，实际上普遍来说，程序员也远远高于设计师，看我的文章很多都是程序员，听到我说放弃对结构的设计也许会有抵触，尤其是一些不错的程序员。我想一些工作了三、五年的程序员在前端上的造诣或许不亚于甚至高于工作了一、两年的设计师，即便这样，我建议你要做得最好是指导而不是代替。其实真正优秀的程序员会很准确的找到自己的位置，会很清楚自己的光芒在哪里或将在哪里才是最耀眼的。

　　说到这里我突然想到也许会产生一个混淆，然后特意去百度“Web标准 程序员”，出现一篇广为传播的文章《网站程序员如何应对web标准》。然后我再次发现不可思议的文章：《为什么ASP.NET程序员应该学习Web标准》，好像还是翻译的，国外的文章。

　　在第一篇文章中，举了一个例：

    <asp:Repeater ID="topNewsList" runat="server" >
    　　<HeaderTemplate>
    　　<ul>
    　　</HeaderTemplate>
    　　<ItemTemplate>
    　　<li><a href="shownews.asp?id=<%#Container.DataItem("id")%>"><%#Container.DataItem("title")%></a></li>
    　　</ItemTemplate>
    　　<FooterTemplate>
    　　</ul>
    　　</FooterTemplate>
    </asp:Repeater>

　　它说这部分代码，由“页面设计师”也就是表示层的程序员完成，这实际上是程序员参与了结构的设计，确定了ul、li、a，我觉得这是错误，而且从某种意义上来说很严重。首先必须区分一下，程序员和设计师的界限在哪里？前端也有编程开发一说，那么和后端的编程开发区分在哪里？再宏观点，什么是前端？什么是后端？这条三八线应该怎么划？

　　什么是程序员？数据层的开发是程序员，还有通用层，业务逻辑层，表示层。表示层算不算程序员？算前端还是后端？js随着ajax新生，也会和数据频繁打交道，交互开发是不是程序员？又算前端还是后端？写代码的开发就是程序员吗？程序员就代表后端吗？那么结构的设计也是写代码，样式的设计也是写代码，都算程序员都算后端罗？除了界面设计，都是开发都是程序员都是后端罗？最搞笑的是很多人不说自己在做样式设计、交互设计而要说成样式开发、交互开发，甚至还有结构开发，我琢磨着剩下孤零零的界面设计，哪天不爽了跳出来高呼一声“还有我界面开发”，似乎顶着“开发”二字，脚不弯了，腰也直了，鸡胸也挺起来了……凸-.-凸

　　实际上设计师、程序员、设计、开发都是文字忽悠游戏，无所谓。但是前端和后端是应该有分界线的，而这条三八线，我认为：以操作方式来划分。凡是不需要环境可以静态完成设计、开发与调试的工作是前端。而需要运行环境、编译、数据库等必须动态化才能完成设计、开发与调试的工作是后端。所以大部分交互开发虽然也是编程也会操作数据库，但是它还是属于前端，而表示层的开发属于后端。“程序员”这三个字通常更多的是泛指后端。那么在上面的实例中，就应该这样：由前端确定用ul还是ol还是div等，后端要做的是动态化页面（加入数据并循环）。用什么方式实现数据的载入（Repeater控件还是其他）不关前端的事，而用什么结构标签格式化数据不关后端的事！不要说后端了，这甚至不关位于前端的交互开发的事，交互开发无论从协同考虑上、性能考虑上、维护考虑上都需要尽可能的避免创建结构，更不应该擅自创建结构。

　　上面两篇以及类似的一些文章，我认为最大的错误就是没有立足于团队的角度去明确区分前端和后端，混为一谈。简单说说在这点上我的经历和态度转变：2006年上半年我对方欣几十个程序员做Web标准培训，那时我是完全希望结构由程序员编写，结果完败；2006年下半年我在卡当，我再次提出全体培训，被拒绝后开始以边开发边沟通的方式将Web标准理念分散渗透和传递，那时我虽然仍抱希望，却已经有所怀疑，因为我发现结构本来是简单的东西，但是一旦多人带着仁者见仁智者见智的心态去操作时，它就变得复杂难控，于是我开始抓结构的决定权，结果成功了；2007年在爆米花，我开始常说一句话：“不管你用什么方式，控件或编程或其他我听不懂的，反正我只要最终输出的页面，在浏览器中查看源代码，其结构和前端确定下来的完全保持一致，丝毫不差，就OK，剩下的事属于前端，你可以不管了。”程序员可以建议或提出障碍，但是结构的决定权100%的落在前端，我完全的放弃了对程序员的主动培训，结果轻松而极速。

　　那么，程序员是否需要学习Web标准呢？这个问题换个角度，就是问：设计师需要学习数据库吗？答案其实是一样的：需要。但是这种学习我觉得应该是属于了解的学习，而不是钻研，是辅助的学习，而不是主导。为什么？因为首先确定结构需要深厚的CSS设计能力作为支持。两年前我写过一篇《CSS,Stop!》的文章来提醒大家关注结构，很快我就想再写一篇《CSS, Important!》的文章来阐述结构和样式的关系，因为通过后来那道面试题我发现，CSS的设计能力在很大程度上影响和限制着你的结构设计能力，如果你CSS水平不够你根本不敢去选择更好的结构哪怕你知道（比如你如果不知道如何清除浮动，势必要加入冗余标签）。其次，CSS和界面设计又是密切相关的（比如圆角的变通灵活实现或图片切割的针对性设计），和交互设计也有瓜葛，而最后界面设计与交互设计源于产品设计。这条线就牵出了前端两个字。如果程序员编写结构，就要学习CSS，然后被莫名其妙稀奇古怪的浏览器兼容打懵掉，还得纠缠进界面艺术及排版设计……一步一坑，越走越不熟悉障碍也就越大，水深火热，最后导致的结果便是团队无法形成专业的前端队伍，也无法形成专业的后端队伍，人人在执行上身兼数职，单兵作战，更不要说协同了。这无论对团队还是对个人都是糟糕的：团队是混乱的散沙，个人是平庸的全面。

　　程序员可以学习Web标准，如果自我感觉很好，可以建议甚至强烈建议，但是不要去替代去操作。术业专攻，博览群晓。前一句指在执行上专一，后一句指在认知上全面。其实我认为如果你决心投身于后端做个牛逼的程序员，完全可以不用在实践中去刻意学习Web标准，学习方式很多，沟通协同中也能学习和了解很多，足矣。而执行上的做与不做，对于个人没影响，一个人可以从头做到尾，但是对于团队这个问题很重要，非常重要！你必须认识到一点，全能是幻象，没有在执行上既精于前端也精于后端的人，因为时间和精力是有限的，你必须放弃，让自己有短处，你才可能拥有傲人的长处。当然我知道还有客观环境在左右程序员的行为，是公司没有建立前端队伍而导致程序员不得不去扛起前端的工作，这是很无奈的事情。所以众多网站强在后端弱在前端，怎么可能不弱嘛，前端的工作由后端程序员兼任，想起一句话：“抢劫，咱不专业啊。”再说下去就是前后人才问题了，不说了。

　　差不多说完了，我想有人会说：“你在说大团队，我们是小团队人少，不可能分得那么细。”其实无论3、5个人的小队还是30、50个人的大队都可以并应该把前后端分离开来。这个东西，和人多人少没关系，人少你都分不清，人多了就只会更混乱。

　　所以，分离的第一步：程序员们，珍爱生命，“远离”标准；CTO们，珍爱程序员，分离前后端。


爆牙齿
2008 08 20

[ 本帖最后由 blank 于 2008-8-20 09:30 编辑 ]

分离：通用也许是个美丽陷阱

　　这段时间超级繁忙，文章断了一个多月了，不好意思。

　　当程序员完全放弃对结构的编写与确定，高呼万岁，解脱了。真的，我发现我经过的程序员没有一个不是超爱Web标准，能不爱吗？我告诉他们再也不用写 html，不用写css，不用写js，最多最烦人最招惹领导的界面问题都与你们无关。（我说句悄悄话：不要看现在每个公司后端“程序员”一堆一堆，我敢说对于其中不少人，像我这样把html/css/js部分从他们手中一抽走，基本就废了他们，他们剩下没多少可做的工作了。唉，别说他们，后来我把自个儿也废了，因为我速度太快了，后面慢聊……）

　　我是要说什么来着？哦，我要说得是程序员万岁了，但压力并不会凭空的消失，而是转移了，本来由大量程序员分担的工作便集中压到往往人单力薄的前端，前端的一系列问题就出来了，那就是设计、结构、样式、行为之间以及其自身的分离。这个分离相当困难，因为这几个东西太缠绵了，千丝万缕的纠缠。实际上，至今我仍在努力梳理，所以我只能在我的能力范围、认知范围和实践范围内说说看。

　　我曾在卡当顶着大量工作成为前端瓶颈，我后来一直在反思：为什么？怎么会这样？web标准错了吗？我开始抛开无法回避的客观因素，从主观上自身上去找答案。web标准，我还是信任的。

　　我当时的工作有哪些？管理和前后协调上的工作就不说了，说说前端技术上。首先我要做设计，因为那时能设计的人都不懂Web标准甚至不懂table，我自然否定他们的设计，因为传统的表格拼图设计思路会给制作带来麻烦，尤其是当时崭新的结构化思路非常需要设计的支持；其次我要做结构，这没啥说的，在结构上的理解与运用没人比我强；最后我还得做样式，由于我从那时开始就追求自创的独立于根的写法，而且狂热的恋上这种我认为最精简最漂亮能最大限度摆脱布局思路的结构，而这需要无比的耐心和深厚的css功底作为支撑，否则难以去除冗余结构也难以还原设计稿……

　　这样，为了避开层层的障碍做得更好，自己理想中的完美，我不自觉的把所有工作都集到了我一个人身上，使其他人很难介入进来，只能走在边缘。随着产品越来越复杂，恶性循环下我就陷得越来越深，不但我得陷在开发中，还得陷在维护中，出了什么bug，不管何时我必须在场，否则无法解决，我手机为QA开着，随时响应他们的召唤。在后来的反思中，我认为陷进去的原因之一就是：通用。

　　可能这一说，是会被开发砍脑袋的。因为“编写一次，畅通无阻”，是开发至上追求，大家都讨厌重复劳动，讨厌苦力活，觉得这些都没有价值，不值得做，通用了，就能节省自己的时间，他人的时间。程序编写我不熟悉，我这里单说前端，更具体的是特指css。

　　css的诞生就是为了统一控制，最初我们就知道使用css来统一全站字体、字体色彩、行距等表现性的东西。多方便啊，维护的时候改一个地方，全站都变了。使用css后给人的第一个感觉就是通用。后来web标准来了，css的控制能力和范围在前端得到了几近无限的放大。我们发现通过css不仅仅可以控制颜色，还能控制布局。那么能使颜色通用，思路自然而然的无缝转嫁：统一控制布局。这是在我脑子里曾长久主导的设计思路和设计方向。我追求着通用，在卡当做到了当时个人能力下的极致甚至写过类似如此变态的css：
xxx div{float:left;}——一个css中。
xxx div div{float:none}——另一个css中。
xxx div div div{float:right;}。——再一个css中。
可能光看这部分代码你会觉得很狗屁，呵呵。也许你会说：“不是通用的错，是你做得不好。”完全是这样的吗？

　　2006年9月，正好两年前，在我围着通用上扑下扑，鸡飞狗跳的折腾过程中，CTO郑文军和我有一次交流，在多次的常规交流中唯这次让我记忆犹新。当时我炫耀着目前的前端多么多么的畅通，要变什么改一个小地方全变，要个性化什么通过css的优先级处理覆盖掉通用定义就行了，当然实际上我是焦头烂额的，忽悠领导呗是吧……文军看了看说：“嗯，不错嘛。”我正为忽悠成功而暗自开心。他话锋一转：“但是我觉得你不应该做得这么通用，有些地方即便能通用你也不应该让它通用，你要允许冗余的存在，允许看起来很讨厌的东西残留在系统中。”这可把我反忽悠了，可以说我把通用处理得不够好，但是能够通用为什么不通用，冗余的存在意味着无意义的重复劳动，无谓的多余时间消耗。我能节省我的时间，为什么不呢？是吧，Why not! 一抹袖子，办公室里，One、Two、Three, Fight!……

　　最后他说：“我们先把技术搁下好不好，不谈技术。换个角度来看，现在要做一件事情，比如我们一个新版本要上，包含很多内容很多模块很多面要处理，上线时间是3天后，铁板钉钉是不允许变的，钱不是问题，但时间晚一秒都不行。而我们现在的人力是肯定做不到的，就比如你前端，你要多少人我都给你，但是3天后必须完成，你可以吗？你做得越通用，对新人而言学习成本越高，无法迅速的开始。……”

　　我当时立刻就有一种醍湖灌顶的感觉，我解决问题处理问题的思路确实局限在了技术这个范围，没有跳出来，不够宏观。所谓的节省精力和时间局限在了一个小范围，甚至只是自己，而实际上我心知肚明的清楚，我自己也并没有省心反而更加烦心。

　　也许程序上的通用是有很大价值的，因为功能的需求变动和扩展通常不会很大和频繁，但是在过于直观的界面设计上，变动是频繁的。很简单嘛，boss通常看不到也看不懂程序，但是界面谁不会看呢？也能很方便的发表意见，甚至路过你身边冒一句：“把这个挪到这边，把那个挪到这里，这个图片不要了，那个角弯一下。”冒完泡后，大摇大摆的带着指点江山的成就感离开，也不会觉得有什么麻烦。只剩下你对着屏幕的反光，大眼瞪小眼，还得提防他啥时候再次路过，然后把之前说的话反着说一次。

　　这样的变动，对于界面设计来说虽然烦，但是这种烦不是因为实施，在PS/FW里拖来拖去的实施并不麻烦，抵触主要源于心烦（老子觉得这样好看，老子专业，凭什么改？）但是对于之后的css设计，实施就是灾难了。css不是银弹，特别是在处理布局上。我们设想也实施过各种各样的css文件：处理字体的，处理颜色的，处理模块的，处理布局的……这样的细分就是在分离，目的是通用。程序之所以相对而言能够去通用，我觉得因为功能之间能够通过定接口基本做到分开。一个优秀的程序员和一个差劲的程序员，无论谁上谁下，只通过接口握手，不会因为不同的编码习惯、风格、优雅度而相互影响。但是css不行，它没有接口，不管你细分了多少模块，最终css面对的是一份混在一起的，整合的html。这种情况下，如果由不同的人来完成不同模块，再组合起来，css间就会冲突，因为布局总是相关的，有时这种冲突会非常激烈。当然我们可以通过优先级去解决，这就是覆盖操作，分离程度越高，覆盖操作越多，而分离层次越多，当你面对一个新页面的时候，你越迷惑：到底以前在这个标签上定义了哪些样式我需要去清除或覆盖。我曾经在这上面陷得很深，我自己都记不得我需要处理哪些我曾定义过的东西，翻箱倒柜的寻找……

　　问题还不仅仅出在开发过程中，维护时也是。分离后，通用后，引一发而动全身是其优势，同时也是其劣势！随着项目的壮大，页面越来越多，而人员变更，使得后续的css设计五花八门，这个时候，分离出来的通用样式就越来越难以更改，因为你不知道引这一发，全身会怎样的抖动，也许左手很正常，而右手在抽羊癫疯。也许全身很正常，但某一处血管已经断了（因为样式问题而导致功能失效不是低概率），于是你不敢轻举妄动，恶性循环后，通用的这些css慢慢就成为沉重的历史包袱压着后续开发。如何查找？就像在超长代码中去寻找一个未关闭的标签或忘写的“;”一样困难，而且你还得首先确诊问题的根本是有个未关闭的标签或“;”。曾经我们上线一个版本后出现严重bug，前后所有相关人力在追查了整整两天后才发现，是程序员套结构时一个未关闭的标签导致。虽然只是一个小问题，习惯问题，却引发了高度重视，甚至大家产生对web标准的怀疑，因为风险太大。（唉，你们不知道我当时的苦啊，有一次我发现程序员居然一个页面少关闭了近10个标签……这还是我写他套……）

　　我要说的是，从那次交流后，我就开始很慎重的对待样式的通用和分离。尽可能少的分离，尽可能少的通用定义，除了兼容尽可能少的进行覆盖，尽可能的回避!important，目的是为了使自己，使他人在面对新页面时不要背着难以卸掉的、沉重的历史包袱。我们知道对待一个页面写样式最快最爽的办法就是面对一个完全无样式的页面，不仅如此，干净的页面对界面设计的宽容度也是最大的。前端是什么，UI和UE，是用户界面和用户体验，界面源于设计，体验源于交互。css不是主角，它是配角，在设计和交互间是穿针引线的作用，css需要做的是尽可能的不限制。而 css的高通用、高分离，我认为就是喧宾夺主，对设计和交互构成了限制。

　　从2007年开始，我写CSS就基本上为一个public.css+"page".css，页面链接"page".css，而"page".css 中对public进行import，并且尽可能少的定义public，把控制权尽可能多的交给"page".css。"page".css得到了更多的控制权就意味着"page"的界面设计得到了来自css更少的限制。目的就是让css之间的牵连更少，而操作更自由。自由当然需要代价，那就是各个page 的css会存在冗余，会在开发时产生重复劳动，但我觉得对于css来说，最重要的还是自由。少了分离少了通用，无论人员变更还是水平高低，都能迅速的参与到项目中来，而不是先啃一套css规范，如果公司一换，屁用没有，又得重新啃新的规范。我float用得比你的position还好，我为啥要遵循你的 position规范呢？我想很多人都不会乐意去修改别人的css，因为很难理清别人的思路，padding-top只是padding-top吗？它很可能是页面的布局重点。我相信每个人在接手他人工作的时候最乐意的就是按自己的方式来，哪怕全新开始也会很快。那么好，你现在把他的"page".css 内容删了重写，页面干干净净，自己搞吧，如果赶时间，极端点，你甚至不用了解和导入public.css。而你写的"page".css并不会被其他页面引用，写得再烂，也不会破坏整体。或许会有人拿面目全非的改版说事，别异想天开只动css，通常来说，面目全非的改版改的是需求，需求一大变，css？直接del吧。不要一说起css的灵活就把轻松改版挂在口中，你做到过吗？css的灵活是体现在开发、维护的过程中各个细微之处，在大量的细节问题处理上节约时间并推进进度，而不是面对整体。如果非要把css拔升到全局控制的高度，会是灾难。再重申一次：css不是银弹。

　　最后一个必须提的，是组件化。如果说我的左手是反对，右手是支持，从2004年开始，面对组件化操作css的做法，我左手就没放下来过，很简单：组件化操作css是更高的通用和更高的分离。前段时间我们在讨论片段化的时候我也是反对将css纳入其中，哪怕最终能自动合并而不必担心文件数的问题。因为，需要给予千变万化、动荡不安的前端更多的宽容和自由。还有一个原因，我会在下篇中讲到。

　　分离的第二步：减少分离，降低通用，解放css。

爆牙齿
2008 9 23

[ 本帖最后由 blank 于 2008-9-23 10:20 编辑 ]

安心坐下

还是惶恐

再次起立

依旧没有

放松坐下

有点疲倦

昏昏睡去

来了，静候佳作。

恭候爆牙齿多时了。欢迎回来......

ps。我不看好html5，我看好xhtml2。因为我喜欢严谨的作风，不喜欢有容乃大的做法。

占个座位.!
  期待........

帖子含量很高,楼主很懂标准,期待下一部!!!

很不错，真的很不容易

站位等着...

此乃记号

期待爆牙齿的大作……

LZ甚好甚强巨，第一页全被他占了

有些想法，期待分享完整經驗

期待非废话

爆牙齿大名早有耳闻啊

好像是沉默一段时间了，aoao也不见了。人都咋了...

一口气看完这篇“废话”，多好的“废话”呀，对我的启发很大，出书吧。你行的。

期待...