taibo 2009-10-12
前端技术
6条评论

JavaScript 组件之旅（四）：测试 JavaScript 组件

目录：

  1. 分析和设计组件
  2. 编码实现和算法
  3. 用 Ant 构建组件
  4. 测试 JavaScript 组件

smart-queue-test
本期，我们要讨论的话题是 JavaScript 的测试，以检查组件的状态和工作方式是否符合预期，还会介绍一个可以方便编写测试用例的测试方法。这里说的测试当然是使用自动化的测试手段，这是软件质量保证(QA)的重要环节。就本系列文章介绍的 Smart Queue 来说，我们的测试目标包括：

  • Task 对象的创建：第二期的代码提供了多种创建方式，需要测试对象创建后的状态。
  • Queue 内的任务运行次序：我们提供了两种改变运行次序的方式：优先级和依赖配置，同样也要测试各种配置对次序的影响。

对于第一个目标，只需检查对象创建后的属性是否符合预期即可。我们已经多次提到“符合预期”，断言(Assert)正是为此而设计的。简单的说，断言就是确保所测试的表达式结果为“真”，否则，以某种方式通知测试人员，并帮助其定位断言失败的测试用例。
第二个目标稍稍有点复杂。由于我们在组件编码实现的时候，将排序后的队列( [/cci]_sorted [/cci])隐藏在了闭包中，所以外部是无法访问的。有两种方法可以考虑：(1)重构代码，增加代码的可测试性，又有两种重构方法：(a)设置 debug 开关，打开时将 _sorted 暴露给外部；(b)增加独立文件，以构建的方式拼接代码最终生成一个测试版本。(2)测试行为的结果而不是过程，前一种方法实质上是深入到组件的运行时状态，而这个方法只是检查组件的运行结果。本期选用后一种种测试方式，第一种测试方式留给有兴趣的读者练习:)

需要说明的是，我个人不赞成第一种的方法a. 为什么呢？我先说一下这个任务队列的设计理念： ..

6 continue reading
taibo 2009-10-04
前端技术
5条评论

JavaScript 组件之旅（三）：用 Ant 构建组件

目录：

  1. 分析和设计组件
  2. 编码实现和算法
  3. 用 Ant 构建组件
  4. 测试 JavaScript 组件

我们走到哪儿了？前两期思考了太多东西，你是否已有倦意？别担心，本期的话题很轻松，你只需要简单了解一些语法，写几行配置，就能驱使系统按你预设的方式自动完成一些工作。听起来是不是很惬意？Let’s go! 我们出发啦～

这期，我们会使用 Ant 将上期编写、整理的代码文件按指定的先后顺序合并成单一的源文件，然后压缩这个文件。这是构建 JavaScript 项目的基本步骤。Ant 是 Apache 的一个顶级开源项目，网上对它的介绍和安装，已经有很多文章，这里就不再赘述了。在构建之前，我们先来看看已有的文件布局：

  smart-queue  // 组件的根目录
    +--- src  // JavaScript源文件目录
        +--- lang.js  // 前文提到的“外部文件”
        +--- smart-queue.js  // Smart Queue 主文件

现在，我们要让它“丰满”起来： ..

5 continue reading
taibo 2009-09-27
前端技术
8条评论

JavaScript 组件之旅（二）：编码实现和算法

目录：

  1. 分析和设计组件
  2. 编码实现和算法
  3. 用 Ant 构建组件
  4. 测试 JavaScript 组件

话说上期我们讨论了队列管理组件的设计，并且给它取了个响亮而独特的名字：Smart Queue. 这次，我们要将之前的设计成果付诸实践，用代码来实现它。

首先，我们要考虑一下它的源文件布局，也就是决定代码如何拆分到独立的文件中去。为什么要这么做呢？还记得上期结尾处我提到这个组件会使用“外部代码”吗？为了区分代码的用途，决定将代码至少分成两部分：外部代码文件和 Smart Queue 文件。
区分用途只是其一，其二，分散到独立文件有利于代码的维护。试想，以后的某一天你决定要在现有的队列管理基本功能之上，添加一些新的扩展功能，或是把它包装成某个实现特定任务的组件，而又希望保持现有功能（内部实现）和调用方式（对外接口）不变，那么将新的代码写到单独的文件是最好的选择。

嗯，下期会重点谈谈文件布局的话题，现在要开始切入正题了。第一步，当然是要为组件创建自己的命名空间，组件所有的代码都将限制在这个顶层命名空间内：

var SmartQueue = window.SmartQueue || {};
SmartQueue.version = '0.1';

