加权平均分(WR) = (v ÷ (v+m)) × R + (m ÷ (v+m)) × C
在这里：
R = 该电影的平均分
v = 该电影的总投票数
m = 列入前250所需要的最少票数(目前是1300票)
C = 数据库中所有电影的总平均分(目前是6.7)

哈哈，厉害吧，投票数多的话，那么R，也就是每个人的电影评分就起到主要作用；
如果投票数少呢，也不能说电影不好，小众的东西还往往是精品呢，文化的东西，毕竟有可能因为语言等因素，或者曲高和寡变得在IMDB上变得小众，这样如果投票数少，那么也不能一棒子打死，就趋于平均水平。
如果票数相同呢，那么就看R了，平均分越高，那么自然排名就越靠前啦。

好玩吧，再看一个。

很多网站在设计博客的排行时，在时间相关性上很困惑，为了满足访问网站频率不同的用户需求，他们只好按日、周、月来做排行，非常明显的缺陷是，让每周或每月的开始时，周榜和月榜上的精彩文章精彩程度不够，而上周末或月末的精彩文章可能被过早撤出用户视线。但是如果按七天排行或者三十天排行，算法又太复杂。
有没有兼顾的算法呢？答案是有的。


假定用户访问周期介于T1到TN，TN=N*T1，用户访问频率在T1到TN之间线性分布。
设文章在每个时间TX里获得的访问量为TXPV，设计系数A=(N-1)/N

使用计算式
T1PV*A^(N-1)+T2PV*A^(N-2)+T3PV*A^(N-3)+……+TNPV=∑TXPV*A^(N-X)
来计算随时间衰减的关注度。
太TMD牛了，佩服的五体投地。
如果算周排行榜，一篇文章在第一天的访问量跟第七天的访问量在权重上明显是不同的，到第七天还有人在访问，那就说明这篇文章更热。

通过这件事情我想，作为一个产品经理，其实应该有这样的基本功力。今天大家在研究热文的的出现和排序算法的时候，我为自己是个理科生感到非常惭愧，对于分析一种算法的改变对于效果的影响上，我表现得跟个文科生一样。倒也不是说文科生同学们就干不了这个事儿，只是说我这么多年的专业训练啊，都tmd练到哪儿去啦？？！！

作为一个将致力于成为一个有创意的、脚踏实地的、有执行力的、成熟的、经验丰富的、牛B哄哄的产品经理作为毕生奋斗目标的人，我今天的体会是一定要严于律己，有意识的培养自己对于算法的感觉，积极参与工程师同志们的算法讨论，不断修炼，逐渐成仙。

jQuery 由 John Resig 创建于 2006 年初，对于任何使用 JavaScript 代码的程序员来说，它是一个非常有用的 JavaScript 库。无论您是刚刚接触 JavaScript 语言，并且希望获得一个能解决文档对象模型（Document Object Model，DOM）脚本和 Ajax 开发中一些复杂问题的库，还是作为一个厌倦了 DOM 脚本和 Ajax 开发中无聊的重复工作的资深 JavaScript 专家，jQuery 都会是您的首选。

jQuery 能帮助您保证代码简洁易读。您再也不必编写大堆重复的循环代码和 DOM 脚本库调用了。使用 jQuery，您可以把握问题的要点，并使用尽可能最少的代码实现您想要的功能。

毫无疑问，jQuery 的原理是独一无二的：它的目的就是保证代码简洁并可重用。当您理解并体会这一原理后，便可以开始学习本教程了，看看 jQuery 对我们的编程方式有多少改进吧。

一些简单的代码简化

下面是一个简单示例，它说明了 jQuery 对代码的影响。要执行一些真正简单和常见的任务，比方说为页面的某一区域中的每个链接附加一个单击（click）事件，您可以使用纯 JavaScript 代码和 DOM 脚本来实现，如 清单 1 所示。

清单 1. 没有使用 jQuery 的 DOM 脚本

var external_links = document.getElementById('external_links');
var links = external_links.getElementsByTagName('a');
for (var i=0;i < links.length;i++) {
var link = links.item(i);
link.onclick = function() {
return confirm('You are going to visit: ' + this.href);
};
}

清单 2 显示了使用 jQuery 实现的相同的功能。

清单 2. 使用了 jQuery 的 DOM 脚本

$('#external_links a').click(function() {
return confirm('You are going to visit: ' + this.href);
});


是不是很神奇？ 使用 jQuery，您可以把握问题的要点，只让代码实现您想要的功能，而省去了一些繁琐的过程。无需对元素进行循环，click() 函数将完成这些操作。同样也不需要进行多个 DOM 脚本调用。您只需要使用一个简短的字符串对所需的元素进行定义即可。

理解这一代码的工作原理可能会有一点复杂。首先，我们使用了 $() 函数 —— jQuery 中功能最强大的函数。通常，我们都是使用这个函数从文档中选择元素。在本例中，一个包含有一些层叠样式表（Cascading Style Sheet，CSS）语法的字符串被传递给函数，然后 jQuery 尽可能高效地把这些元素找出来。

如果您具备 CSS 选择器的基本知识，那么应该很熟悉这些语法。在 清单 2 中，#external_links 用于检索 id 为 external_links 的元素。a 后的空格表示 jQuery 需要检索 external_links 元素中的所有 元素。用英语说起来非常绕口，甚至在 DOM 脚本中也是这样，但是在 CSS 中这再简单不过了

• jQuery：访问 jQuery 主页并下载源代码。
• 选择器：获取在 jQuery 中可以使用的选择器的完整列表，包括 CSS3 和 XPath 选择器。
• jQuery 插件：获取可以使用的 jQuery 插件的完整列表。
• Interface：尝试使用 jQuery 最基本的插件，可用于动画、显示效果、拖放功能和用户界面（UI）。
• Form 插件：获取 jQuery 插件，它可用于使用 Ajax 提交表单。

页面首次访问时的延时是网站和Web应用设计中遇到的一个很重要的问题。用户总是感觉页面相应的不够快。
为什么用户会有这样的感觉？也许用户还保留多年前那种按分钟计费的接入网方式的使用习惯（现在的饭店或机场还保持那种接入方式）；也许是因为用户觉得页面要有足够快的响应才能称得上所谓的信息高速路。但在我看来这是好莱坞的责任。在每部好莱坞的动作大片中：敲击一下键盘的同时，电脑屏幕上就会出现超高分辨率，有着密密麻麻数据显示的精美网站操作界面；而且网站上读取一部百科全书也不过短短几毫秒就可以完成。
但在现实生活中却完全不是这么回事,因为无论你如何尽量简化你的页面,延迟还是存在的。而且为了使页面更绚丽，通常会使用flash，但如果滥用flash会严重影响页面的响应速度。作为网络应用，还必须保证页面元素的加载顺序，不会因为页面上未完全加载的元素被用户访问而造成异常。

哪些因素造成网站响应缓慢？

当谈到提高网站响应速度，最通常的做法就是尽可能的减少网站文件的尺寸。(这也导致针对JavaScript库文件大小的无休止的讨论，但最终也没什么结果。）实际上,有许多因素会影响到网页初次访问的响应速度:

* HTML文档的大小。
* 页面中嵌入的脚本、图像、多媒体元素文档的大小。
* HTML页面的复杂程度。(浏览器可以很快的展现简单的页面)
* 用户的接入速度
* 会被页面访问的第三方内容所在服务器的访问速度。
* 网站域名及其页面包含的外部域名的ＤＮＳ解析速度。
* 用户计算机的性能。(浏览器会因为系统消耗过多的资源在其他任务上而变得响应缓慢)。
* 服务器的相应速度。

除了以上的技术上的因素会导致网站响应变慢以外，还有一些人为设计上的因素。例如：为了避免页面加载过程中出现的页面区域错乱和无图像显示；页面被设计为需要页面内容完全加载完毕后才一起显示。
让网站响应便快的方法

经过实践，以下经验对于解决由于技术和人为因素造成网站响应变慢的问题会有所帮助。

* 在不影响页面显示质量的前提下，尽可能的优化HTML代码。（这包括在发布页面时，去掉HTML文档中的注释以及冗余的换行标记。但为了保证页面的可读性，这些代码还应当保留在源代码中）
* 页面中尽可能少的包含其他外部引用，减少文档之间的依赖。（可以将多个脚本放入一个脚本文件，用CSS的sprite技巧将多个小图片合并为一个大图，这样就只需要加载一次）
* 确保你没有从外部服务器上引用第三方的内容：用一个脚本将远程的RSS源缓存在本地。这样不仅可以避免DNS解析所造成的延时，而且也不会因为外部服务器的宕机影响你的服务。
* 尽可能的制定图片及包含图片的元素的尺寸。这样可以避免页面展现时由于图片陆续加载而造成页面元素跳动的现象。
* 在页面的末端加载大的脚本，这样页面的可以在大的脚本加载完成前展示出来。如果把大的脚本在页面头元素中加载，则浏览器会等到脚本完全加载完成后才显示页面内容。

web开发准则与提高响应速度

可惜上文提到的这些计巧与我们通常认为的web开发的准则有冲突。例如减少页面包含文件数量会造成产品的可维护性变差。为了使网站的不用页面（首页，文章页，存档页）保持不同的页面风格最简单的方法是不同类型的页面的特殊的样式存放在他们各自的样式文件中。一个页面可以有一个最基本的样式文件，然后根据页面的不同类型再包含该类型页面的指定的样式文件。
脚本的存放也可以用相同的方法，将功能相近的脚本放到一个文件中。这样有助于代码的维护。你不用察看所有的脚本代码就可以很快的找到你需要的函数。此外，将脚本加入到页面的主体部分通常被认为是不良的编码习惯，因为他将用户的行为控制逻辑嵌入的页面的结构中。

幸好有技术方案可以解决这些问题。

用一个包含来引用多个样式或脚本。

爱德华艾略特提出的解决方法是用一个PHP的脚本将多个CSS样式或脚本整理成单一的档案。这个脚本对于javascript还可以调用DouglasCrockford’s的JSmin进行压缩。这个脚本使用很简单，而且可以缓存归并后的文件，直到这些被归并的文件被修改。这就意味着当你修改被归并的某个文件后，脚本会自动重新打包缓存。这样就很简单的解决了代码维护和页面响应速度间的矛盾。
解决页面加载的问题

另一个棘手的问题是，嵌入在页面头元素的脚本，必要要等页面加载完成后才能被调用。这样就会有些延时 ，而且还会产生问题。

延时是由于浏览器加载，解析和展现文档的方式造成的。当你用window的onload事件加载脚本时，浏览器的处理顺序是这样的：

* 解析HTML代码装载外部脚本和样式表
* 执行被解析后的脚本
* 建立HTML的DOM树
* 装载图片和其它外部引用内容
* 页面装载完毕

在大多数情况下这样的加载会比较慢，而有些步骤需要提前。许多聪明的程序员致力于解决这个问题，不时的会有新的解决方案出现。大多数的javascript脚本都会有针对onAvailable或onDocumentReady的事件处理。这类事件会在部分文档装载完成后就会被触发，而不用等到大量图片被加载。但通过实践和反复测试，针对旧的浏览器和操作系统并没有无懈可击的解决方案。但我相信只要我们继续努力，再加上那么点运气一定会找到最终的解决方案的。

对于web应用由于调用未加载完成的元素而导致异常是很致命的问题。如果这类问题时发生在页面美化部分，则会有一些解决方法。

为了解决一次加载过多内容的问题，可以采按需分别加载内容。

为了更好的装饰页面一次载入大量的内容，往往会产生问题。大量的内容有可能是每个标签中都包含过多的文字或者是一个有四级的导航栏。运用javacript脚本可以很轻松的动态展示这些内容。但是如果脚本被禁用，则这些动态内容就会失去样式而被打乱，无法正确地展示，这当然不是一个好主意。页面也没有必要一次将所有的动态展示内容都一次加载，这样会增加页面载入的负载。

解决方法是当用户触发标签时再用javascript动态的加载显示的内容。当用户关闭脚本后也会显示一个基本的静态文本。

用什么方法来加载额外的内容取决于你需要引用的是什么。最简单的方法是动态的生成脚本标签。这是一个很早就有的方法，被用来引入大量的javascript数据集或在页面加载后再引入脚本。


function pull(){
var s = document.createElement('script');
s.type = 'text/javascript';
s.src = 'largeJavaScriptBlock.js';
document.getElementsByTagName('head')[0].appendChild(s);
}
window.onload = pull;


del.icio.us页面就到这种方法来引入由json返回的数据。由于json返回的不过是一堆javascript代码，你可以在页面装载完成后，生成javascript脚本标签包含这些代码；然后执行这些代码原来替换页面中某个元素的内容。Dishy作为封装了json的对象可以让你很轻松的完成这些。另一个列子是不太显眼的Flickr头像，Flickr用json输出显示你最新相片，当用户禁用脚本，哪个位置显示的只是一个链接。

如果你要引入的是非javascript的内容，你可以使用Ajax或者AHAH或者Hijax或者其他不包含xml的ajax（你愿意把称作什么名称都可以）。例如，一个用ajax实现的导航，它甚至可以根据用户需要可选择的加载更为复杂的界面。

Imaging trickery 图像显示技巧
最后一个方法的渊源会追溯到可能你还没开始接触网站开发时。那时浏览器大战中最为ie的竞争对手苦命的Netscape（但在我看来那时还是不错的）浏览器支持一个自定义的HTML属性‘lowsrc’，这个属性可以指定一个小图片提前加载作为大图载入时的替代显示图片。这样即使用户的接入速度很慢，也可以看到即将呈现图片的一个预览。
你可以重用这一想法，当页面加载时不要嵌入过大的图片而是载入更为规范化的小图片；等页面加载完成后再用大图片进行替换。你甚至可以简化到开始只载入背景色，然后等页面载入完成再用javascript或者DOM加载原图进行覆盖。
这种方法还适用于你需要从多个服务器取得许多不能被缓存的图片。（例如gravatars）通常可以先载入一个占位的图片，等页面加载完成后再动态取得分散在其他服务器上的小图片。


#layout {overflow:auto; zoom:1;}
<div id="layout">
<div id="left">Left</div>
<div id="right">Right</div>
</div>

使用 :after （非 IE 浏览器）

#layout:after{
display: block;
clear: both; content: "";
visibility:hidden; height: 0;
}
<div id="layout">
<div id="left">Left</div>
<div id="right">Right</div>
</div>

