译自“Professional Web APIs with PHP: eBay,
Google, PayPal, Amazon, FedEx, Plus Web Feeds” (chapter 12)

你一定听过这样一句话“失败的计划是必定失败（Fail to plan, and you plan to fail.”对WebAPI来说，在开始一切工作之前的规划尤为重要，因为他不仅会影响到实现难度，同时会让那些使用API的开发者痛苦不堪。

通常来说，引入额外的安全层次会更好的保护你的API，但是同时需要很好的平衡这种设计对易用性的影响。时刻记得，安全即是保护你的数据，也是确保开发者的调用过程完整（通常是用“token”）。

完全开放的API

在一个完全没有安全验证机制的开放API里，首先会有一个来自外界的请求，然后系统会尝试完成并响应这个请求。

优点:

• 最小的使用障碍 – 既没有加密页没有验证机制，任何人都可以访问你的API。
• 更容易的创建分布式应用 – 登录帐户或者程序员，只要他们使用了你的API，那么程序可以分布到任何地方,而你根本无需考虑他们在哪里调用。
• 省心 – 如果你没有管理用户账户和开发密钥，那就可以花更多的时间在开发API本身。

缺点:

• 缺少控制 – 任何人在任何地方都可以调用API，尽管这是web服务的目标，但可能会在潮水般的请求涌来时失去控制。如果这些请求只是来自一部机器，还可以借助防火墙来搞定，但是如果分布很广，处理起来就会很痛苦。
• 没有加密 – 所有请求端和服务端的请求和响应都是对任何人都可见的。
• 无法接触到开发者 – 因为API的调用不存在注册过程，也就无法联络到相应的开发者。而你可以通过注册机制建立一个与开发者的一个很好的联系。比如，告知他的应用正在被误用，API有新的改动，征求改进建议等等。
• 误用 – 很不幸，总有一些人会利用这一点去做一些不好的事，即便你觉得这个可能性很小。

因为这些问题，完全开放的API只适用于用来请求信息，而不是发布信息 – 也就是请求的信息资源产生过程不会占用太多CPU资源。一个很恰当的例子是国家天气服务API，它只接受信息请求，并且这些请求可以全天候的缓存在服务器上。如果是需要发布信息，那么相应的验证机制要被用来识别请求者，当请求需要消耗大量CPU时，远端程序需要被识别出来，从而对发来的请求进行过滤和控制。

HTTP 验证

通过HTTP头包含中验证信息，基于Base64编码，实际上并没有加密，没有信息安全可言。

优点：

• 简单 — 因为验证信息是在HTTP头里，所以可以被路由器和网关处理。从而可以用硬件过滤和筛查客户端请求。从应用的角度来看，验证实际上是发生在服务器端，因此设计服务器时应该考虑到高性能和高并发的开发和测试。
• 对应用来说透明 -  因为是web服务器来处理验证，你可以完全不需要考虑用户登录问题。当然这只适用于请求那些于特定用户无关的信息（每个用户使用相同的请求得到相同的信息）。
• 易于编码 — 添加一个额外的HTTP头信息对大多数编程语言来说都不在话下。It is also pretty universally available even in shared hosting situations (which may prevent things like SSL requests or external libraries).

缺点:

• 验证信息是明文传输的 — Base 64是可逆算法，任何人都可以从传输的信息中得到用户名和密码，但实际都不需要这样做，只需要修改HTTP头即可。
• 用户名限制 — 当使用HTTP验证时，冒号(:) 不可以作为用户名的一部分。
• 没有加密 — 所有请求和响应都是可见的。

这种基本的验证方式对大多数API应用已经足够了，基本的验证允许API既可以是客户相关也可以是客户无关的，取决于是否需要。同时允许过滤那些有问题的客户端。更好的办法是将用户名和密码组合分开，这样验证信息可以有点保护，合法用户可以使用其他信息去修改API的使用权限。

服务器端代码