初始化的时候，如果碰到命名空间冲突就把它拉过来用。通常这个冲突是由重复引用组件代码导致的，因此“拉过来用”会将对象以同样的实现重写一次；最坏的情况下，如果碰巧页面上另一个对象也叫 SmartQueue, 那不好意思了，我会覆盖你的实现——如果没有进一步的命名冲突，基本上两个组件可以相安无事地运行。同时顺便给它一个版本号。

接着，按三个优先级为 SmartQueue 创建三个队列：

var Q = SmartQueue.Queue = [[], [], []];

每个都是空数组，因为还没有任务加进去嘛。又顺便给它建个“快捷方式”，后面要访问数组直接写 Q[n] 就可以啦。

接下来，我们的主角 Task 隆重登场——怎么 new 一个 Task, 定义在这里：

    var T = SmartQueue.Task = function(fn, level, name, dependencies) {
        if(typeof fn !== FUNCTION) {
            throw new Error('Invalid argument type: fn.');
        }
        this.fn = fn;
        this.level =  _validateLevel(level) ? level : LEVEL_NORMAL;

        // detect type of name
        this.name = typeof name === STRING && name ? name : 't' + _id++;

        // dependencies could be retrieved as an 'Object', so use instanceof instead.
        this.dependencies = dependencies instanceof Array ? dependencies : [];
    };

..

8 continue reading
taibo 2009-09-20
前端技术
7条评论

JavaScript 组件之旅（一）：分析和设计

毫无疑问，JavaScript 是一种非常灵活的脚本语言，有时候它像一只难以驯服的野马——你受益于它的灵活性的同时，也要时刻提防它变得失去控制；另一方面，由于 JavaScript 通常会和宿主环境（比如浏览器）紧密结合，因此缺乏功能强大而简单易用的开发工具。在这样的环境中，开发组件或框架成为一项具有挑战的工作。
这次，我们将以一个简易的 JavaScript 组件开发为契机，逐步展开组件的分析、设计、实现、构建和测试等任务，探讨组件开发过程涉及的方方面面。这些探讨将分 4 篇陆续张贴出来（链接将在张贴后更新）：

  1. 分析和设计组件
  2. 编码实现和算法
  3. 用 Ant 构建组件
  4. 测试 JavaScript 组件

现在，假设我们要从头开始设计并实现一个队列管理组件，先让我们来认识一下队列：

Queue

Queue

图片来自 Wikipedia.

队列是一个“先进先出”(FIFO) 的数据结构，只能向它的尾巴追加项，项从头部取出使用，这个规则将应用到我们所探讨的组件中去。对于队列，相信学过 C 或是数据结构课程的同学已有所了解，如果你已经把它还给了老师，请使用搜索引擎简单了解一下队列的知识。

这个队列管理组件具体要实现的功能是：它是个任务管理器，按高、中、低优先级维护着三个任务队列，客户（使用者）可以在任何时候把想要执行的任务添加到某个队列，可以指定任务运行的上下文，并传给它必要的数据。客户也可以随时运行这个队列，队列里的任务按照指定的依赖关系以合理的方式依次运行。

为了不至于使组件过于简单而缺乏实用性，我们特意给它添加了一些“糖”：分优先级、传入上下文和数据、处理依赖关系。如果把上面这段理解为需求的话，那么首先，我们要从中提取出最重要的关键词，它们直接决定了这个组件应该如何设计：

  • 队列
  • 优先级
  • 依赖关系

然后，我们从中提炼出涉及的对象：

  • 任务管理器 (TaskManager): 从目前需求来看，它只需要一个实例。
  • 队列 (Queue): 每个优先级对应一个队列，由 TaskManager 管理这三个 Queue 实例。
  • 任务 (Task): 描述添加的任务，放在相应优先级的 Queue 里面。
  • 依赖 (Dependency): 描述单一的依赖，即 Task1 依赖 Task2, 显然某个 Task 可能具有多个依赖。

..

7 continue reading
sofish 2009-01-16
交互设计 前端技术
39条评论

浅谈产品设计中的可用性和可访问性

在用户体验这个行业，经常会听到，可用性，可访问性这样专业的名词，但是，事实上在很多产品实现过程里都忽略了这一点！WHY？

举个很简单的例子，用户的注册流程，很多交互设计师在做这块流程设计的时候都无可避免的忽略了部分可用性和可访问性，直白点说，产品的应用场景没有cover全用户群，损害了这部分用户的可用性和访问性。

太抽象？不明白？好，那我们就用户注册流程展开，侃侃流程中用户提交表单的设计。

支付宝注册流程

看上图，这是现有支付宝注册流程中的一块功能，要实现的功能很简单，个人用户直接填写注册信息，是企业用户的话，就先选择企业，再填写注册信息，最后提交表单，完成操作。流程早就发布上线了，看上去很和谐，但是不然……

..

39 continue reading