注：使用 :after 需要注意几点，设置高度为零（height: 0;）；content 是必须的，但其值可以为空。

我不想从物理学角度对产品结构元素进行用户体验分析，因为那种分析过于技术化，而是从用户能够感受得到的角度进行分析（做用户体验的原则：坚决做用户感受得到，绝不做用户感受不到的——控制成本的有效办法），把用户体验划分为四步（用户体验四步曲）：

第一步视觉体验。视觉体验是用户对界面设计的第一感官体验。它是完全是用户几乎没有经过思考前的一种视觉感受，如何给用户提供一种近于完美的视觉体验，需要考虑到用户看到界面时可能出现的任何一种感受，这就提出UI设计师需要对目标用户偏爱的准确了解和把握，精确传达需要传达的含义，才会获得预期的效果；视觉体验直接影响到用户是否停留在此页面进行一下步的表达理解。注意：任何一种让用户感官视觉不适的界面都可能导致用户产生怨言和流失。

第二步表达体验。表达体验是用户在视觉体验的基础上对界面内容的理解，界面内容可能是文字，也可能是图案，这些内容是引导用户进行操作的“提示或说明”，是需要用户进行理解的内容，如何给用户提供一种简单直白有趣易懂的表达体验，需要产品设计人员考虑到用户对需要理解的内容可能出现的任何一种理解进行预估，消除一些传达出错误信息的内容，因为这些内容都是单向的表达，没有解释和补充的机会来纠正用户瞬间的理解；表达体验直接影响到用户下一步的操作行为是否合理。注意：任何一种让用户产生误解的表达都可能导致用户产生怨言和流失。

第三步操作体验。操作体验是用户通过对表达内容的理解后做出的行为动作的体验过程。功能逻辑是操作体验的直接影响因素，如何优化用户的操作过程是产品设计人员需要思考的核心问题之一，既需要考虑正常的逻辑，又需要考虑非正常的逻辑形式，尽可能考虑到用户可能出现的任何一种行为方式，才能保证用户进行正确的愉悦的操作过程；操作体验直接影响到用户下一步的内容体验。注意：任何一种繁琐和复杂的操作逻辑都可能导致用户产生怨言和流失。

第四步结果体验。结果体验是用户通过操作行为获得的行为结果的一种体验过程。用户的任何一种操作可能出现的任何一个行为结果都直接影响到用户结果体验。如果通过用户的任何行为来预估用户的准确需求是产品设计人员需要思考的核心问题之一，这就要求涉及好每一种用户行为可能出现的任何一种结果，并预测每一种结果是否能够满足用户的需求，如果不能，如何采用其他方式来满足用户的行为需求。注意：任何一种不能满足用户需求的操作结果都可能导致用户产生怨言和流失。

总结：用户是绝顶聪明的天才，因为他可能发现任何一个细微的不足；用户是傻子，因为任何一个微不足道的细节失误都可能导致用户出现挫败感；每一个细节看起来都微不足道，但是每一个细节的综合就会促使整个产品趋于完美，也许用户只是感动于某个细节，但他接受你一定是认同你的全部！

原文：http://column.iresearch.cn/u/yuxuejun/archives/2008/32363.shtml

现在就来说个淘宝首页上的一个小技巧。

类目之间的横竖线

从很久很久以前开始，类目间的竖线无非都只有三种。

1. 背景图
   在a标签设置一个padding 用宽1px高不等的背景图来position到右侧。
   缺点：最后一个还是要用class来隐藏掉背景。
2. 符号
   在每个a标签之间用”|”符号来填充。
   缺点：html文件变大，文件维护变得很麻烦，而且在html中毫无意义。
3. a标签右侧的boder。
   同背景图一样，只不过使用border-right来代替。缺点也同上。

看到这里，可能已经有人打开淘宝首页用firebug查看源码来看是怎么做了。

其实现有是利用ul的overflow:hidden 再将li的margin-left:-1px的做法做出来的。这样的做法就可以同时避免以上的缺点了。
为什么之前都没有那么做的，寡人也不知道了。难道寡人是第一个发现这样的做法？
不管是谁先此之前利用了这样的方法实现类目间竖线。
不过在淘宝首页上线后不久就有同行的网站在首页改版中也用了这样的方法。
那个网站不看也罢。class实在是写的有点多。加载html会变得多得多。
反正一个首页需要加载1.17m的网页我的大脑会自动屏蔽。

圆角的做法.

为了这个圆角,前段开发们付出的努力是在是太多了.又要考虑http连接数,又要考虑css与html的代码量与语义.
贴出的是最近考虑替换现有圆角做法的方案,可能还有许多未考虑的状况.但是大体的编写方式便是如下.
好处是便于维护,只有一个图片.还可以某种程度上的任意缩放.缺点是多了无意义的html代码.