大多数工作都是由web服务器来完成的。Apache可以使用一个文本文件查找用户帐号，但如果API允许用户信息修改，那么这不是一个明智的选择。Apache可以使用Berkeley数据库（如果你设置了mode_db或者mode_dbm模块），BerkeleyDB在大多数linux版本里都是标准组件，如果没有安装，可以从www.sleepvcat.com下载。要使用BerkeleyDB，PHP需要配置“-with –db4”选项，相应Apache必须要使用“—enable-module=auth_db”选项编译。

Httpdconf要配置为（(.htaccess也要类似配置):

<Directory /www/domains/api.example.com >

  AuthName "API Requires Registration"

  AuthType Basic

  AuthDBUserFile /www/basicAuth/api.example.com/passwords.dat

  require valid-user

 </Directory>

Directory参数指定被保护的文件夹
AuthName指定当浏览器访问该目录时显示给用户的消息
AuthType 设置为 basic,即基本HTTP验证方式
AuthDBUserFile Berkeley数据库的文件路径，它应该是web文档根目录以外的地方 – 你不想让攻击者可以下载它吧
require 指明想要访问目录的用户必须存在于数据库中

上面这些的前提是用户可以被添加到数据库中，那么用户如何添加呢？请看下面这个函数：

function createUser($username, $password)

{

  $chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";

  $r1 = rand(1, strlen($chars) - 1);

  $r2 = rand(1, strlen($chars) - 1);

  $salt = substr($chars, $r1, 1) . substr($chars, $r2, 1);

  $saltedPassword = crypt($password, $salt);

  $resource = dba_open("/www/basicAuth/api.example.com/passwords.dat", "c", "db4");

  if (dba_insert($username, $saltedPassword, $resource))

  {

    dba_close($resource);

    return true;

  }else

  {

    dba_close($resource);

    return false;

  }

}

该函数最重要的部分是用dba_open()函数打开数据库（第二个参数“c”指定如果文件不存在则创建他， “db4”是数据库类型）,插入用户名和密码，然后关闭数据库连接。

下面这个函数是删除用户:

function deleteUser($user)

{

  $resource = dba_open("/www/basicAuth/api.example.com/passwords.dat", "c", "db4");

  dba_delete($user, $resource);

  dba_close($resource);

}

最后，你应该想要通过API脚本访问用户信息：

$username = $_SERVER['PHP_AUTH_USER'];

$password = $_SERVER['PHP_AUTH_PW'];

这两个变量都存储与$_SERVER这个全局数组里，password是明文存储的，需要记住，用户这时已经通过了验证，因此这些信息只是用来存放基本数据罢了。

客户端代码

要访问API，客户端程序需要发送一个包含了用户名和密码（Base64加密过的）的HTTP头。

$authorization = base64_encode("username:password");

首先用户名和密码必须要用内置函数进行编码，“username:password”则是HTTP 规范制定的格式。

fputs($fp, "Authorization: Basic $authorization\r\n");

在socket连接过程中，验证头始终都和HTTP头部一起发送。

基于消息的验证

客户端验证信息也可以和一般的消息一起发送。因为增加一个验证信息对客户端代码来说并不是多大的负担。请记住，即便使用了SSL，URL仍然是以明文传输的，也就是说如果验证信息是通过URL传递的（REST请求），那么它对传输途中的任何人都是可见的。

优点:

• 处理简单 – 每次处理都进行验证，如果一个普通页面。
• 容易编码 – 程序员只需要增加一个额外的参数（验证信息）
• 方便跟踪 – 可以容易地配置统计某一段时间里有多少次调用，根据情况进行限流。

缺点:

• 验证信息是明文 – REST APIs会将验证信息以明文发送无论是否使用了安全的接入点。不安全的接入点也会把验证信息以明文格式发送，无论是REST还是SOAP。
• 没有加密 – 所有请求和响应都是对可见的。

基于消息的验证和HTTP验证很相似，最主要的不同是由谁来处理验证过程，HTTP是通过服务器，而基于消息的验证则是通过API本身。

服务器端代码

切记验证信息应该和站内的其他验证信息分开。下面是一个基本的验证函数。

function checkUser($username, $password)

{

  $query = "SELECT `user_level` FROM `users` WHERE `username` = ‘$username' AND

    `password` = '$password'";

  $results = getAssoc($query, 1);

  return $results[‘level'];

}

客户端代码

取决于服务器端使用的是SOAP还是REST，这部分在后面的“REST？还是SOAP”中有讨论。

SSL 接入端

配置web服务器支持SSL连接可以保护请求和响应内容，同时又不需要额外编码。服务器端证书认证只能用来确认服务器而不能用来识别验证客户端。所以仍然需要前面两种验证机制。

优点:

• 加密 – 请求和响应内容都被加密，从而不会存在被监听的问题。
• 服务器验证 – 客户端可以根据SSL证书来确认服务端没有改变。使用签名机构的证书同样可以达到这样的目的。
• 配置简单 – 没有额外编码，只需要配置web服务器。

缺点:

• 增加了服务器负担 – 加密和解密的过程本身就需要占用较多的CPU资源，每个请求都会需要一个额外的握手过程来建立安全套接字。
• 没有客户端验证 – 使用了SSL。
• 增加了客户端负担 – 处理SSL对客户端来说通常都会比较繁琐，可能需要安装相应的扩展包才能实现（在共享主机环境下可能会比较麻烦）。

SSL对任何API都是很重要的安全机制。它提供了对请求和响应内容的保护，以及服务器的识别。并且很容易和HTTP认证或基于消息的认证结合。但是也要根据特定情况决定是否使用SSL，因为它毕竟会增加一些负担给服务器和客户端。

服务器端代码

不需要代码，只需要配置web服务器。

客户端代码

要连接SSL接入端，PHP需要配置“--with-openssl”选项。同时要看服务器是否支持SSL，从phpinfo()输出中看是否在Registerd PHP Streams有“https”。

客户端证书

API服务器可以为每个客户端生成一个证书来建立安全的信息传输，然后这个证书会被用在验证过程，确认服务器和客户端身份。尽管这种方法提供了最高级别的安全，但它也是要求对服务器端和客户端最严格的：并非所有的工具（比如NuSOAP）都支持客户端证书。

优点:

• 身份确认- 服务器和客户端的身份都得到了确认。
• 加密 – 请求和响应内容都被保护，不会被第三方监听。

缺点:

• 增加了处理 – 因为需要建立安全套件字，额外的工作不可避免。
• 服务端额外负担 – 服务器需要为每一个客户端都生成证书，并且要确保这些API必须要存放安全的地方，通过安全的传输通道。

客户端证书确保了客户端和服务端的身份，可以一定程度上保证API的安全，但是它的代价也是很明显的 - 客户端和服务器端的CPU的负担，并且无法使用一些方便的客户端工具与API交互。

服务器端代码

设置客户端证书需要一定量的工作，你很难说服所有试图使用API的客户去花钱申请自己的证书。你也可以提供授权给客户，但这样也有一些不安全的问题 – 你必须要像一个真正的授权机构一样小心。但这仍然是一个相对轻松的解决办法，接下来我们详细介绍一下：

1. 设置证书授权。最好是使用一个独立的服务器来保存CA的私钥，而不是用web服务器，理想情况下，这台服务器最好不要接入互联网，而只可以连接请求密钥的机器，因为API需要不停请求它生成密钥。
2. 为你的用户生成密钥，同时使用安全的连接分发。如果使用不安全的方式去分发，比如HTTP，甚至email，那么还不如不生成。因为完全没有必要去生成。
3. 配置web服务器只接受生成的证书，用户必须提供由你签名的证书。
4. 配置服务器使用SSL认证。

建立你的认证（CA）

OpenSSL可以很好的完成这项工作，它包含两个很重要的脚本，CA.pl和CA.sh，可以自动完成这个过程。其他类似OpenCA或者TinyCA提供了界面更友好的方案。 考虑到你只需要做一次，那么太过友好的界面并不是很必要。

首先需要修改CA脚本，其中有一行代码：

$DAYS="-days 365"

定义了证书的有效期为一年以内（365天），如果觉得太短，可以设置一个大一点的值，比如10年。.

其次，运行脚本时需要回答有关于公司的问题， common name这一项很重要- 它应该被配置为API的主机名，记得使用一个健壮的密码。脚本执行时会生成一个demoCA的文件夹，里面放置了所有生成好的文件。

最后，生成服务器端证书。分两步，第一步，生成认证签名请求（Certificate Signing Request, CSR）；第二部，使用CA对CSR进行签名。下面是用openssl生成CSR的命令：

openssl req -new –key server.key –out server.csr

openSSL在生成密钥之前会问一系列问题，这些需要和你创建CA时的信息匹配，以免增加不必要的额外配置。要为生成的CSR签名，首先需要把CSR文件（server.csr）重命名为newreq.pem，然后使用下面这条命令：

CA.sh –signreq

它会为请求签名，最后必须要配置Apache服务器使用证书，需要修改虚拟主机的httpd.conf文件，增加如下信息：

SSLEngine On

SSLCertificateFile /etc/http/conf/ssl/server.crt

SSLCertificateKeyFile /etc/http/conf/ssl/server.key

SSLProtocol All –SSLv2

SSLCipherSuite ALL:!EXP:!NULL:!ADH:!LOW

前三行用来打开SSL引擎、设置证书路径和服务器私钥路径。最后两行用来阻止SSL使用不安全的协议。

第四，生成客户端证书：

CA.sh –newreq

CA.sh –signreq

记得通过安全的渠道分发给用户。

第五，配置web服务器要求客户在试图建立连接时提供证书，同时确保证书是由你签名和创建的。

SSLCACertificateFile /etc/http/conf/ssl/demoCA.crt

SSLCARevocationFile /etc/http/conf/ssl/demoCA.crl

SSLVerifyClient require

SSLVerifyDepth

SSLCACertificateFile 要指向你放置CA证书文件的位置， SSLRevocationFile 要指向.crl文件（该文件是和*.crt文件同时生成的），没有这个文件，你就无法取消非法用户（或者不在使用API的用户）。SSLVerifyClient 指明所有用户必须提供证书，否则将拒绝连接。最后， SSLVerifyDepth 1 指定所有客户端证书必须是由你的CA直接生成的，这避免了其他用户创建合法的客户端证书。最后要重启Apache来使这些配置生效。

客户端代码

要连接有安全的接入端，PHP需要配置“--with-openssl” 选项,同时要确定phpinfo()的输出中有SSL支持（Registered PHP Stream列表），并且在Registered Stream Socket Transports 中也存在SSL项。

因为必须要提供客户端证书，所以还要使用cURL库。它适合用来调用SOAP和REST API，处理请求和响应都很类似：

function callAPI($endpoint, $requestBody)

{

  $ch = curl_init();

  curl_setopt($ch, CURLOPT_URL, $endpoint);

  curl_setopt($ch, CURLOPT_SSLCERT, "../certs/cert_key_pem-1.txt");

  curl_setopt($ch, CURLOPT_POST, TRUE);

  curl_setopt($ch, CURLOPT_POSTFIELDS, $requestBody);

  ob_start();

  curl_exec($ch);

  $response = ob_get_clean();

  if (curl_error($ch))

 {

   file_put_contents("/tmp/curl_error_log.txt", curl_errno($ch) . ": ".

    curl_error($ch), "a+");

   curl_close($ch);

   return null;

 }else

 {

    curl_close($ch);

    return $response;

 }

}

这个函数使用客户端证书来建立连接，然后使用输出缓冲来获取响应内容（cURL把输出直接发送给浏览器）。如果出现错误，响应出错信息会记录到文件；如果成功，响应结果会返回给调用函数。客户端证书切记要存放到安全的地方（web文档根目录之外的位置）。

很多人都对ChromeOS兴奋不已，很明显有些博客言过其实。也许是该总结一下到底google的新OS是（不是）什么了。

ChromeOS是：
1.是linux：如果你认为Moblin(REF)是linux内核，clutter window manager也是linux的话。那么ChromeOS以及他还没有命名的轻量级窗口管理器也是linux。如同其他linux版本一样，ChromeOS也会开源，我们可能看到其他基于ChromeOS的版本 - 正如Ubuntu基于Debian一样。

2.是为上网本设计的操作系统：有一件事可以确定，ChromeOS会根据上网本的使用模式而专门优化，这和第一台EEE PC上的Xandros OS或 gOS类似：本地预装一部分应用程序，其他应用则基于云上。最主要的不同在于：google Gears使得云应用变得更易用，用户体验更好。如果你看一下google ChromeOS的合作伙伴，你会注意到他们大多在上网本市场有着很好的表现。

3.是基于ARM的：再看一眼合作伙伴，其中有Qualcomm,Freescale和德州电器，没有Intel！这三家是ARM芯片制造商同时对ChromeOS可以很好的运行在基于ARM的芯片上有很大的兴趣。对x86的兼容性会帮助ChromeOS占有更多的市场，但是大多数预装ChromeOS的机器会是基于ARM的。

4.会在货架上出售：对，ChromeOS的目标就是帮助出售便宜的上网电脑（用户只有上网机会为google创造价值）。在摆放时应避免和PC放到一起，造成消费者的混淆。

5.对linux来说是件好事：linux最大的问题是他的市场份额。因为linux只能代表2%的市场，很多软件，游戏和硬件商会忽略它，因为市场实在是太小了，不愿意将产品或者驱动移植到linux上。作为平衡，linux社区起到很大的作用，很多驱动，应用软件是由程序员自己开发的。但有一个问题，很多流行的游戏是由游戏工作室设计的，驱动应该是在硬件发布之前而不是之后开发的。如果基于linux的平台 - ChromeOS能够得到更多的市场份额，对整个linux社区都是一件好事 - 可以获得更好的商用软件供应商和硬件厂商的支持。

ChromeOS不是：
1.并不完全依靠“云”：即便google没有使用Gnome或者KDE，她仍然可能会移植大多数的linux应用程序到ChromeOS，那么最终将有一整套完整的应用生态环境出现。尽管可能需要等上几年。因为Google gears的支持，类似google doc这样的web应用可以在离线状态下运行，所以本地应用程序可能是不需要的。

2.不是微软杀手：尽管为ChromeOS编写本地应用程序是可能的，但是ChromeOS最主要的目标是web接入。这意味着一开始可能只有很少的商用软件支持。因此，大多数人还是想要Windows作为他们的PC平台。ChromeOS可能只能在上网本制造商方面威胁到微软，但微软并没有在这方面赚钱，所以也就不大可能会引起大的对抗。

3.还没有准备好：google预期第一台装备ChromeOS的设备在2010年下半年诞生，尽管第一个beta版已经available。当ChromeOS上市的时候，Windows7和其他诸如Moblin和Jolicloud的linux操作系统将和它同台竞争。

REST API
当处理REST请求时，因为信息是通过GET，所以，信息在传输过程中会进行URL编码(URL-encoded)；当需要进一步处理时，首先要进行解码（唯一例外是用户名和密码）。不同的请求类型应该使用不同的endpoints(URLs)；如果要以单独的脚本程序来处理所有的请求，你可以让所有的请求都指向同一个endpoint，或者配置web服务器来映射许多endpoints到同一个脚本。我建议用后一种方式；它符合规范同时允许你以后在不需要影响外部接口的情况下做修改。

允许程序员使用web接口来请求API - 在调试程序时将变得非常有用；程序员可以快速的判断问题源于请求本身还是代码。你可以提供给程序员的调试工具越多，你的网站也就越容易开发。

SOAP APIs
当处理SOAP请求时，首先要检查请求是否符合WSDL指定的格式。如果你使用诸如NuSOAP的工具，他可以帮你做到这一点。事实上，大多数SOAP API使用一个框架来处理许多低级的工作。 SOAP API使用单一endpoint接收所有请求（作为一个通用规则，一些大的API会根据功能来拆分到不同的endpoint），因此，或者是你有一个很大的脚本文件，或者是在每个功能点都调用很多required()方法。

允许程序员在使用web接口时可以粘贴整个请求文档到一个表单，然后发送到你的服务器。从直接的经验来看，有这样一个工具对程序员调试程序时是非常有用的。提供脚本或者函数从而让程序员可以手动创建请求对那些没有使用SOAP框架的程序员是很有帮助的。

jdbc:derby:db1
•打开系统文件夹中的db1

jdbc:derby:london/sales
•打开数据库lodon/sales，london位于系统文件夹下，sales是london的子目录

jdbc:derby:/reference/phrases/french

•打开数据库 /reference/phrases/french。 unix下，就是从根目录开始的路径。windows下则是C:\reference\phrases\french（如果当前驱动器是C.如果一个包含数据库的jar文件在用户的类路径下，则这个路径是jar文件内的路径。

jdbc:derby:a:/demo/sample
•打开驱动器A中的数据库，路径是\demo\sample

jdbc:derby:c:/databases/salesdb jdbc:derby:salesdb
•这两个连接到相同的数据库 - salesdb.在windows下derby默认的系统路径是C:\databases.

jdbc:derby:support/bugsdb;create=true
•在系统路径下创建一个新的数据库 - support/bugsdb。如果不存在，则自动产生相应的文件夹。

jdbc:derby:sample;shutdown=true
•关闭sample数据库。（如果没有启用验证，则不需要提供用户密码）

jdbc:derby:/myDB
•以只读方式连接myDB（位于类路径下）

jdbc:derby:classpath:/myDB
•同样以只读方式连接myDB数据库。使用classpath的原因是，路径下可能存在和数据库同名的文件夹。

jdbc:derby:jar:(C:/dbs.jar)products/boiledfood
•访问只读数据库boiledfood， 位于C:dbs.jar中的products文件夹。

jdbc:derby:directory:myDB
•访问myDB（位于系统文件夹）。使用directory是类路径下可能存在同名文件夹（myDB)