css：
.c,.c i,.c i i,.c b,.c b b,.c p{
background-image:url(http://pics.taobao.com/bao/album/promotion/uiblog/purple.png);/*背景图片*/
background-repeat:no-repeat;
}
.c{
width:200px;/*临时定的宽度*/
background-position:0 -4px;
}
.c i{
display:block;
height:4px;
}
.c i i{
margin:0 0 0 4px;
background-position:right 0;
}
.c b{
display:block;
height:4px;
background-position:0 bottom;
}
.c b b{
margin:0 0 0 4px;
background-position:right bottom;
}
.c p{
margin:0 0 0 4px;
padding:0 4px 0 0;
background-position:right -4px;
}

caption这个标签在firefox下会有左边有1px空隙的bug,很讨厌.能想到的简单的方法只有-1px的margin了.

css：
table{
border-collapse:collapse;
}
table caption,table td,table th{
border:1px solid #a2bbdd;/*边框颜色*/
background:#c3d9ff;/*背景颜色*/
}
table caption{
text-align:left;
border-bottom:none;
margin-left:-1px;
}

html：
< table>
< caption>表格标题< /caption>
< tr>
< th>标题< /th>
< th>标题< /th>
< th>标题< /th>
< th>标题< /th>
< /tr>
< tr>
< td> 内容< /td>
< td> 内容< /td>
< td> 内容< /td>
< td> 内容< /td>
< /tr>
< /table>

需要正视的二个标签

1. acronym这个标签用来解释名词很爽,但是用得太少.(我也一直想用来着,所以记下了.)
   css：
   acronym{cursor:help}
   html：
   < acronym title=”段正淳又是金庸笔下一个十分奇特的人物。他奇特在到处留情，情人极多，见一个爱一个，而又绝不是徒然风流薄幸，当他是单独对着一个情人的时候，他真是真心真意爱这个情人的，只好说这个人的感情特别丰富，别无其他解释。” >文字< /acronym>
2. ins这个标签忘记是在哪个网站上看到过用来在h2里显示更多的链接,后来查了书,大家都觉得有点欠妥,有点争议.
   css：
   还未写入css组件…欠奉上了
   html：
   
   

   标题更多>>

   标题右侧“更多”的实现

   

   曾经做上图所示的效果,会使用到position来相对定位到h2标签的右侧.这样的做法,代码确实会多好几行. 其实可以用个笨一点的办法来实现的：

   譬如html代码如下：

   < h2>< a h ref=”#” >标题< /a> < span>更多…< /span> < /h2>

   使用potsition的css差不多如下：

   h2{
   position:relative;
   height:20px;
   }
   span{
   position:absolute;
   right:0;
   top:0;
   display:block;
   height:20px;
   }

   这样才能实现更多在右侧.其实真的还可以更简单:

   h2{
height:20px;
}
span{
float:right;
display:block;
margin:-10px 0 0 0;
height:20px;
}

   其实只是利用了margin-top 的负数来实现,因为默认的float会换行到h2标签下面去，所以让它自个跳上去。大致代码就是如此了,是不是很简单?我说很简单嘛！由于很简单,所以就不放出单独的测试页面了.

   ps:我说咱们啥时候也得搞个和蓝色理想一样的编辑器吧…

   淘宝的css属性顺序书写规范

   以前部门的同事们，每个人都有一套书写的规范，导致看对方的css代码非常吃力，所以就推行了一套书写标准 ，或许对您也有帮助。

   *{
/*显示属性*/
display
position
float
clear
cursor
/*盒模型*/
margin
padding
width
height
/*排版*/
vertical-align
white-space
text-decoration
text-align

   /*文字*/
   color
   font
   content

   /*边框背景 为什么要把 boder和background放在最后的原因是修改的频率会较之前的频繁，放在最后查看起来方便，哈哈。*/
border
background
}

   说到底其实属性的书写顺序规范就是：神仙?妖怪? – 身材怎么样！- 服装类型(比基尼?棉袄?) – 服装款式(黑色?白色?纽扣?拉链?) – 用了啥化妆品和发型.
   这个书写标准小部分并不是浏览器厂商推行的书写规范，所以可能被广大标准推广者所不认同 。但这些个都是弟兄几个实践出来认为最符合现有淘宝环境的。

   css代码的简写

   css缩写的语法，对新手有一定帮助,老鸟就不用看了.

   1. 0px不需要单位，直接:margin:0
   2. 盒模型的缩写，语法是margin:上 右 下 左;.甚至可以简写成margin:上 (右左) 下,当然右左的值应该是一样的
   3. css属性的最后一项”;”号省略。（不建议 ^_^）
   4. 字体宽度normal用400代替,bold用700代替。
   5. 16进制的色彩值，如果每两位的值相同，可以缩写一半，例如：#000000可以缩写为#000;#0044DD可以缩写为#04D;
   6. border边框的缩写，语法是border:width style color,类似boder:1px solid red;
   7. 背景background的缩写,语法是color image repeat attachment position.类似:background:#f00 url(background.gif) no-repeat fixed 0 0( 为什么我从不写fixed呢?)
   8. 字体的缩写,类似font:italic small-caps bold 1em/140% “SimSun”,sans-serif,可以省略到最简单font:12px “SimSun”.
   9. list的属性缩写,语法list-style:square inside url(image.gif) ,不过一般咱们都不用.
   10. 想凑10条, 还真难.就把删除无用换行符和空格算一个吧

   一天大家在团队中讨论“未知图片垂直居中”的问题，突发奇想用vertical-align:middle这个属性来实现，于是抽了时间做了下面这个不成熟的例子：

   CSS:

    div{
     width:140px;
     height:140px;
     text-indent:-8px;
     text-align:center;
     line-height:138px;
     background:red;
     font-size:12px;
     *font-size:120px;
     *text-indent:-60px;
   }
   img{
     width:100px;
     height:100px;
     vertical-align:middle;
   }

   HTML:

   < div>& nbsp;<img src="ipodclassics.jpg" alt="iPod classic" />

   初衷是不想用position来做,毕竟 大量的图片显示浏览器在渲染的时候会消耗 较多的资源。

   缺点是 输出了 无意义的nbsp;, 而且font-size和font-indentd的计算公式不是很简单(所以以上的数字都是凑的^_^).

   后来小马见了这个思路，用了点时间升级了代码,用:after输出代替了无趣nbsp ,代码见下。

   CSS:

    .tb-p-c{
     display: block;
     width:140px;
     height:140px;
     line-height:140px;
     text-align:center;
     *font-size:123px;
   }
   .tb-p-c img{
     vertical-align:middle;
   }
   .tb-p-c:after {
     content: ".";
     visibility: hidden;
     font-size: 12px;
     margin-left: -5px;
   }

   HTML:

   <a class="tb-p-c"><img src="jishi070912_2.jpg" /></a>

   这样子，恼人的nbsp消失了。大家对vertical-align:middle的渲染方式有了更进一步的了解了。还让很多同志发现了after这个伪类还可以用来hack.

   结果圆心又给CSS升了次级：

   CSS:

    .tb-p-c{
     display: table-cell;
     vertical-align:middle;
     width:140px;
     height:140px;
     text-align:center;
     *display: block;
     *font-size: 122px;
     background:red;
   }
   .tb-p-c img {
     vertical-align:middle;
   }

   这是第三次的升级，由于时间关系，没有测试上面的代码，原因是利用了display来渲染，感觉上还是会让浏览器多次渲染，所以偶没测试 。
   这次探讨给了我们很多很多的收获，相信如果有大家的参与，会有更多方式和我们没发现的观点。大伙别小气，多发表回复，一起提高。

   ]]> http://adam.ofeva.com/blog/51.html/feed 1 http://adam.ofeva.com/blog/50.html http://adam.ofeva.com/blog/50.html#comments Mon, 18 Aug 2008 15:26:27 +0000 阿当 http://adam.ofeva.com/?p=50 Web标准的web UI——来源、谬误与个人理解

   序

   我从2004年末开始接触web标准，2005年5月正式采取完全的web标准方式的网页制作，2005年8月，第一个符合web标准的网站UI开发工作完成。直至今日，经历了无数的艰辛，也有过许多的困惑。所幸，我的瑞典籍的Project Leader是一个很有经验的人，他告诉了我很多关于web标准国内并不了解的东西，我这几年技术方面的成长离不开他的支持和引导，感谢Andreas Liljefilt！在这里，我把它们告诉大家，也希望能有更多的人来讨论。

   Chaper 1 什么是web标准？Div+css的谬误。

   提到web标准，就不得不先说一说国内业界非常流行的一个词——Div+css。这个词在国内简直是一个潮流，不仅互联网上一直在提，大量的教程中使用这个词，就连一些出版的书籍也是用了这个概念。然而，甚少人知道的是，这个概念本身是错误的。有好事的朋友不妨去google搜索一下（先调整到英文界面，这样可以强制让它搜索google.com而不是google.cn），”div+css”这样一个关键字是根本找不到任何一个英文网页，全部都是中文的。没错，其实所谓的div+css就是一个中国特有的理解和概念。我甚至不知道这个词是谁先提出来的，然而，它对web标准中xhtml/css的网页构建方法的理解几乎是完全错误的。

   回归正题，web标准究竟是什么？Web标准是w3c组织规定的各种web上所使用的语言的标准和规范的集合。

   我们目前究竟接触到了web标准的多少？打开 w3c的官方网站，我们在左侧可以看到如下列表：

   