开闭原则
类应该被扩展,而不是被修改

Liskov替换原则
子类可以替换父类

依赖注入原则
依赖于抽象,而不是实现

接口分离原则
接口应该分开,避免单一通用的接口

合成重用原则
尽量用多态聚合代替继承

最少知识原则
操作知道尽可能少的当前类中的对象(自身,参数,类中的其他实例对象)

发布重用等效原则
细粒度的重用相当于细粒度的版本发布

包依赖:

共同关闭原则
一同变更的类应放在一起

公用重用原则
如果类不会一起被重用,就不应该放到一起.

非循环依赖原则
包之间不可以有循环依赖

依赖不变原则
依赖不应该经常变化

抽象不变原则
抽象包不应该经常变化

TODO: 翻译

假设持续整合是你开发过程中很重要的一部,你也很想把代码覆盖检查并入你的自动构建过程.但是如何设定覆盖率目标呢?经验丰富的代码覆盖支持者会建议你75%,85%甚至100%.

通过对项目中的代码分析,我意识到需要设定比上述数据低得多的目标.我不想成为团队中的Cathcart上校(Josef Heller的小说<<第22条军规>>中的人物,因为每当部下已经达到当前的飞行任务次数时,他就会设定更高的任务次数,虽然Yossarian不断地完成飞行任务,但却似乎永远都无法完成这个总在变化的次数,小说中最后Yossarian开小差逃到瑞典-译者).

我选择增量改进的策略而不是专制的设定更高的目标.为了成功的执行这个策略,每次构建都必须达到比之前构建更高的覆盖率.通过每次一小步的提升,来最终提升代码质量.

以下介绍如何使用Cobertura和Apache Ant来实现这个增量改进.

单元测试,代码覆盖,持续整合
这三个概念已经被广泛的接受为最佳实践.事实上,大多数程序员知道他们必须要单元测试.如果你还不知道,让我来引用Google研发总监Peter Norvig的名言:

"如果你觉得不需要写单元测试,把所有原因写下来到一张纸上.仔细的揣摩这张纸.然后,扔掉这张纸开始写单元测试."

但是谁来测试测试人员呢? 也就是说,你怎么来确认你写了足够的测试呢?这些是非常宝贵的信息,因为那些没有被测试覆盖到的代码正是最耗费你经历的地方.一个解决办法是使用代码覆盖工具,它们会告诉你有被测试代码的百分比,然后加入一个代码覆盖检查到你的持续构建过程.如果你的覆盖检查不通过,那么构建也该被认定为失败.

在我的增量改进策略中,我选择Cobertura是因为她4个定义完整而简单的ant任务扩展.其中之一 cobertura-check,当代码覆盖率没有达到要求是会认定构建失败.例如下面这个例子,当覆盖率小于80%时,Ant会认为构建是失败的:

<target name="coverage_check">
<cobertura-check totallinerate="80"/>
</target name="coverage_check">

但是,你可以使用之前的覆盖率来作为当前检查的标准.通过几个Cobertura的任务以及两个核心的ant任务,你就可以达到这个目标.而不需要担心是否应该考量 代码行率(line rate),分支率(branch rate)或者其他的覆盖数据.你的目标是改进,而不是一个绝对的硬性指标.

创建一个XML格式的代码覆盖报表
创建好ant任务后,你可以加入增量覆盖率检查到你的构建脚本中,第一步是用cobertura-report任务创建一个覆盖率报表:

<cobertura-report format="xml"/>

下面是一个生成的报表:

<?xml version="1.0"?>
<!DOCTYPE coverage SYSTEM "http://cobertura.sourceforge.net/xml/coverage-02.dtd">

<coverage line-rate="0.43612334801762115" branch-rate="0.48344370860927155" version="1.8" timestamp="1181043899853">
<sources>
<source>./src/java</source>
</sources>
<packages>
...
</packages>
</coverage>

确保你把这个文件保存安全的地方(或者放到你的版本控制系统),因为之后你会用到他们.

从报表中得到覆盖率数据
一开始你可能会用Ant的XmlProperty任务来直接获取代码行率(line rate).但是这种做法有几个问题:
1.Cobertura的行率(line-rate)是十进制小鼠,但是cobertura-check是用整数形式的百分率
2.在一个实际的项目里,coverage.xml可能会很大,使用XmlProperty可能会造成内存不足的错误