# Accessibility
# Amaya
# CC/PP
# Compound Document Formats
(CDF)
# CSS
# CSS
Validator
# Databinding
# DOM
# Efficient XML
Interchange
# eGovernment
# GRDDL
# Health Care and Life
Sciences
# HTML
# HTML Tidy
# HTML Validator
# HTTP
# Incubator
# InkML
# Internationalization
# Jigsaw
# Libwww
# MathML
# Mobile Web Initiative
(W3C-MWI)
# Multimodal
Interaction
# OWL
# Patent Policy
# PICS
# PNG
# POWDER
# Privacy and P3P
# RDF
# Rich Web Clients
# Rules
# Security
# Semantic Web
# Service Modeling Language
(SML)
# SMIL
# SOAP/XMLP
# SPARQL
# Style
# SVG
# Timed Text
# URI/URL
# Validators
# Voice
# Ubiquitous Web
Applications
# WAI
# Web API
# Web Application
Formats
# Web Architecture
(TAG)
# WebCGM
# Web Services
# WS-Addressing
# WS-CDL
# WSDL
# WS-Policy
# XForms
# XHTML
# XHTML2
# XLink
# XML
# XML Base
# XML Encryption
# XML Key Management
# XML Processing
# XML Query
# XML Schema
# XML Signature
# XPath
# XPointer
# XSL and XSLT


   全看下来后是不是觉得很晕？没错，这个就是web标准目前的全部技术规范。web标准包含了这么多的内容，而我们目前所说的div+css只是其中xhtml/css实现方式的不完整的一部分而已。

   * 为什么是xhtml/css？

   其他的部分，我不想说的太多，第一是因为我也没办法全都弄懂，第二是其中有一大半浏览器支持不完全甚至根本就不支持。XML是web标准中对网页实现的最终目标。也就是web页面数据化和语义化，然而由于浏览器的支持不完善和兼容问题，目前优秀、兼容性强的纯xml网站只是停留在幻想里而已。因此，现在主流的网页实现方式就是xhtml/css。首先，xhtml与html大部分兼容，并且可以让目前大多数的浏览器直接阅读。css主流的几大浏览器也支持的非常完善。再加上ECMAScript(不说Javascript的原因是Javascript的概念中包含了很多与标准不同的浏览器私有定义)，已经足够实现web UI布局的大部分需要了。

   Chapter 2 web标准真的是要完全不用表格？

   好像是在2005年的时候，一篇叫做《把表格从你的网页中扔出去》（找不到文章的链接了，但确实有这篇文章）的在线文章，似乎给了人们一个错觉，要符合标准，那么表格在网页中就完全不能使用了。必须用div来代替。也许div+css这个概念就是这样被想当然的创造出来的（源自表格布局）。但事实上，web标准并不是完全不允许使用表格。而是要求摒弃使用表格来布局的做法。同时，也不再使用布局这个概念。而是提倡结构与表现分离。这时，就有一些人会产生一个疑惑，如果说xhtml代表结构，css用来控制表现，那么，布局该如何解决？相信现在接触web标准的朋友不会再有这个疑惑了吧？结构和表现结合起来就形成了布局。既然不能用表格来做布局了，那么表格还有什么用呢？似乎很多人忘了表格在html中的原始定义——展现结构化数据表格。举个例子，某学校班级的期中考试成绩表，这种数据，就是一个非常明显的表格。web标准中绝对没有要求你用div来模拟表格，那是非常蠢的做法。这几天在经典论坛上还看到有人产生这样的疑惑，表格形式的格式化数据，用表格比用div要方便的多，他们搞不懂为什么一定要用div来表现表格，现在我告诉你答案了，该用表格展现数据的时候就要用表格。

   Chapter 3 为什么要用web标准？怎么样才算是符合web标准？

   很多人会说例如兼容性好、代码易懂、代码量小、结构合理、甚至有人说使用标准可以实现比表格更丰富的样式等各种理由来支持web标准，而web标准也的确具有这些优点，然而，这些却并非web标准真正要做的。

   并非把表格换成div就是符合web标准了。也并非使用xhtml和css就是符合web标准。甚至就算你的代码能够通过w3c的验证，也很难说它就完全符合web标准。事实上，web标准的最终目标不是为了让人容易看懂网页如果仅仅是为了让人容易看懂，那么表格布局已经足够了。它的最终目标是为了让计算机能够读懂网页。看下面几个例子：

   表格布局的一段代码：

   <table width=”50%”>
   <tr>
   <td width=”30%”></td>
   <td width=”30%”><font size=”3″>web</font>标准的概念</td>
   <td width=”40%”>如何实现<b>标准化制作</b></td>
   </tr>
   <tr>
   <td colspan=”3″><font color=”red”><font size=”3″>web</font>标准在网页中的使用</font></td>
   </table>

   web标准（XHTML/CSS）实现的一段代码：

   <h3><span>web</span>标准的概念</h3>
   <h3>如何实现<em>标准化制作</em></h3>
   <h3 class=”important”><span>web</span>标准在网页中的使用</td>

   web标准(XML)实现的另一段代码：

   <articles>
       <articletitle>web标准的概念</articletitle>
       <articletitle em=”4″ emlegth=”3″>如何实现标准化制作</articletitle>
       <articletitle level=”important”>web标准在网页中的使用</articletitle>
   <articles>

   看过以上几段代码后，我们先来分析一下。第一段是表格布局的代码，它把整块分成了两行，第一行用了三列，第一列是空的用于缩进，后面两列分别放了两篇文章的标题。其中的英文文字采用了不同于中文的字号。第二篇文章的标题上还有一部分是加粗强调的。第二行则是一篇文章的标题占用了整行，并且以红色显示文章标题。在页面展现出来之后，我们能够明白下面的信息：第一篇文章是普通文章，第二篇文章中有一个概念是很重要的。而第三篇文章则非常重要。然而，在代码中我们却很难看出这一点。因为没有人说过加粗就一定是强调。也没有人告诉我们红色就一定表示重要（如果是在暗红色背景下，它甚至表示不重要，光看代码是不知道页面展现出来是什么样子的，是否重要自然无从判断），在这段代码中甚至没有告诉我们，这几段文字是文章标题。

   第二段代码就要清楚的多了，首先，h3标签告诉我们，它是一个标题。span标签完全没有含义，会被分析器忽略掉。而em标签则表示强调。程序很容易明白它究竟是什么。最后一行指定的的类important则可以告诉分析器，这篇文章十分重要。

   最后，我们再看第三段中的XML代码，首先，articletitle已经明明白白的告诉我们，它是文章标题，多余的信息没有了。事实上多数情况下是否强调一段文字中某一个部分对于分析器来说并不重要。因此，加粗强调被放到了属性里面。最后一条，level属性非常明白告诉分析器，这个属性定义的是文章的级别。而它的属性important则告诉分析器，它的级别是重要。将来采用这种结构，我们的网络将会更加智能，而搜索引擎的搜索结果也将会更加准确。当然，好处远远不只是这些。

   直到现在为止，第三段代码要想真正完美实现并且兼容，仍然只能停留在我们的梦想里。

   Chapter 4 web标准的局限

   web标准并没有有些人说的那么天花乱坠无所不能。正如很多在学习web标准开发的朋友所体会到的那样，如果想要开发的产品完全符合web标准，它的局限性其实很大。举例来说，如果按照web标准的建议不使用空结构块(如空div)、不使用无意义块（如仅作为装饰边角的图片）、不做无意义的DOM结构嵌套，那么想实现一个可拉伸大小的园角块都是非常困难的。目前网上流行的几种做法都不符合这个要求。这就是为什么欧美的许多网站往往结构以方块为主并且非常干净简练，一个原因是他们习惯这样的风格，但更重要的原因是为了UI的可用性和符合标准而在牺牲了美观，因为网站的DOM结构越复杂，互动表现越复杂，触发BUG的可能性就越大，兼容性也越难调整，此外，这些效果往往还不能完善。有兴趣的朋友不妨仔细看看一直被设计人员称道的大多数韩国网站，这种类型的网站和欧美的主流风格正好完全相背，走了另一个极端，以界面华丽花哨著称，因此特别能获得美术出身的朋友的青睐，在使用过程中总会出现各种各样的小问题。在 FF下也没有几个可以完美表现的。此外，这类网站在中国也是行不通的。大家不妨想想，究竟有哪个模仿韩国的网站能够获得比较高的知名度的？原因嘛，第一是它们经常造成浏览器速度过慢，第二是在网络条件不好的情况下下载经常很慢，第三，对服务器的负载压力非常大，很容易提高服务器的投入成本，最后，带来高带宽成本。

   Chapter 5 web标准的背后，企业该如何适应web标准？

   web标准有诸多好处，也带来了美好的前景，应当普及和推广。然而，盲目地追随标准，却可能造成整个项目的失败。要知道，web标准并非孤立的产生，而是于整个软件工程和web项目管理的发展有关。下面，我们来看一下，在适应web标准的过程中，究竟有哪些问题会造成项目失败。

   1. 对标准的理解错误

   前面说了，国内其实大多数企业和开发人员并不了解web标准。甚至有很多连web标准这个概念都不知道。反而对div+css这个被人错误解释出来的怪胎耳熟能详。设计师在进行设计的时候，往往天马行空的去做设计，完全没有任何章法可言，同样的内容，甚至在首页是三个字的标题，到了二级栏目页就会变成五个字，从根本上破坏了结构的可重用性。而UI程序员（请原谅我使用这个词语，因为发展到现在的web标准网页开发已经不是美术出身的设计师能够完全掌握的了）为了适应设计师的设计，只好拼命叠加各种奇怪的DOM结构，结果使本来用十行html代码就能写出来的页面最后用了三十行甚至更多，结构也一片混乱。css就更不用说了，不仅乱，而且乱的毫无章法。这种开发的方式经常造成最后只要设计上修改一点，就要对代码作非常大的改动，甚至整个开发流程从头做一遍，根本没有做到web标准中宣传的改版成本小，正好相反，改版成本有时会被无限提高。而混乱的结构和样式也会引发浏览器更多的BUG，让UI程序员不得不花更多的精力去写hack。从而进一步提高开发成本。

   2. 没有任何规划，上手就做

   在早期，由于表格布局的完全可视化编辑，使网页开发是可以完全不需要规划，一边做一边修改的。而我们大多数企业目前的开发流程也是如此。往往网站开发接近完成，策划人员还没有完全确定网站要展示的内容和提供的功能。但欧美许多公司的做法却是先做一份十分完善的策划和需求描述，然后建立用例模型、分析网站需求、建立逻辑模型，规划UI模块、规划功能模块、定义UI和功能模块的接口（大多数情况下这个接口就是我们现在经常使用的各种模板标签，事实上在欧洲比较完善的团队，这些标签在开始设计前就已经规定好了）、定义 flash应用程序的数据接口（一般情况下是XML文档）、定义内容框架（以便设计师在设计网站时了解网站的每个页面上究竟应该放些什么），这一大堆的各种文档几乎可以让任何两个不同的团队做出功能一模一样的两个网站来，除了美术设计不同。我就见过一份不过二十多个模板的策划案，仅仅是涉及UI设计和开发的策划和分析文档打印出来有300多页，密密麻麻的几十万字！为什么要说中国和欧美企业的开发过程的不同呢？原因很简单。中国的流程随意性更大，而欧美的流程则更加系统。然而web标准在设计的时候却是以欧美的设计流程为主。这就是我上面说的，没有任何规划，上手就做经常会造成项目失败的原因。一个边策划边构建的开发流程，采用了一份为完善的系统工程要求订制的标准，不失败才是奇迹！

   3. 主导人员角色错误，外行管理内行

   这几乎是中国百分之八十项目失败的主要原因！对比东西方的管理，会发现一个奇怪的现象，在西方一个项目是由专业的项目经理主导，而东方则是谁职位最高就由谁主导。总经理、部门行政经理甚至市场人员干预网站开发进程在中国屡见不鲜，甚至有向非web专业市场人员主导项目管理的倾向。在一个web开发团队中，有时起主导作用的项目经理或者策划人员并非专业的项目经理或者web策划人员，最夸张的，我目前在做的项目竟然是以设计师的设计稿为主导，设计成什么样子，就必须作成什么样子，并且整个网站的设计稿完全没有任何关于互动方面的说明（其实是绘图师，他们对web的结构和技术限制是完全懂的）。而我认识的很多朋友也都因为上级在开发进程中的胡乱干预（注意，是开发进程中，而不是策划过程）叫苦连天，甚至有时会造成整个项目必须彻底推翻重来的尴尬境地。不断延期或者推翻重来的项目开发过程，无限翻倍的项目成本，造成项目失败也就不怎么新鲜了。似乎这一点与web标准并没有关系，然而，在web标准化开发要求的团队和流程里，第一点要求就是项目经理和策划人员必须专业并且其技能范围符合项目规模！事实上这也是任何项目管理的必要条件。

   那么，企业和开发人员究竟该如何适应web标准？以下几点注意事项仅供参考：

   1. 完善的前期策划和分析
   2. 完善的前期逻辑模型以及项目规范性文档的制定
   3. 尽可能将行政性干预移到策划阶段（按照国内的情况，做到这一点可能很困难）
   4. 尽可能向后兼容，在项目规范性文档制定阶段对网站进行完善的模块化规范（主要是为了提高网站模块代码的可重用性以及最大程度上降低改版成本）。
   5. 尽可能简化UI代码的DOM结构，以降低维护成本
   6. 在设计和开发过程中首先保证UI的可用性，在此基础上保证其美观（好用第一，好看第二）。
   7. 项目阶段明确，要让单位的高层明白，在项目的alpha期之前是不可能有能让他们看的懂用的通的完善网站出现的。
   8. 项目团队主要成员必须要用专业人员，并且要让这些人员有足够的决定权（如果项目负责人无法主导项目走向，项目就必然产生缺陷甚至失败）。

   这篇文章到这里已经结束了，我不知道这篇文章究竟会不会让那些一意孤行的BOSS们看到，更不指望能给他们带来多少影响。如果哪个BOSS看到了，希望你考虑一下你的投资和钞票。我所说的这一切，不仅仅是为了减轻开发人员的负担，更是为了让开发人员能够实现一个赚钱的项目，从而在这个赚钱的项目中获得更多的金钱和良好的心情。而能够决定这一切的，并非开发和设计人员。

   原文：http://blog.icebirds.net/site/comments/a20071224001/

   ]]> http://adam.ofeva.com/blog/50.html/feed 0 http://adam.ofeva.com/blog/49.html http://adam.ofeva.com/blog/49.html#comments Mon, 18 Aug 2008 15:15:55 +0000 阿当 http://adam.ofeva.com/?p=49 这篇文章阐述的是一种函数式编程（functional-programming）设计模式，我称之为惰性函数定义（Lazy Function Definition）。我不止一次发现这种模式在JavaScript中大有用处，尤其是编写跨浏览器的、高效运行的库之时。

   热身问题

   编写一个函数foo，它返回的是Date对象，这个对象保存的是foo首次调用的时间。

   方法一：上古时代的技术

   这个最简陋的解决方案使用了全局变量t来保存Date对象。foo首次调用时会把时间保存到t中。接下来的再次调用，foo只会返回保存在t中的值。

   var t;
   function foo() {
       if (t) {
           return t;
       }
       t = new Date();
       return t;
   }

   但是这样的代码有两个问题。第一，变量t是一个多余的全局变量，并且在 foo调用的间隔期间有可能被更改。第二，在调用时这些代码的效率并没有得到优化因为每次调用 foo都必须去求值条件。虽然在这个例子中，求值条件并不显得低效，但在现实世界的实践例子中常常会有极为昂贵的条件求值，比如在if-else-else-…的结构中。

   方法二：模块模式

   我们可以通过被认为归功于Cornford 和 Crockford 的模块模式来弥补第一种方法的缺陷。使用闭包可以隐藏全局变量t，只有在 foo内的代码才可以访问它。

   var foo = (function() {
       var t;
       return function() {
           if (t) {
               return t;
           }
           t = new Date();
           return t;
       }
   })();

   但这仍然没有优化调用时的效率，因为每次调用foo依然需要求值条件。

   虽然模块模式是一个强大的工具，但我坚信在这种情形下它用错了地方。

   方法三：函数作为对象

   由于JavaScript的函数也是对象，所以它可以带有属性，我们可以据此实现一种跟模块模式质量差不多的解决方案。

   function foo() {
       if (foo.t) {
           return foo.t;
       }
       foo.t = new Date();
       return foo.t;
   }

   在一些情形中，带有属性的函数对象可以产生比较清晰的解决方案。我认为，这个方法在理念上要比模式模块方法更为简单。

   这个解决方案避免了第一种方法中的全局变量t，但仍然解决不了foo每次调用所带来的条件求值。

   方法四：惰性函数定义

   现在，这是你阅读这篇文章的理由：

   var foo = function() {
       var t = new Date();
       foo = function() {
           return t;
       };
       return foo();
   };

   当foo首次调用，我们实例化一个新的Date对象并重置 foo到一个新的函数上，它在其闭包内包含Date对象。在首次调用结束之前，foo的新函数值也已调用并提供返回值。

   接下来的foo调用都只会简单地返回t保留在其闭包内的值。这是非常快的查找，尤其是，如果之前那些例子的条件非常多和复杂的话，就会显得很高效。

   弄清这种模式的另一种途径是，外围（outer）函数对foo的首次调用是一个保证（promise）。它保证了首次调用会重定义foo为一个非常有用的函数。笼统地说，术语“保证” 来自于Scheme的惰性求值机制（lazy evaluation mechanism）。每一位JavaScript程序员真的都应该 学习Scheme ，因为它有很多函数式编程相关的东西，而这些东西会出现在JavaScript中。

   确定页面滚动距离

   编写跨浏览器的JavaScript, 经常会把不同的浏览器特定的算法包裹在一个独立的JavaScript函数中。这就可以通过隐藏浏览器差异来标准化浏览器API，并让构建和维护复杂的页面特性的JavaScript更容易。当包裹函数被调用，就会执行恰当的浏览器特定的算法。

   在拖放库中，经常需要使用由鼠标事件提供的光标位置信息。鼠标事件给予的光标坐标相对于浏览器窗口而不是页面。加上页面滚动距离鼠标的窗口坐标的距离即可得到鼠标相对于页面的坐标。所以我们需要一个反馈页面滚动的函数。演示起见，这个例子定义了一个函数getScrollY。因为拖放库在拖拽期间会持续运行，我们的getScrollY必须尽可能高效。

   不过却有四种不同的浏览器特定的页面滚动反馈算法。Richard Cornford在他的feature detection article 文章中提到这些算法。最大的陷阱在于这四种页面滚动反馈算法其中之一使用了 document.body. JavaScript库通常会在HTML文档的<head>加载，与此同时docment.body并不存在。所以在库载入的时候，我们并不能使用特性检查（feature detection）来确定使用哪种算法。

   考虑到这些问题，大部分JavaScript库会选择以下两种方法中的一种。第一个选择是使用浏览器嗅探navigator.userAgent，为该浏览器创建高效、简洁的getScrollY. 第二个更好些的选择是getScrollY在每一次调用时都使用特性检查来决定合适的算法。但是第二个选择并不高效。

   好消息是拖放库中的getScrollY只会在用户与页面的元素交互时才会用到。如果元素业已出现在页面中，那么document.body也会同时存在。getScrollY的首次调用，我们可以使用惰性函数定义模式结合特性检查来创建高效的getScrollY.

   var getScrollY = function() {

       if (typeof window.pageYOffset == ‘number’) {
           getScrollY = function() {
               return window.pageYOffset;
           };

       } else if ((typeof document.compatMode == ‘string’) &&
                  (document.compatMode.indexOf(‘CSS’) >= 0) &&
                  (document.documentElement) &&
                  (typeof document.documentElement.scrollTop == ‘number’)) {
           getScrollY = function() {
               return document.documentElement.scrollTop;
           };

       } else if ((document.body) &&
                  (typeof document.body.scrollTop == ‘number’)) {
         getScrollY = function() {
             return document.body.scrollTop;
         }

       } else {
         getScrollY = function() {
             return NaN;
         };

       }

       return getScrollY();
   }

   总结

   惰性函数定义模式让我可以编写一些紧凑、健壮、高效的代码。用到这个模式的每一次，我都会抽空赞叹JavaScript的函数式编程能力。

   JavaScript同时支持函数式和面向对象便程。市面上有很多重点着墨于面向对象设计模式的书都可以应用到JavaScript编程中。不过却没有多少书涉及函数式设计模式的例子。对于JavaScript社区来说，还需要很长时间来积累良好的函数式模式。

   更新：

   这个模式虽然有趣，但由于大量使用闭包，可能会由于内存管理的不善而导致性能问题。来自 FCKeditor 的FredCK改进了getScrollY，既使用了这种模式，也避免了闭包：

   var getScrollY = function() {

       if (typeof window.pageYOffset == ‘number’)
           return (getScrollY = getScrollY.case1)();

       var compatMode = document.compatMode;
       var documentElement = document.documentElement;

       if ((typeof compatMode == ‘string’) &&
                  (compatMode.indexOf(‘CSS’) >= 0) &&
                  (documentElement) &&
                  (typeof documentElement.scrollTop == ‘number’))
           return (getScrollY = getScrollY.case2)();

       var body = document.body ;
       if ((body) &&
                  (typeof body.scrollTop == ‘number’))
           return (getScrollY = getScrollY.case3)();

       return (getScrollY = getScrollY.case4)();
   };

   getScrollY.case1 = function() {
       return window.pageYOffset;
   };

   getScrollY.case2 = function() {
       return documentElement.scrollTop;
   };

   getScrollY.case3 = function() {
       return body.scrollTop;
   };

   getScrollY.case4 = function() {
           return NaN;
   };

   原文：Lazy Function Definition Pattern.

   ]]> http://adam.ofeva.com/blog/49.html/feed 0 http://adam.ofeva.com/blog/48.html http://adam.ofeva.com/blog/48.html#comments Mon, 18 Aug 2008 15:09:09 +0000 阿当 http://adam.ofeva.com/?p=48 引子：

   今天在蓝点看了Yang的博客《CSS样式表中继承关系的空格与不空格》，思考了一下，本来想写《CSS样式的复合定义与复合调用及简单的模块化设计》，但是内容太大，还是来点简单的实惠。所以改叫《CSS样式——从空格谈起》吧。

   一、空格运算符

   （1）CSS语言

   简单地说，CSS语言类似JS语言，是通过客户端下载后，通过本地浏览器解析。而CSS语言又是非常低级的“弱类型”语言，离JS这种基于对象的比较完善的“弱类型”语言，还差相当一段距离。要知道CSS样式是定义出来的，而样式的呈现是根据文档流顺序和CSS优先级别，浏览器自己识别计算后显示出来的。而浏览器又有忽略和纠错功能（尤以IE为甚），所以样式定义的语法有错误，并不影响浏览器正常工作，只不过显示不出应有的效果罢了。在我们设计定义样式的时候，排错是比较令人苦恼的，其本质原因是于这种弱类型CSS语言本身的不严禁性有关系的，所以我们就更应该注重CSS定义的严禁，才能出较少的错误，较快更好的完成工作

   （2）CSS的运算符

   首先说，CSS语言的运算符就不多，有.#{}:”;还有一个非常重要的空格。这几个运算符，都是常用的定义声明符号。而在CSS样式定义中，空格就有点特殊，我们可以把它视为在.Net或Java中命名空间或类包定义中的 . 运算符。换句话说，我们可以把空格视为路径指向的箭头，表明HTML标签的父子级别关系。CSS是与HTML想关联的，也就是说，CSS的每一个定义都与“某个HTML标签”或“某段模块化HTML代码”相对应，而HTML可以调用多个样式类。一个CSS样式类可以根据HTML代码来“复合定义”；一个HTML标签也可以“复合调用”多个样式类。所以说，CSS样式定义的复杂性与关联的HTML是密不可分。

   （3）实例说明

   <style type=”text/css”>
   td .b {
          color:#00ff00;
   }
   th.b { 
          color:#ff0000;
          font-family:黑体;
          font-size:20px;
   }
   .b {
          color:#0000ff;
          font-size:12px;
   }
   </style>

   <table>
          <tr>
                
                 <td><div class=”b”>第一个类b的类路径是th .b</div></td>
                 <th class=”b”>第二个类b的类路径是th.b</td>
                 <td class=”b”>第三个类b的类路径是 .b</th>
          </tr>
   </table>
   <div class=”b”>第三个类b的类路径是 .b</div>

   讲解：

   1、第一个类b的类路径是td .b，定义该HTML文档内所有的td标签内的带class=”b”的标签的样式 。
   也就是说：
   td .b {
          color:#00ff00;
   }
   定义的是
   <td><div class=”b”>text</div></td>
   这组代码块中的b类，class=”b”是包含在td标签内的，是td的子级，所以在这里要用“空格”指向明确表明父子级别关系。

   2、第二个类b的类路径是th.b，定义的是该HTML文档内所有的带class=”b”的th标签的样式。
   也就是说，
   th.b { 
          color: #FF0000
   }
   定义的是
   <th class=”b”>text</td>
   在这里的代码中，th和class=’b'是平级的，先th后.b组成一个同级类路径th.b，所以没有空格代表“HTML类”和“自定义类”具有同级路径！

   3、第三个类b的类路径是 .b，定义该HTML文档内所有的td标签的样式，它是该文档的一个全局样式，是body .b的简写。
   也就是说，
   .b {
          color:#0000ff;
          font-size:12px;
   }
   定义了
   <td class=”b”>第三个类b的类路径是td.b</th>
   和
   <div class=”b”>第三个类b的类路径是 .b</div>

   这两处的b类没有明确的路径指向，优先级别要比有明确路径的低。

   4、大家可以看到，在HTML代码中，同样都是class=”b”，但是在CSS定义时，采用的类路径不同，作用就不同了。类路径越完整，优先级越高。在具体应用的时候，我们可以，使用完整类路径来定义某HTML代码块某一些特殊地方，做异化处理。例如本例表头th的黑体字显示效果。

   二、HTML中复合调用样式类

   （1）在一个HTML标签内，可以复合调用多个样式类，也是用空格做运算符，复合类名总字符不能超过256。
   （2）示例：

   <style type=”text/css”>
   .myTxt {
          font-size:50px;      
          font-family:Arial Black;
   }
   .txtRed {
          color:red;
   }
   .txtOrange {
          color:orange;
   }
   .txtGreen {
          color:green;
   }
   .txtBlue {
          color:blue;
   }
   </style>
   <ul>
          <li class=”myTxt txtRed”>123</li>
          <li class=”myTxt txtOrange”>Text</li>
          <li class=”txtGreen”>Text</li>
          <li class=”myTxt txtBlue”>Text</li>
   </ul>

   （3）应用：
   对于某些多数样式属性累同，仅有几个不同样式属性的定义，可以用这个方法来缩写。
   也可以在某个不改变某个通用样式类的同时，用HTML调用复合类，突出局部特例。

   三、CSS+HTML的模块化设计

   （1）举个简单例子：
   .classNameA .classNameB .classNameC
   就是一个类包路径,A包含B,B包含C.
   意思就是,在A块内的全部HTML代码(包括B块、C块),先应用样式classNameA；
   然后，在B块内的全部HTML代码(包括C块),先应用样式classNameA，之后再先应用样式classNameB；
   最后，在C块内的全部HTML代码,先应用样式classNameA，再先应用样式classNameB,最后应用样式classNameB；

   （2）在样式表中，关于类包的路径，对于某些复杂的HMTL代码，最后写绝对路径，就是每一个类名都不要拉下。这样可读性更强，错误率更小；当然，宽容度就越低。

   例如：

   <style type=”text/css”>
   /*控制 li 的样式*/
   .a1 ul li {
       color:red;
   }

   /*控制class=”a”的div块内，全部连接 a 的样式*/
   .a1 a {
       font-size:20px;
   }

   /*控制class=”a”的div块内，一个一个为 class=”mylink”的样式*/
   .a1 .myLink {
          font-size:12px;
   }

   /*控制 li 内连接a的样式*/
   .a1 ul li a {
          font-size:40px;
   }

   /*控制名 li 内，一个为 class=”mylink”的连接的样式 */
   .a1 ul li .myLink {
          font-size:60px;
          font-family:黑体;
   }

   /*b1样式*/
   .b1 {
         color:blue;
   }
   /*控制 li 内 b1 的样式*/
   .a1 ul li .b1 {
        color:green;
   }
   </style>

   <div class=”a1″>
         <a href=”#”>linkText</a>
         <a href=”#” class=”myLink”>titleText</a>
         <div class=”b1″>b11111111</div>
         <ul>
               <li>
                      <a href=”#”>titleText</a>
                      <div class=”b1″>nameCN</div>
               </li>
               <li>
                      <a href=”#” class=”myLink”>titleText</a>
                      <div class=”b1″>nameCN<span class=”c1″>nameEN</span></div>
               </li>
               <li>titleText</li>
               <li>titleText</li>
               <li>titleText</li>
         </ul>
   </div>

   样式，按*.HTML从内层到外层；按*.CSS上下文，从下文到上文；按内联样式表上下文，从下文到上文；按内嵌>内联>外联的优先级；
   叠加覆盖计算最终显示效果。

   CSS语句，严格说是JS代码的一类，换句话说，CSS语句也是“弱类型”的，空格是一个“运算符”，由于“弱类型”不严谨，所以，没有空格的时候，虽然不报错，也有显示效果，但那是按错误逻辑运算的，有时歪打正着，但确莫名其妙。再加上有很多满足各浏览器的HACK语法，CSS语句就更加零乱不堪。所以，写的时候，尽量在满足宽容度的情况下，严禁一些。

   （3）给大家一个案例

   模块化设计，要求相对封闭独立性、可重复性、可修改性、统一性等等是比较高的，当然，模块化越高越复杂的，修改起来也要月谨慎，因为牵一发而动全身，这就要求，在开发设计前期要做好详尽的策划，从目录结构、命名规范，到全局和特例的界限划分、后期修改的宽容度估计等等，都要有个把握。

   下面就给一个我做的网站的地址：http://www.51youcai.com

   1. 样式表是按类路径来模块化定义的，有中文注释；
   2. 由于加了jsp程序，代码格式有变动，也许会有不少垃圾代码；
   3. 在FireFox下，有几处显示不当、JS未做相应优化，请用IE6+浏览；
   4. 感兴趣者可以当HTML和CSS来，做参考。
   ]]> http://adam.ofeva.com/blog/48.html/feed 0 http://adam.ofeva.com/blog/47.html http://adam.ofeva.com/blog/47.html#comments Mon, 18 Aug 2008 15:02:53 +0000 阿当 http://adam.ofeva.com/?p=47 原文：Unobtrusive Ajax。

   今天才看见的一个Presentation，是Jesse Skinner在06年10月发表的。虽然题目是关于Ajax的，但实际上前面很大篇幅再讲什么是Unobtrusive的Web开发，而且将得也很有意思。下面把其中的要点摘录出来翻译，分享一下。

   对Web前端进行分层

   • Web前端的分层：
     • 核心思想：结构（HTML）、表现（CSS）和行为 （JavaScript）
     • 物理上：.html、.css和.js文件
     • 概念上：各层之间，相互独立，互不影响
   • 借用MVC的思想：
     • Model – HTML
     • View – CSS
     • Controller – JavaScript

   物理上的分层

   • CSS只出现在.css文件中，JavaScript只出现在.js文件中
   • 在HTML中不会出现onload、onclick或者style属性
   • 不使用不赞成使用的HTML，比如font标签和align属性

   概念上的分层

   • 内容和表单在纯HTML中（没有CSS和JavaScript）也能够正常显示和使用
   • 表单和链接在没有JavaScript时候也能正常工作
   • 只在CSS中定义表现，而不是在HTML或JavaScript中
   • 任何人可以通过任何客户端访问内容，即便是没有CSS、JavaScript，甚至没有鼠标

   两种分层有何不同

   • 物理分层主要使开发者受益
   • 概念分层主要让使用者受益

   Unobtrusive的前端

   Unobtrusive的HTML

   • 使用更多的HTML标签
   • 只将<table>用于表格式的数据
   • 避免使用无意义的<div>和<span>

   Unobtrusive的CSS

   • All CSS is unobtrusive
   • 尽量使用可重用的class
   • 将CSS放在外部.css文件中，或者<style>标签中
   • 最好使用<h1>，而不是<div class="header">

   Unobtrusive的Flash对象

   • 用JavaScript将HTML替换成Flash
   • Bobby van der Sluis的脚本（bobbyvandersluis.com）
   • 将Flash的内容同样放在HTML中
   • 如果浏览器支持Flash，用户将会欣赏性感的Flash版本
   • 不要在HTML中加入混乱的Flash代码

   Unobtrusive的JavaScript

   • 从纯HTML入手
   • JavaScript只用来为HTML添彩
   • 不要摆架子，测试每一个细节
   • 离了JavaScript，页面仍然能够正常工作
   • 不要使用onclick或javascript:void(0)
   • 将JavaScript放在外部.js文件中，或者<script>标签中

   为什么要Unobtrusive

   • 首先，这不是必须的
   • 大部分开发者都没有在用
   • 一些比较值得一提的例子：
     • Google Maps (maps.google.com)
     • TWERQ (twerq.com)
     • Marlboro (marlboro.com)

   Unobtrusive开发的优势

   • 代码更佳简洁，并且易于维护
     • 易读和易懂意味着更容易修改
     • 修改全部的样式仅仅需要修改CSS文件
     • JavaScript能够很容易的修改
     • HTML的修改变得更加保险
   • 能够提高可访问性（accessibility）
     • 可访问性意味着所有人都可以访问你的内容
     • 你不能揣测所有人
     • 但你可以肯定的是所有浏览器都能够处理HTML
     • 大约10%的访问者是不能够使用JavaScript功能（www.w3schools.com/browsers/browsers_stats.asp）
     • 有些人使用的是屏幕阅读器，有些人无法使用鼠标
   • 有利于搜索引擎优化
     • 搜索爬虫无法解释CSS和JavaScript
     • 搜索爬虫只会顺着<a>继续爬行
     • JavaScript和Flash中的内容无法被搜索到
     • 更多的内容，更结构化的HTML，使得页面相关性更高

   不过有时，不得不使用JavaScript

   • 当然，离了JavaScript，JavaScript游戏肯定无法运行
   • 很多Web统计服务的脚本依赖于JavaScript
   • Google Ads需要JavaScript
   • 对于Unobtrusive，只要尽量做到就好了

   如何进行Unobtrusive的开发

   不要去问别人，直接去做

   从没有JavaScript开始入手

   • 使用带有链接和表单的纯HTML
   • 使用CSS来实现hover和滚动效果
   • 使用HTTP的功能（比如用”Location”头来转向）

   重视链接

   • 页面上的所有链接，离了JavaScript都应该能够正常工作
   • 这也意味着不使用javascript:伪协议
   • 甚至不要使用<a href="#">
   • 如果有链接一定要使用JavaScript，那么就用JavaScript来把链接添加到页面中

   为CSS和JavaScript提供hook

   • 给一个页面中唯一的元素加上ID
   • 给重复使用的元素加上class
   • 使用列表等其他有语义的结构

   使用可靠的技术

   • 从纯HTML和CSS开始
   • 动态的为链接和表单添加高级交互功能
   • 同时通过HTML和JSON/XML两种方式提供内容
   • 为有或没有JavaScript的情况提供额外的CSS
   • 为有JavaScript和无JavaScript的用户提供不同的应用

   我的看法

   Unobtrusive应该是对Web Standards的进一步深化，也可以理解为Web Standards的一个方面。但是，这种开发方式目前仍然是一种比较理想化的方式，也许在个人，或者小团队的开发中可以贯彻的很好。但是到了大型项目中，严格的执行未必是一种高效的方式。尽管代码的易维护性显而易见，但是大部分项目的前端代码不一定有维护（或者大量维护）的需求，而项目要求的更多是能够在最短时间内完成。

   然而，Unobtrusive绝对是一个具有指导性的Web前端开发方式，实现得越接近，无论是对用户，还是对开发者，甚至对计算机，都会更有好处。

   ]]> http://adam.ofeva.com/blog/47.html/feed 0 http://adam.ofeva.com/blog/46.html http://adam.ofeva.com/blog/46.html#comments Mon, 18 Aug 2008 14:59:09 +0000 阿当 http://adam.ofeva.com/?p=46 真是五个很quick的小提示：

   只在
   

   元素上使用submit事件

   如果要在form中绑定事件处理程序时，应该只在
   元素上绑定submit事件，而不是给提交按钮绑定click事件。
   March：这个方式固然很好，但是，公司开发时使用了Web Flow，一个页面就一个大form，而里面可能有若干个提交按钮，所以不得不把部分事件处理程序绑定在了提交按钮的click事件上。

   可点击的都应该是链接

   不要给除锚元素（）以外的元素绑定click事件。这一点对于键盘用户很重要，因为他们在仅通过键盘获取元素焦点时会遇到困难。

   March：不过个人感觉锚元素还是应该只用作链接，而一些功能性的操作（比如Google Reader的Mark all as new），最好还是用来标注，accessibility的问题可以通过快捷键等方式解决。这样做可以更好的还原HTML元素的语义。

   简单的for循环优化

   在你写一个for循环时，有个很简单的技巧能够提高性能。

   for ( var i = 0; i < elements.length; ++i )
   使用下面的语句代替上面的：

   for ( var i = 0, j = elements.length; i < j; ++i )
   这样可以把元素的个数（elements.length的值）储存在一个变量j中，这样就不必在每次循环时都计算一遍元素的个数。

   用匿名函数来作为事件处理程序

   尤其是对于短小的函数，创建一个匿名函数会比使用一个命名函数的引用更具可读性。

   anchor.onclick = function() { map.goToPosition( home ); return false; }
   March：在较复杂的JavaScript开发时还是使用命名函数效率更高。

   使用Array.join代替字符串连接（concatenating strings）

   在将很多字符串、变量等连接成一个很长的字符串时，将所有字符串和变量放入一个数组，然后用join方法将他们组成一个长字符串，这样无论从代码可读性还是从性能上都更胜于字符串连接。
   