我建议使用Ant的XSLT任务来获取你所需要的数据

<xslt in="coverage.xml" out="build/coverage.properties" style="src/xsl/coverage.xsl" />

这个简单的xsl模板生成仅仅包含你所需要的数据的属性文件:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"  version="1.0">
<xsl:output method="text" omit-xml-declaration="yes"/>
<xsl:template match="coverage">
total.line-rate=
<xsl:value-of select="floor(@line-rate*100)"/>
</xsl:template>
</xsl:stylesheet>

注意方法:floor(@line-rate*100), 会把行率转成一个整数,生成的coverage.properties文件只有一行:

total.line-rate=44

这个属性文件仅仅是一个临时的文件,构建之后你可以把它清理掉.

使用Ant的property任务读入这个属性文件中唯一的值total.line-rate:

<property file="build/coverage.properties" />

然后你可以把之前的"80"替换为新的Ant属性值:

<cobertura-check totallinerate="${total.line-rate}"/>

完整的例子
最终的build.xml应该是这样(其他的任务省略掉):

<target name="coverage_check" depends="check_against_previous_rate">
<antcall target="coverage_report"/>
</target>

<target name="coverage_report">
<cobertura-report format="xml" destdir="." />
</target>

<target name="check_against_previous_rate" depends="coverage_xml_to_properties">
<property file="build/coverage.properties" />
<cobertura-check totallinerate="${coverage.line-rate}" />
</target>

<target name="coverage_xml_to_properties">
<xslt in="coverage.xml" out="build/coverage.properties" style="src/xsl/coverage.xsl" />
</target>

注意:新的覆盖报表只有在覆盖检查通过时才生成.(覆盖率必须要高于前一次的构建)

记得要先执行coverage_report,然后执行coverage_check.实际开发中,你应该加入另一个covertura-report任务来生成HTML的报表.

跟踪改进率
一个附加的好处是你可以通过记录覆盖率数据到一个文件来跟踪改进率.通过echo人物:

<target name="time">
<tstamp>
<format property="date.time" pattern="yyyy-MM-dd HH:mm"/>
</tstamp>
</target>

<target name="log" depends="time">
<echo file="${history.txt}" append="true">
${date.time};total.line-rate;${total.line-rate}
</echo>
</target>

可量化的结果,看得见的改进
在使用了上述的措施后的一周后,我们的代码覆盖率提升了30%.可喜的是,那些之前不情愿写测试的程序员现在也很自豪地看到项目的覆盖率提升.

敏捷开发的民主精神在于,每一个团队成员都可以为整个团队提出目标 - 通过写单元测试. 没有专制的目标,没有cathcart上校.

你也可以更进一步.把这种增量式改进策略用到其他的地方.

作者Steven Hale,工作与瑞典的Omegapoint AB咨询公司.有超过20年的系统开发经验.

之前，在讨论我在corbis所使用的软件工程管理方法时 ，我曾提到引入看板系统来维持项目运行。因为它的引入，我们现在每个月平均发布两个新的版本。然而，这些并没有使用传统的敏捷开发方法如两周迭代（two week iteration)或快速迭代（sprint)。而是用看板系统来管理变更请求（CR-Change Request）。当CR被完成时，它被设在准备发布状态，并在每周三被发布。

尽管我们让没有用Visual Studio的开发人员使用了outlook的teamlook客户端联入Team Foundation Server跟踪所有CR，但基本上的日常工作，我们都是使用白板作为看板来跟踪所有CR，把Post-It当作看板卡。

我们的支持过程是由一组常见的软件工程资源驱动的，没有一个专职的支持维护团队。通过设置看板，我们可以向管理层保证 - 我们正在履行我们的承诺，我们使用了一定的资源来进行支持活动，而不需要特别指出是谁在负责。

每天早会上所有团队成员会围绕看板来进行当天的工作安排，讨论进度和当前存在的问题。达伦戴维斯，作为项目经理，会主持会议，并分析每张卡片并与其他成员讨论。每张卡上写着CR的标题以及ID，及负责人的名字。每个负责人有责任根据当前CR的进行阶段移动相应CR的卡片。达伦利用每天的早会来保证Team Foundation Server上的数据和看板是同步的。该看板系统基本上是自我组织(self organizing)，但整个团队每天都会验证它的有效性。

一些关键概念。红星 - 这个任务已经严重超时的，超过28个工作日服务水平协议（ SLA），通过该系统。这使"迟到"的项目能够自我加速，不需直接管理干预。粉红色卡表示这个CR在Team Foundation Server里还是open的。这些粉红色卡包含了描述信息和在Team Foundation Server里的ID 。还有一些其他类型的卡片：黄色-客户提出（customer-valued)的CR;蓝色-客户提出（和要求）的BUG;绿色-IT维护项，如：的sql 2005的升级;橙色-新增（或额外）的BUG;粉红-issue。

看板限制卡片最多只能有20张，分为不同阶段，系统的分析，开发，测试，构建/合并，部署。此外，我们也允许有3个bug可以放在任何地方。这样可以有效地利用闲散资源。当人手不够的时候，我们会减少这个数量，或者干脆不要。此外，还有两个维护项，这让我们能解决固定分配一些资源到大大系统维护和升级，例如API版本升级，与平台的升级。 如net2.0或sql server 2005 。

看板赋予我们三个成功要素：

• 减少“进行中(work-in-progress)”， （讽刺的是，这些事情本身会限制工作的完成）
• 量入而出（如果有新的CR，首先看看板上有没有足够的空间）
• 确定优先顺序

我们每周和公司的技术总监开会讨论，决定任务的优先等级。他们从后台日志中拿出新的CR并考虑怎么把他们配置到看板上。这迫使他们思考哪些是最重要的事情。看板强迫他们给出优先等级。

看板还把我们从定时迭代的压迫（constraints of time-boxed iterations)中解放出来。尽管我们现在每两个星期发布一个新版本，大的任务可以在系统中最多可以存在60天。那些对于“一（两）周迭代”来说太大的任务同样可以放到看板里，而不需要特殊对待。

最后，看板解放了我们，我们不再把每个迭代都当作一个小型的项目而投入过多的管理成本它基本上是自行组织和管理，除非有特殊情况出现，如需要加快请求或因环境或系统的维修问题变更发布时间。

technorati的标签：敏捷，朱+安德森，精益生产，看板，软件+工程

顺便问一下customer-valued怎么翻译？

最后修改：2009-8-12