var text = 'There are' + elements.length + 'members in the elements array.';
var text = ['There are', elements.length, 'members in the elements array.'].join(' ');

   ]]> http://adam.ofeva.com/blog/46.html/feed 0 http://adam.ofeva.com/blog/45.html http://adam.ofeva.com/blog/45.html#comments Mon, 18 Aug 2008 14:29:11 +0000 阿当 http://adam.ofeva.com/?p=45 以下以 IE 代替 Internet Explorer，以 MF 代替 Mozzila FF

   1. document.form.item 问题

   现有问题：
   现有代码中存在许多 document.formName.item(“itemName”) 这样的语句，不能在 MF 下运行

   解决方法：
   改用 document.formName.elements["elementName"]

   其它
   参见 2

   2. 集合类对象问题

   现有问题：
   现有代码中许多集合类对象取用时使用 ()，IE 能接受，MF 不能。

   解决方法：
   改用 [] 作为下标运算。如：document.forms(“formName”) 改为 document.forms["formName"]。
   又如：document.getElementsByName(“inputName”)(1) 改为 document.getElementsByName(“inputName”)[1]

   3. window.event

   现有问题：
   使用 window.event 无法在 MF 上运行

   解决方法：
   MF 的 event 只能在事件发生的现场使用，此问题暂无法解决。可以这样变通：
   原代码(可在IE中运行)：

   function gotoSubmit() {

   alert(window.event); // use window.event

   }

   新代码(可在IE和MF中运行)：

   function gotoSubmit(evt) {
   evt = evt ? evt : (window.event ? window.event : null);

   alert(evt); // use evt

   }

   此外，如果新代码中第一行不改，与老代码一样的话(即 gotoSubmit 调用没有给参数)，则仍然只能在IE中运行，但不会出错。所以，这种方案 tpl 部分仍与老代码兼容。

   4. HTML 对象的 id 作为对象名的问题

   现有问题：
   在 IE 中，HTML 对象的 ID 可以作为 document 的下属对象变量名直接使用。在 MF 中不能。

   解决方法：
   用 getElementById(“idName”) 代替 idName 作为对象变量使用。

   5. 用idName字符串取得对象的问题

   现有问题：
   在IE中，利用 eval(idName) 可以取得 id 为 idName 的 HTML 对象，在MF 中不能。

   解决方法：
   用 getElementById(idName) 代替 eval(idName)。

   6. 变量名与某 HTML 对象 id 相同的问题

   现有问题：
   在 MF 中，因为对象 id 不作为 HTML 对象的名称，所以可以使用与 HTML 对象 id 相同的变量名，IE 中不能。

   解决方法：
   在声明变量时，一律加上 var ，以避免歧义，这样在 IE 中亦可正常运行。
   此外，最好不要取与 HTML 对象 id 相同的变量名，以减少错误。

   其它：
   参见 问题4

   7. event.x 与 event.y 问题

   现有问题：
   在IE 中，event 对象有 x, y 属性，MF中没有。

   解决方法：
   在MF中，与event.x 等效的是 event.pageX。但event.pageX IE中没有。
   故采用 event.clientX 代替 event.x。在IE 中也有这个变量。
   event.clientX 与 event.pageX 有微妙的差别（当整个页面有滚动条的时候），不过大多数时候是等效的。

   如果要完全一样，可以稍麻烦些：
   mX = event.x ? event.x : event.pageX;
   然后用 mX 代替 event.x

   其它：
   event.layerX 在 IE 与 MF 中都有，具体意义有无差别尚未试验。

   8. 关于frame

   现有问题：
   在 IE中 可以用window.testFrame取得该frame，mf中不行

   解决方法：
   在frame的使用方面mf和ie的最主要的区别是：
   如果在frame标签中书写了以下属性：

   那么ie可以通过id或者name访问这个frame对应的window对象
   而mf只可以通过name来访问这个frame对应的window对象
   例如如果上述frame标签写在最上层的window里面的htm里面，那么可以这样访问
   ie： window.top.frameId或者window.top.frameName来访问这个window对象
   mf： 只能这样window.top.frameName来访问这个window对象

   另外，在mf和ie中都可以使用window.top.document.getElementById(“frameId”)来访问frame标签
   并且可以通过window.top.document.getElementById(“testFrame”).src = ‘xx.htm’来切换frame的内容
   也都可以通过window.top.frameName.location = ‘xx.htm’来切换frame的内容
   关于frame和window的描述可以参见bbs的‘window与frame’文章
   以及/test/js/test_frame/目录下面的测试
   —-adun 2004.12.09修改

   9. 在mf中，自己定义的属性必须getAttribute()取得
   10.在mf中没有 parentElement parement.children 而用parentNode parentNode.childNodes
   childNodes的下标的含义在IE和MF中不同，MF使用DOM规范，childNodes中会插入空白文本节点。
   一般可以通过node.getElementsByTagName()来回避这个问题。
   当html中节点缺失时，IE和MF对parentNode的解释不同，例如

   MF中input.parentNode的值为form, 而IE中input.parentNode的值为空节点

   MF中节点没有removeNode方法，必须使用如下方法 node.parentNode.removeChild(node)

   11.const 问题

   现有问题：
   在 IE 中不能使用 const 关键字。如 const constVar = 32; 在IE中这是语法错误。

   解决方法：
   不使用 const ，以 var 代替。

   12. body 对象

   MF的body在body标签没有被浏览器完全读入之前就存在，而IE则必须在body完全被读入之后才存在

   13. url encoding在js中如果书写url就直接写&不要写&例如var url = ‘xx.jsp?objectName=xx&objectEvent=xxx’;
   frm.action = url那么很有可能url不会被正常显示以至于参数没有正确的传到服务器
   一般会服务器报错参数没有找到
   当然如果是在tpl中例外，因为tpl中符合xml规范，要求&书写为&
   一般MF无法识别js中的&

   14. nodeName 和 tagName 问题

   现有问题：
   在MF中，所有节点均有 nodeName 值，但 textNode 没有 tagName 值。在 IE 中，nodeName 的使用好象
   有问题（具体情况没有测试，但我的IE已经死了好几次）。

   解决方法：
   使用 tagName，但应检测其是否为空。

   15. 元素属性

   IE下 input.type属性为只读，但是MF下可以修改

   16. document.getElementsByName() 和 document.all[name] 的问题

   现有问题：
   在 IE 中，getElementsByName()、document.all[name] 均不能用来取得 div 元素（是否还有其它不能取的元素还不知道）。

   17. DOM 数据岛的问题

   现有问题：
   在IE中, 标签具有特殊意义, 可以内含XML DOM, 并能实现与HTML组件的数据 绑定. 在MF中,则仅仅是一个未知的标记而已. 另外, 对 IE 来说, 实际意味着这里是一个ActiveX对象, 但它却挂在HTML本 身的DOM树下作为一个节点, 因而会对DOM树的遍历造成严重影响.

   解决方法：
   IE的数据绑定机制是可以用JS来模拟的, 但是太麻烦, 建议不使用数据绑定机制或者 寻找实现这种模拟的库来做. 我们只讨论如何实现DOM的兼容. 在MF中无论已知的HTML标记还是其它符合XML规范的标记, 都是用统一的DOM树来处理的, 因此, MF事实上完全可以使用DOM数据岛, 但与IE小小的不同在于: 在IE中 是个 DOM document, 而在MF只是 DOM node. 这个差别通常不足为患. 但是有一个小小的细节, 为了兼容HTML相当随意的语法, MF无法识别简写的空标记. 如: , 这其中和是简写形式的, 会使MF无法识别, 应当写成: 不过, 我怀疑如果用XHTML, 可能就没有这种问题. 但我还没有试过. 对于IE中干扰HTML的DOM结构问题, 我现在的方法是处理完毕后把它从HTML的 DOM中删除. 不知道还有没有更好的解.

   ]]> http://adam.ofeva.com/blog/45.html/feed 0 http://adam.ofeva.com/blog/44.html http://adam.ofeva.com/blog/44.html#comments Mon, 18 Aug 2008 02:11:12 +0000 阿当 http://adam.ofeva.com/?p=44 什么是用户故事(user story)

   假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。

   因此，我们的客户就是他们的市场经理。谈需求的时候，有一回他这样说：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。”

   上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。也就是说，上面我们的客户所说的话，就是在描述一个用户故事（user story）。
   (我解释一下为什么用故事这个词，没兴趣也可以忽略。在一个系统面前，每个用户要完成同样的目标，都要做这个系统设定的例行的事，这件事情不是一个例子，所以不叫事例，这也不是故事，也不能算一段历程，而是一个例行的事。)

   如果我们想要记下这段用户故事，我们可能会用这样的格式：

   名称：卖饮料

   事件：

   1. 用户投入一些钱。

   2. 售货机显示用户已经投了多少钱。

   3. 如果投入的钱足够买某种饮料，这种饮料对应的按钮的灯就会亮。

   4. 用户按了某个亮了的按钮。

   5. 售货机卖出一罐饮料给他。

   6. 售货机找零钱给他。

   注意到，一个用户故事里面的事件可以这样描述：

   1. 用户做XX。

   2. 系统做YY。

   3. 用户做ZZ。

   4. 系统做TT。

   5….

   用户故事只是描述系统的外在行为

   一个用户故事只是以客户能够明白的方式，描述了一个系统的外在行为，它完全忽略了系统的内部动作。比如，下面有下划线的那些文字，就属于不应该出现在用户故事中的系统内部动作：

   1. 用户投入一些钱。

   2. 售货机将塞进来的钱存在钱箱里，然后发送一条命令给屏幕，屏幕显示目前已经投入的金额。

   3. 售货机查询数据库里面所有饮料的价格，判定钱足够买哪些饮料，对于钱足够买的那些饮料，对应的按钮的灯就会亮起来。

   4. 用户按下一个亮起来的按钮。

   5. 售货机卖出一罐饮料给用户，然后将数据库里面该饮料的存货数量减1。

   6. 售货机找零钱给用户。

   不管是口头描述的，还是书面形式，这样的内容是描述用户故事时一个很常见的错误。特别的，千万不要提及任何有关数据库，记录，字段之类的对客户一点意义都没有的东西。

   评估发布时间

   用户故事是用来干嘛的？假定客户希望在50天内递交这个系统。我们做得了吗？为了解答这个问题，我们就要在项目开始的阶段，试着找出所有的用户故事，然后评估一下，每一项历程需要多长的开发时间。可是，怎么评估呢？
   比如，我们现在收集了下面这些用户故事：

   卖饮料：如上面所说的。
   取消购买：在投入了一些钱后，用户可以取消购买。
   输入管理密码：授权的人可以输入管理密码，然后增加存货，设定价格，拿走里面的钱等等。
   补充饮料：授权的人可以在输入管理密码后增加存货。
   取出钱箱里的钱：授权的人在输入管理密码后，可以取出钱箱里的钱箱里面的钱。
   安全警报：有些事情经常发生的话，系统会自动打开安全警报。
   打印月销售报表：授权的人可以打印出月销售报表。

   然后找出里面最简单的用户故事（这里的“简单”，意思是说实现周期最短）。我们不一定非常精准的判断哪个最简单。只要挑出你觉得最简单的就行了。比如，我们觉得“输入管理密码”是最简单的用户故事。然后我们判断说，这个用户故事算1个“故事点（story point）”。

   用户故事故事点
   卖饮料
   取消购买
   输入管理密码 1
   补充饮料
   取出钱箱里的钱
   安全警报
   打印月销售报表

   不过一般我们不会列出清单，而是做出一堆卡片贴在墙上，每张卡片记录一个用户故事，然后将故事点写在卡片上面：

   

   这样的一张卡片就叫“故事卡（story card）”。

   然后开始考虑其他用户故事。比如，对于“取出钱箱里的钱”这个故事，我们认为它跟“输入管理密码”这个故事一样简单，所以它应该也是算1个故事点。我们在列表里面标上。当然，实际操作的时候，我们是在“取出钱箱里的钱”的故事卡上填上故事点。
   用户故事故事点
   卖饮料
   取消购买
   输入管理密码 1
   补充饮料
   取出钱箱里的钱 1
   安全警报
   打印月销售报表

   对于“取消购买”，我们认为它应该是“取出钱箱里的钱”的两倍的工作量，所以它算2个故事点。
   用户故事 故事点
   卖饮料
   取消购买 2
   输入管理密码1
   补充饮料
   取出钱箱里的钱1
   安全警报
   打印月销售报表

   对于“卖饮料”，我们认为它应该是“取消购买”两倍的复杂度，所以它应该算4个故事点。
   用户故事 故事点
   卖饮料4
   取消购买2
   输入管理密码 1
   补充饮料
   取出钱箱里的钱 1
   安全警报
   打印月销售报表

   对于“补充饮料”，我们又认为它比“取出钱箱里的钱”复杂，但又比“卖饮料”简单，然后它又应该比“取消购买（２个故事点）”复杂，所以我们认为它应该是3个故事点：
   用户故事故事点
   卖饮料4
   取消购买2
   输入管理密码 1
   补充饮料3
   取出钱箱里的钱 1
   安全警报
   打印月销售报表

   类似的，我们认为“安全警报”应该比“补充饮料”简单一些，所以应该是2个故事点：
   用户故事故事点
   卖饮料4
   取消购买2
   输入管理密码 1
   补充饮料3
   取出钱箱里的钱1
   安全警报2
   打印月销售报表

   “打印月销售报表”应该跟“卖饮料”一样复杂，所以应该是算4个故事点，这样的话，我们总共有17个故事点：
   用户故事故事点
   卖饮料4
   取消购买2
   输入管理密码1
   补充饮料3
   取出钱箱里的钱1
   安全警报2
   打印月销售报表4
   总计17

   现在挑出任意一个用户故事，估计一下它要花（你一个人）多少时间来完成。假设我们之前做过跟“取出钱箱里的钱”类似的功能，所以我们就挑这个来计算，估计它要花5天的时间。也就是说，一个故事点要花5天的时间来完成。现在我们有17个故事点，也就是说，我们需要17×5＝85天来完成这个项目（如果只是一个开发人员来做的话）。假设现在我们的团队里面有两个开发人员，所以我们就需要85÷2＝43天来完成。

   从目前的估计来看，我们可以在50天的期限里面做完这个项目。但现在说这个还太早了！这样的评估，更多的是猜测。通常开发人员在工作量上的估算都很差。事实上，人们经常会低估了工作量。那我们应该怎么估计得更准？

   我们实际的开发速度是多少

   为了做到更准的估计，我们就让客户先给我们两周的时间做一些实际的开发，来测量一下我们在这两周里面可以做多少的用户故事。我们叫这两周的时间为“迭代周期”。

   哪些用户故事应该放在第一个迭代周期里面做？这可能完全是客户决定的，也可能是大家讨论以后决定的。不过挑出的这些用户故事的故事点不应该超过这两周的承受能力。因为一个迭代周期有10天（假设我们周末不工作），然后我们估计一个开发人员5天可以完成一个故事点。现在我们有两个开发人员，所以我们应该可以在这个迭代周期中完成（10÷5）×2＝4个故事点。

   然后客户可以在总故事点不超过４的前提下，挑出一些用户故事在这个迭代周期里实现。他们可能会尽量挑选他们觉得最重要的故事。比如，对他们来说，销售报表跟找零钱最重要，所以他们就挑出这两个：
   用户故事故事点
   取出钱箱里的钱1
   打印月销售报表2
   总计3

   假设两周的迭代周期过去了，我们完成了“取出钱箱里的钱”，不过“打印月销售报表”没有完成，还剩0.5个故事点没有完成。也就是说，我们在这个迭代周期内完成了3-0.5＝2.5个故事点（比原来的预计要差一些）。

   2.5个故事点这样的数值，就是我们现在的参考值。也就是说，这个团队每个迭代周期可以完成2.5个故事点。这个参考值对我们很有用。它有两个用处：
   首先，我们可以假定我们在下个迭代周期也可以完成2.5个故事点，然后客户选择的用户故事的故事点总和不能超过2.5。
   其次，在从第一个迭代周期取得参考值以后，我们可以重新估算我们的发布时间了。本来我们估算我们每个开发人员完成1个故事点的时间是5天，现在我们有了实践后的数据了，我们的团队（两个开发人员）可以在一个迭代周期（10天）内完成2.5个故事点。现在总的故事点是17，计算一下，我们需要17÷2.5＝7个迭代周期来完成。14周，也就是70天。也就是说，我们满足不了客户提出的期限（50天内）！怎么办？

   预计不能如期完成时怎么办？

   很明显，现在我们完成不了全部的用户故事。在这50天里面，我们只能完成50÷10×2.5＝12.5个用户故事。因为现在有17个故事点，我们应该让客户挑出总计4.5个故事点的用户故事，推迟到下一个发布周期去。客户应该选择那些比较次要的用户故事。比如，客户可以推迟“打印月销售报表”这个用户故事。

   （这只是开发不能如期完成时的解决方法之一，这种方法应该是在客户比较有诚意合作的前提下使用。）
   用户故事故事点
   卖饮料4
   取消购买2
   输入管理密码1
   补充饮料3
   取出钱箱里的钱1
   安全警报2
   总计13

   然后他还要挑出总和至少为0.5个故事点的故事。

   但是如果“月销售报表”这个用户故事对客户来说也是非常重要，而且其他的故事也不能推迟，这时怎么办？这时我们就要试着简化这些用户故事。比如，原来“月销售报表”是要用一个第三方报表库来实现的，而且还要画出饼状统计图，如果我们只是生成简单的文本格式的报表的话（这格式应该可以被Excel导入，以便日后的处理）。那么这个用户故事的故事点就会从4减少到2，节省了2个故事点。如果客户同意的话，我们就可以将“打印月销售报表”分成两个用户故事“生成月销售文本报表”和“生成图形报表”，然后将后者推迟到下一个发布。

   现在新的故事卡片出来了：
   用户故事故事点
   卖饮料4
   取消购买2
   输入管理密码 1
   补充饮料3
   取出钱箱里的钱1
   安全警报2
   打印月销售文本报表2
   总计15

   还有其他的2.5个故事点要推迟，我们可以简化“卖饮料”。假设本来我们可以卖不同价格不同类别的饮料。如果现在我们只是简单支持一种价格一种类别的饮料的话，那这个用户故事的故事点可以从4减到2了。客户如果同意的话，我们就可以将“卖饮料”分割为“卖单一饮料”和“卖多种饮料”，然后将后者推迟到下个周期发布：
   用户故事故事点
   卖单一饮料2
   取消购买2
   输入管理密码1
   补充饮料3
   取出钱箱里的钱1
   安全警报2
   打印月销售文本报表2
   总计13

   现在还剩0.5个故事点，我们再考虑一下“安全警报”。假设本来这个故事是要同时触发本机上的警报，跟通知附近的一个警察局的。如果现在我们只是触发本机的警报，那所花的故事点就可以从2减到1了。于是在客户同意的情况下，我们将“安全警报”分割为“本机安全警报”和“通知警察”，然后将后者推迟到下个发布：
   用户故事故事点
   卖单一饮料2
   取消购买2
   输入管理密码 1
   补充饮料3
   取出钱箱里的钱1
   本机安全警报1
   打印月销售文本报表2
   总计12

   现在我们总计有12个故事点要做了（lt;=12.5）。上面这个筛选在本次发布的用户故事的过程，叫“发布计划编制”。

   增加开发人员来满足发布期限

   在上面的例子中，我们以推迟部分用户故事到下个发布周期的办法来解决问题。这种“控制开发范围”通常是最好的解决办法。不过，这种解决办法实施不了的情况下，那你就只好保留所有的用户故事，然后增加更多的开发人员了。在这个例子中，假定我们需要“n”个开发人员，才能在50天内完成17个故事点。50÷10×2.5×n÷2.算出来，n＝2.7，我们需要3个开发人员，也就是多加一个开发人员进来。不过注意：
   团队人数加倍并不等于开发周期的减半。它可能只会缩短1/3。如果团队超过10个人的话，增加更多的人员可能反而会延缓项目的进度。
   而且项目开发周期越长，团队内的成员对整个项目代码的熟悉度就越少，加上不确定的人员流动，新来人员的业务不熟等其他可能性，这项目会越来越复杂。
   总的意思就是，项目人数不能太多，周期不能太长。

   根据参考值来掌控项目

   每个迭代周期2.5个故事点的这个参考值，只是第一个迭代周期的数据，第二个迭代周期可能会变成2或者3（一般是不会变动得太大）。假设是2的情况下，那对于第三个迭代周期，我们就要将参考值设为2，然后让客户以2为故事点总数来挑选用户故事。
   对于大多数项目，参考值很快就会稳定下来（比如在几个迭代周期后）。当这个值稳定下来后，我们就要重新估计开发周期，重新进行“发布计划编制”了。如果这个参考值告诉我们，我们每个迭代周期可以做3个故事点的话，我们就要让客户挑选更多的用户故事放在这次的发布计划中。相反如果这个参考值是2的话，我们就要让客户减少用户故事（需要的话可以分割一些用户故事），如果团队人员还不多的话，可以增加更多的开发人员。

   这是项目的初始阶段绝对要注意的。

   发布计划编制，估算每个用户故事时要考虑哪些细节，忽略哪些细节？

   在项目初始，我们要找出这个发布周期内所有主要的用户故事，评估每个故事的故事点。可是要怎么评估里面的细节呢？比如对于“卖饮料”， “卖饮料”这个简单的标题，省略了很多的细节：用户会投入什么样的钱？纸币可以吗？人民币可以吗？按钮的灯的亮度要多少？可不可以多个按钮对应一种饮料？按钮被按下以后，要不要变暗？找零钱是不是全部找10分的面额？
   我们是不是要考虑上面所有的细节？对于按钮灯的亮度，我们就不用考虑了，它对我们的工作量没影响。不过，零钱的面额就对我们的工作量很有影响，我们要认真考虑一下（找一堆10分的零钱就很容易实现；如果要尽量减少零钱的个数就比较麻烦了）。处理不同币种也要考虑。
   一般情况，我们不用太担心会漏过什么细节。对于每个用户故事，只要考虑一些“重要”问题就行了。当然，这里面的“重要”，就要根据经验以及客户的观点来决定了。

   如果我们不好估算的话怎么做

   如果我们觉得，这个用户故事不好估算，那可能的原因就是：

   1.这个用户故事太大。这种情况我们就可以将这个用户故事分割出若干个新的用户故事，比如：
   将“卖饮料”分割出：
   1：显示总投入金额。
   2：金额够买的饮料对应的按钮灯亮起来。
   3：按下亮灯的按钮，可以买到对应的饮料。
   2.我们之前从没开发过自动售货机的程序。因此，我们不知道开发这样的程序有多复杂。这样的话，我们就要做一些实验了，比如做一个让售货机找钱的小程序。这种试验就叫“spike”（翻译不出来）。

   迭代周期内的计划编制

   对于这个迭代周期内选择的所有用户故事，不像在发布计划编制那样，只是考虑一些重要的细节，现在我们要从客户那里调查到所有的细节。比如对于“卖饮料”，我们可能会在白板上画出用户交互的草图，然后跟客户一起讨论：
   这是一台自动售货机……
   用户投入硬币……
   假设他投入的是50分，而价格是40分，那么按钮就会亮起（别忘了我们现在做的只卖单一饮料）
   用户按一个亮起的按钮，一罐饮料会掉到售货机的出口
   找零钱……

   在跟客户详细讨论完，了解了足够的细节以后，我们才发现，事实上这个用户故事“卖饮料（只卖单一的）”的故事点远远比我们预计的要麻烦，这时候应该类似前面的发布计划编制那样，1、分割出小的用户故事，挑出一些放在下一个迭代周期内；或者2、挑出这个迭代周期内的一些用户故事放在下一个迭代周期。反之，如果发现这个用户故事比我们想像的还要简单，那我们就要增加更多的用户故事到这个迭代周期内。

   用户故事只是跟用户交流的开始，而不是全部

   假想现在已经从客户那边得到足够详细的需求了，我们可以开始实现了。注意，我们不用把所有用户提供的细节都记录下来。为什么呢？假设以后，你有点忘记用户故事，而客户又在你旁边，你是直接问客户，还是去找看需求文档找到你要的东西？当然是直接问客户了。客户可以提示更准确，更完整的需求给你。特别要注意的是，以后只要你一完成一个用户故事，你就要让客户看一下，或者实际的操作一下，因为客户对已经做的的东西了解得越多，那他就可以提供越准确越完整的需求。
   用户挑选完用户故事以后，在之后的两个星期内，我们就要将这些用户故事逐个完成。每个用户故事我们都会设计结构，编码，测试等等。每做完一个用户故事，我们都要让客户验证一下系统是不是他所想的那样。

   在这两个星期内，如果我们提早完成了用户故事，我们就要让客户挑更多的用户故事。相反的，如果我们不能及时完成，我们就要让客户知道当前的进度。

   总结

   ]]> http://adam.ofeva.com/blog/44.html/feed 0