架构师 (2014年6月刊). pdf

articles = extractEmail(); // 添加文章 for (Article article : articles) { addArticleOrComment(article); } // 清空邮件 cleanEmail(); logger.debug(" 完成 " + getExtractorName() + "。。"); } Yuna 工具在推广后，越来越多的部门使用这个工具，处理的时间越来越慢，Yuna 是每隔 5 分钟进行一次抽取的，而当邮件多的时候一次处理可能就花了几分钟，于是我在 Yuna2.0 版本里使用了生产者消费者模式来处理邮件，首先生产者线程按一定的规则去邮件系统里抽取邮件，然后存放在阻塞队列里，消费者从阻塞队列里取出文章后插入到 conﬂunce 里。代码如下： public class QuickEmailToWikiExtractor extends AbstractExtractor { private ThreadPoolExecutor threadsPool; private ArticleBlockingQueue emailQueue; public QuickEmailToWikiExtractor() { emailQueue= new ArticleBlockingQueue(); int corePoolSize = Runtime.getRuntime().availableProcessors() * 2; threadsPool = new ThreadPoolExecutor(corePoolSize, corePoolSize, 10l, TimeUnit.SECONDS, new LinkedBlockingQueue(2000)); } public void extract() { logger.debug(" 开始 " + getExtractorName() + "。。"); long start = System.currentTimeMillis(); // 抽取所有邮件放到队列里 new ExtractEmailTask().start(); // 把队列里的文章插入到 Wiki insertToWiki(); long end = System.currentTimeMillis(); double cost = (end - start) / 1000; logger.debug(" 完成 " + getExtractorName() + ", 花费时间：" + cost + " 秒 "); } /** * 把队列里的文章插入到 Wiki */ private void insertToWiki() { // 登录 wiki, 每间隔一段时间需要登录一次 conﬂuenceService.login(RuleFactory.USER_NAME, RuleFactory.PASSWORD); while (true) { 70 2014 年 6 月《架构师》 //2 秒内取不到就退出 ExchangeEmailShallowDTO email = emailQueue.poll(2, TimeUnit. SECONDS); if (email == null) { break; } threadsPool.submit(new insertToWikiTask(email)); } } protected List

extractEmail() { List allEmails = getEmailService(). queryAllEmails(); if (allEmails == null) { return null; } for (ExchangeEmailShallowDTO exchangeEmailShallowDTO : allEmails) { emailQueue.oﬀer(exchangeEmailShallowDTO); } return null; } /** * 抽取邮件任务 * * @author tengfei.fangtf */ public class ExtractEmailTask extends Thread { public void run() { extractEmail(); } } } 多生产者和多消费者场景在多核时代，多线程并发处理速度比单线程处理速度更快，所以我们可以使用多个线程来生产数据，同样可以使用多个消费线程来消费数据。而更复杂的情况是，消费者消费的数据，有可能需要继续处理，于是消费者处理完数据之后，它又要作为生产者把数据放在新的队列里，交给其他消费者继续处理。如下图：投稿信箱：editors@cn.infoq.com 71 我们在一个长连接服务器中使用了这种模式，生产者 1 负责将所有客户端发送的消息存放在阻塞队列 1 里，消费者 1 从队列里读消息，然后通过消息 ID 进行 hash 得到 N 个队列中的一个，然后根据编号将消息存放在到不同的队列里，每个阻塞队列会分配一个线程来消费阻塞队列里的数据。如果消费者 2 无法消费消息，就将消息再抛回到阻塞队列 1 中，交给其他消费者处理。以下是消息总队列的代码； /** * 总消息队列管理 * * @author tengfei.fangtf */ public class MsgQueueManager implements IMsgQueue{ private static ﬁnal Logger LOGGER = LoggerFactory.getLogger(MsgQueueManager.class); /** * 消息总队列 */ public ﬁnal BlockingQueue messageQueue; private MsgQueueManager() { messageQueue = new LinkedTransferQueue(); } public void put(Message msg) { try { messageQueue.put(msg); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } public Message take() { try { return messageQueue.take(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } return null; } } 72 2014 年 6 月《架构师》启动一个消息分发线程。在这个线程里子队列自动去总队列里获取消息。 /** * 分发消息，负责把消息从大队列塞到小队列里 * * @author tengfei.fangtf */ static class DispatchMessageTask implements Runnable { @Override public void run() { BlockingQueue subQueue; for (;;) { // 如果没有数据，则阻塞在这里 Message msg = MsgQueueFactory.getMessageQueue().take(); // 如果为空，则表示没有 Session 机器连接上来，需要等待，直到有 Session 机器连接上来 while ((subQueue = getInstance().getSubQueue()) == null) { try { Thread.sleep(1000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } // 把消息放到小队列里 try { subQueue.put(msg); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } } } 使用 Hash 算法获取一个子队列。 /** * 均衡获取一个子队列。 * * @return */ public BlockingQueue getSubQueue() { int errorCount = 0; for (;;) { if (subMsgQueues.isEmpty()) { return null; } int index = (int) (System.nanoTime() % subMsgQueues.size()); try { return subMsgQueues.get(index); } catch (Exception e) { // 出现错误表示，在获取队列大小之后，队列进行了一次删除操作 LOGGER.error(" 获取子队列出现错误 ", e); if ((++errorCount) < 3) { continue; } } } } 投稿信箱：editors@cn.infoq.com 73 使用的时候我们只需要往总队列里发消息。 // 往消息队列里添加一条消息 IMsgQueue messageQueue = MsgQueueFactory.getMessageQueue(); Packet msg = Packet.createPacket(Packet64FrameType. TYPE_DATA, "{}".getBytes(), (short) 1); messageQueue.put(msg); 小结本章讲解了生产者消费者模式，并给出了实例。读者可以在平时的工作中思考下哪些场景可以使用生产者消费者模式，我相信这种场景应该非常之多，特别是需要处理任务时间比较长的场景，比如上传附件并处理，用户把文件上传到系统后，系统把文件丢到队列里，然后立刻返回告诉用户上传成功，最后消费者再去队列里取出文件处理。比如调用一个远程接口查询数据，如果远程服务接口查询时需要几十秒的时间，那么它可以提供一个申请查询的接口，这个接口把要申请查询任务放数据库中，然后该接口立刻返回。然后服务器端用线程轮询并获取申请任务进行处理，处理完之后发消息给调用方，让调用方再来调用另外一个接口拿数据。另外 Java 中的线程池类其实就是一种生产者和消费者模式的实现方式，但是实现方法更高明。生产者把任务丢给线程池，线程池创建线程并处理任务，如果将要运行的任务数大于线程池的基本线程数就把任务扔到阻塞队列里，这种做法比只使用一个阻塞队列来实现生产者和消费者模式显然要高明很多，因为消费者能够处理直接就处理掉了，这样速度更快，而生产者先存，消费者再取这种方式显然慢一些。我们的系统也可以使用线程池来实现多生产者消费者模式。比如创建 N 个不同规模的 Java 线程池来处理不同性质的任务，比如线程池 1 将数据读到内存之后，交给线程池 2 里的线程继续处理压缩数据。线程池 1 主要处理 IO 密集型任务，线程池 2 主要处理 CPU 密集型任务。感谢张龙对本文的策划与审校。原文：http://www.infoq.com/cn/articles/producers-and-consumers-mode 74 2014 年 6 月《架构师》特别专栏 | Column Node.js 软肋之回调大坑作者吴海星 Node.js 需要按顺序执行异步逻辑时一般采用后续传递风格，也就是将后续逻辑封装在回调函数中作为起始函数的参数，逐层嵌套。这种风格虽然可以提高CPU利用率，降低等待时间，但当后续逻辑步骤较多时会影响代码的可读性，结果代码的修改维护变得很困难。根据这种代码的样子，一般称其为 "callback hell" 或 "pyramid of doom"，本文称之为回调大坑，嵌套越多，大坑越深。坑的起源后续传递风格为什么会有坑？这要从后续传递风格（continuation-passing style--CPS) 说起。这种编程风格最开始是由 Gerald Jay Sussman 和 Guy L. Steele, Jr. 在 AI Memo 349 上提出来的，那一年是 1975 年，Schema 语言的第一次亮相。既然 JavaScript 的函数式编程设计原则主要源自 Schema，这种风格自然也被带到了 Javascript 中。这种风格的函数要有额外的参数：“后续逻辑体”，比如带一个参数的函数。CPS 函数计算出结果值后并不是直接返回，而是调用那个后续逻辑函数，并把这个结果作为它的参数。从而实现计算结果在逻辑步骤之间的传递，以及逻辑的延续。也就是说如果要调用 CPS 函数，调用方函数要提供一个后续逻辑函数来接收 CPS 函数的“返回”值。回调在 JavaScript 中，这个“后续逻辑体”就是我们常说的回调 (callback)。这种作为参数的函数之所以被称为回调，是因为它一般在主程序中定义，由主程序交给库函数，并由它在需要时回来调用。而将回调函数作为参数的，一般是一个会占用较长时间的异步函数，要交给另一个线程执行，以便不影响主程序的后续操作。如下图所示：在 JavaScript 代码中，后续传递风格就是在 CPS 函数的逻辑末端调用传入的回调函数，并把计算结果传给它。但在不需要执行处理时间较长的异步函数时，一般并不需要用这种风格。我们先来看个简单的例子，编程求解一个简单的 5 元方程：投稿信箱：editors@cn.infoq.com 75 x+y+z+u+v=16 x+y+z+u-v=10 x+y+z-u=11 x+y-z=8 x-y=2 对于 x+y=a;x-y=b 这种简单的二元方程我们都知道如何求解，这个 5 元方程的运算规律和这种二元方程也没什么区别，都是两式相加除以 2 求出前一部分，两式相减除以 2 求出后一部分。5 元方程的前一部分就是 4 元方程的和值，依次类推。我们的程序写出来就是：代码清单 1. 普通解法 -calnorm.js var res = new Int16Array([16,10,11,8,2]),l= res.length; var variables = []; for(var i = 0;i < l;i++) { if(i === l-1) { variables[i] = res[i]; }else { variables[i] = calculateTail(res[i],res[i+1]); res[i+1] = calculateHead(res[i],res[i+1]); } } function calculateTail(x,y) { return (x-y)/2; } function calculateHead(x,y) { return (x+y)/2; } 方程式的结果放在了一个整型数组中，我们在循环中依次遍历数组中的头两个值 res[i] 和 res[i+1]，用 calculateTail 计算最后一个单值，比如第一和第二个等式中的 v；用 calculateHead 计算等式的 " 前半部分 "，比如第一和第二个等式中的 x+y+z+u 部分。并用该结果覆盖原来的差值等式，即用 x+y+z+u 的结果覆盖原来 x+y+z+u-v 的结果，以便计算下一个 tail，直到最终求出所有未知数。如果 calculateTail 和 calculateHead 是 CPU 密集型的计算，我们通常会把它放到子线程中执行，并在计算完成后用回调函数把结果传回来，以免阻塞主进程。关于 CPU 密集型计算的相关概念，可参考本系列的上一篇 Node.js 软肋之 CPU 密集型任务。比如我们可以把代码改成下面这样：代码清单 2. 回调解法 -calcb.js var res = new Int16Array([16,10,11,8,2]),l= res.length; var variables = []; (function calculate(i) { if(i === l-1) { variables[i] = res[i]; console.log(i + ":" + variables[i]); process.exit(); }else { calculateTail(res[i],res[i+1],function(tail) { variables[i] = tail; calculateHead(res[i],res[i+1],function(head) { res[i+1] = head; console.log('-----------------'+i+'-----------------') calculate(i+1); }); 76 2014 年 6 月《架构师》 }); } })(0); function calculateTail(x,y,cb) { setTimeout(function(){ var tail = (x-y)/2; cb(tail); },300); } function calculateHead(x,y,cb) { setTimeout(function(){ var head = (x+y)/2; cb(head); },400); } 跟上一段代码相比，这段代码主要有两个变化。第一是calculateTail 和 calculateHead 里增加了setTimeout，把它们伪装成CPU 密集型任务；第二是弃用for 循环，改用函数递归。因为calculateHead 的计算结果会影响下一轮的 calculateTail 计算，所以 calculateHead 计算要阻塞后续计算。而 for 循环是无法阻塞的，会产生错误的结果。此外就是 calculateTail 和 calculateHead 都变成后续传递风格的函数了，通过回调返回最终计算结果。这个例子比较简单，既不能充分体现回调在处理异步非阻塞操作时在性能上的优越性，坑的深度也不够恐怖。不过也可以说明“用后续传递风格实现几个异步函数的顺序执行是产生回调大坑的根本原因”。下面有一个更抽象的回调样例，看起来更有代表性： module.exports = function (param, cb) { asyncFun1(param, function (er, data) { if (er) return cb(er); asyncFun2(data,function (er,data) { if (er) return cb(er); asyncFun3(data, function (er, data) { if (er) return cb(er); cb(data); }) }) }) } 像 function(er,data) 这种回调函数签名很常见，几乎所有的 Node.js 核心库及第三方库中的 CPS 函数都接收这样的函数参数，它的第一个参数是错误，其余参数是 CPS 函数要传递的结果。比如 Node.js 中负责文件处理的 fs 模块，我们再看一个实际工作中可能会遇到的例子。要找出一个目录中最大的文件，处理步骤应该是：用 fs.readdir 获取目录中的文件列表；循环遍历文件，获取文件的 stat；找出最大文件；以最大文件的文件名为参数调用回调。这些都是异步操作，但需要顺序执行，后续传递风格的代码应该是下面这样的：投稿信箱：editors@cn.infoq.com 77 代码清单 3. 寻找给定目录中最大的文件 var fs = require('fs') var path = require('path') module.exports = function (dir, cb) { fs.readdir(dir, function (er, ﬁles) { // [1] if (er) return cb(er) var counter = ﬁles.length var errored = false var stats = [] ﬁles.forEach(function (ﬁle, index) { fs.stat(path.join(dir,ﬁle), function (er, stat) { // [2] if (errored) return if (er) { errored = true return cb(er) } stats[index] = stat // [3] if (--counter == 0) { // [4] var largest = stats .ﬁlter(function (stat) { return stat.isFile() }) // [5] .reduce(function (prev, next) { // [6] if (prev.size > next.size) return prev return next }) cb(null, ﬁles[stats.indexOf(largest)]) // [7] } }) }) }) } 对这个模块的用户来说，只需要提供一个回调函数 function(er,ﬁlename)，用两个参数分别接收错误或文件名： var ﬁndLargest = require('./ﬁndLargest') ﬁndLargest('./path/to/dir', function (er, ﬁlename) { if (er) return console.error(er) console.log('largest ﬁle was:', ﬁlename) }) 介绍完 CPS 和回调，我们接下来看看如何平坑。解套平坑编写正确的并发程序归根结底是要让尽可能多的操作同步进行，但各操作的先后顺序仍能正确无误。服务端的代码一般逻辑比较复杂，步骤多，此时用嵌套实现异步函数的顺序执行会比较痛苦，所以应该尽量避免嵌套，或者降低嵌套代码的复杂性，少用匿名函数。这一般有几种途径： 1. 最简单的是把匿名函数拿出来定义成单独的函数，然后或者像原来一样用嵌套方式调用，或者借助流程控制模块放在数组里逐一调用； 2. 用 Promis； 3. 如果你的 Node 版本 >=0.11.2，可以用 generator。 78 2014 年 6 月《架构师》我们先介绍最容易理解的流程控制模块。流程控制模块 Nimble 是一个轻量、可移植的函数式流程控制模块。经过最小化和压缩后只有 837 字节，可以运行在 Node.js 中，也可以用在各种浏览器中。它整合了 underscore 和 async 一些最实用的功能，并且 API 更简单。 nimble 有两个流程控制函数，_.parallel 和 _.series。顾名思义，我们要用的是第二个，可以让一组函数串行执行的 _.series。下面这个命令是用来安装 Nimble 的： npm install nimble 如果用 .series 调度执行上面那个解方程的函数，代码应该是这样的： ... var ﬂow = require('nimble'); (function calculate(i) { if(i === l-1) { variables[i] = res[i]; process.exit(); }else { ﬂow.series([ function (callback) { calculateTail(res[i],res[i+1],function(tail) { variables[i] = tail; callback(); }); }, function (callback) { calculateHead(res[i],res[i+1],function(head) { res[i+1] = head; callback(); }); }, function(callback){ calculate(i+1); }]); } })(0); ... .series 数组参数中的函数会挨个执行，只是我们的calculateTail 和 calculateHead 都被包在了另一个函数中。尽管这个用流程控制实现的版本代码更多，但通常可读性和可维护性要强一些。接下来我们介绍 Promise。 Promise 什么是 Promise 呢？在纸牌屋的第一季第一集中，当琳达告诉安德伍德不能让他做国务卿后，他说：“所谓 Promise，就是说它不会受不断变化的情况影响。” Promise 不仅去掉了嵌套，它连回调都去掉了。因为按照 Promise 的观点，回调一点也不符合函数式编程的精神。回调函数什么都不返回，没有返回值的函数，执行它仅仅是因为它的副作用。所以用回调函数编程天生就是指令式的，是以副作用为主的过程的执行顺序，而不是像函数那样把输入映射到输出，可以组装到一起。投稿信箱：editors@cn.infoq.com 79 最好的函数式编程是声明式的。在指令式编程中，我们编写指令序列来告诉机器如何做我们想做的事情。在函数式编程中，我们描述值之间的关系，告诉机器我们想计算什么，然后由机器（底层框架）自己产生指令序列完成计算。Promise 把函数的结果变成了一个与时间无关的值，就像算式中的未知数一样，可以用它轻松描述值之间的逻辑计算关系。虽然要得出一个函数最终的结果需要先计算出其中的所有未知数，但我们写的程序只需要描述出各未知数以及未知数和已知数之间的逻辑关系。而 CPS 是手工编排控制流，不是通过定义值之间的关系来解决问题，因此用回调函数编写正确的并发程序很困难。比如在代码清单 2 中， caculateHead 被放在 caculateTail 的回调中执行，但实际上在计算同一组值时，两者之间并没有依赖关系，只是进入下一轮计算前需要两者都给出结果，但如果不用回调嵌套，实现这种顺序控制比较麻烦。当然，这和我们的处理方式（共用数组）有关，就这个问题本身而言，caculateHead 完全不依赖于任何 caculateTail。这里用的 Promis 框架是著名的 Q，可以用 npm install q 安装。虽然可用的 Promis 框架有很多，但在它们用法上都大同小异。我们在这里会用到其中的三个方法。第一个负责将 Node.js 的 CPS 函数变成 Promise。Node.js 核心库和第三方库中有非常多的 CPS 函数，我们的程序肯定要用到这些函数，要解决回调大坑，就要从这些函数开始。这些函数的回调函数参数大多遵循一个相同的模式，即函数签名为 function(err, result)。对于这种函数，可以用简单直接的 Q.nfcall 和 Q.nfapply 调用这种 Node. js 风格的函数返回一个 Promise： return Q.nfcall(FS.readFile, "foo.txt", "utf-8"); return Q.nfapply(FS.readFile, ["foo.txt", "utf-8"]); 也可以用 Q.denodeify 或 Q.nbind 创建一个可重用的包装函数，比如： var readFile = Q.denodeify(FS.readFile); return readFile("foo.txt", "utf-8"); var redisClientGet = Q.nbind(redisClient.get, redisClient); return redisClientGet("user:1:id"); 第二个是 then 方法，这个方法是 Promise 对象的核心部件。我们可以用这个方法从异步操作中得到返回值（履约值），或抛出的异常（拒绝的理由）。then 方法有两个可选的参数，分别对应 Promis 对象的两种执行结果。成功时调用的 onFulﬁlled 函数，错误时调用 onRejected 函数： var promise = asyncFun() promise.then(onFulﬁlled, onRejected) Promise 被解决时（异步处理已经完成）会调用 onFulﬁlled 或 onRejected 。因为只会有一种可能，所以这两个函数中仅有一个会被触发。尽管 then 方法的名字让人觉得它跟某种顺序化操作有关，并且那确实是它所承担的职责的副产品，但你真的可以把它当作 unwrap 来看待。Promise 对象是一个存放未知值的容器，而 then 的任务就是把这个值从 Promise 中提取出来，把它交给另一个函数。 var promise = readFile() var promise2 = promise.then(readAnotherFile, console.error) 这个 promise 表示 onFulﬁlled 或 onRejected 的返回结果。既然结果只能是其中之一，所以不管是什么结果，Promise 都会转发调用 : 80 2014 年 6 月《架构师》 var promise = readFile() var promise2 = promise.then(function (data) { return readAnotherFile() // if readFile was successful, let's readAnotherFile }, function (err) { console.error(err) // if readFile was unsuccessful, let's log it but still readAnotherFile return readAnotherFile() }) promise2.then(console.log, console.error) // the result of readAnotherFile 因为 then 返回的是 Promise，所以 promise 可以形成调用链，从而避免出现回调大坑： readFile() .then(readAnotherFile) .then(doSomethingElse) .then(...) 第三个是 all 和 spread 方法。我们可以把几个 Promise 放到一个数组中，用 all 将它们变成一个 Promise，而 spread 跟在 all 后面就相当于 then，只是它同时接受几个结果。如果数组中的 N 个 Promise 都成功，那 spread 的 onFulﬁlled 参数就能收到对应的 N 个结果；如果有一个失败，它的 onRejected 就会得到第一个失败的 Promise 抛出的错误。下面是用 Q 改写的解方程程序代码： .... var Q = require('q'); var qTail = Q.denodeify(calculateTail); var qHead = Q.denodeify(calculateHead); (function calculate(i) { Q.all([ qTail(res[i],res[i+1]), qHead(res[i],res[i+1])]) .spread(function(tail,head){ variables[i] = tail; res[i+1] = head; return i+1; }) .then(function(i){ if(i === l-1) { variables[i] = res[i]; process.exit(); }else { calculate(i); } }); })(0); function calculateTail(x,y,cb) { setTimeout(function(){ var tail = (x-y)/2; cb(null,tail); },300); } function calculateHead(x,y,cb) { setTimeout(function(){ var head = (x+y)/2; cb(null,head); },400); } ... 注意 calculateTail 和 calculateHead 中的 cb 调用，为了满足 denodeify 的要求，投稿信箱：editors@cn.infoq.com 81 我们给它增加了值为 null 的 err 参数。此外还用到了上面提到的 denodeify、all 和 spread、then。其实除了流程控制，Promise 在异常处理上也比回调做得好。甚至有些开发团队坚决反对在代码中使用 CPS 函数，将 Promise 作为编码规范强制推行。再来看一下那个找最大文件的例子用 Promise 实现的样子： var fs = require('fs') var path = require('path') var Q = require('q') var fs_readdir = Q.denodeify(fs.readdir) // [1] var fs_stat = Q.denodeify(fs.stat) module.exports = function (dir) { return fs_readdir(dir) .then(function (ﬁles) { var promises = ﬁles.map(function (ﬁle) { return fs_stat(path.join(dir,ﬁle)) }) return Q.all(promises).then(function (stats) { // [2] return [ﬁles, stats] // [3] }) }) .then(function (data) { // [4] var ﬁles = data[0] var stats = data[1] var largest = stats .ﬁlter(function (stat) { return stat.isFile() }) .reduce(function (prev, next) { if (prev.size > next.size) return prev return next }) return ﬁles[stats.indexOf(largest)] }) } 这时这个模块的用法变成了： var ﬁndLargest = require('./ﬁndLargest') ﬁndLargest('./path/to/dir') .then(function (er, ﬁlename) { console.log('largest ﬁle was:', ﬁlename) }) .fail(function(err){ console.error(err); }); 因为模块返回的是 Promise，所以客户端也变成了 Promise 风格的，调用链中的所有异常都可以在这里捕获到。不过 Q 也有可以支持回调风格函数的 nodeify 方法。 generators generator 科普在计算机科学中，generator 实际上是一种迭代器。它很像一个可以返回数组的函数，有参数，可以调用，并且会生成一系列的值。然而 generator 不是把数组中的值都准备好然后一次性返回，而是一次 yield 一个，所以它所需的资源更少，并且调用者可以马上开始处理开头的几个值。简言之，generator 看起来像函数，但行为表现像迭代器。 82 2014 年 6 月《架构师》 Generator 也被称为半协程，是协程的一种特例（比协程弱），它总是把控制权交回给调用者（同时返回一个结果值），而不是像协程一样跳转到指定的目的地。如果要说得具体一点儿，就是虽然它们两个都可以 yield 多次，暂停执行并允许多次进入，但协程可以指定 yield 之后的去向，而 generator 不行，它只能把控制权交回给调用者。因为 generator 主要是为了降低编写迭代器的难度的，所以 generator 中的 yield 语句不是用来指明程序要跳到哪里去的，而是用来把值传回给父程序的。 2008 年 7 月，Eich 宣布开始 ECMAScript Harmony（即 ECMAScript 6）项目，从 2011 年 7 月开始，ECMAScript Harmony 草案开始定期公布，预计到 2014 年 12 月正式发布。generator 就是在这一过程中出现在 ECMAScript 中的，随后不久就被引入了 V8 引擎中。 Node.js 对 generator 的支持是从v0.11.2 开始的，但因为Harmony 还没正式发布，所以需要指明 --harmony 或 --harmony-generator 参数启用它。我们用 node --harmony 进入 REPL，创建一个 generator： function* values() { for (var i = 0; i < arguments.length; i++) { yield arguments[i]; } } 注意 generator 的定义，用的是像函数可又不是函数的 function*，循环时每次遇到 yield，程序就会暂停执行。那么暂停后，generator 何时会再次执行呢？在 REPL 中执行 o.next()： >var o = values(1, 2, 3); > o.next(); { value: 1, done: false } > o.next(); { value: 2, done: false } > o.next(); { value: 3, done: false } > o.next(); { value: undeﬁned, done: true } > 第一次执行o.next()，返回了一个对象{ value: 1, done: false }，执行到第四次时， value 变成了 undeﬁned，状态 done 变成了 true。表现得像迭代器一样。next() 除了得到 generator 的下一个值并让它继续执行外，还可以把值传给 generator。有些文章提到了 send()，不过那是老黄历了，也许你看这篇文章的时候，本文中也有很多内容已经过时了，IT 技术发展得就是这样快。我们再看一个例子，还是在 REPL 中： function* foo(x) { yield x + 1; var y = yield null; return x + y; } 再次执行 next()： >var f = foo(2); > f.next(); { value: 3, done: false } > f.next(); 投稿信箱：editors@cn.infoq.com 83 { value: null, done: false } > f.next(5); { value: 7, done: true } 注意最后的 f.next(5)，value 变成了 7，因为最后一个 next 将 5 压进了这个 generator 的栈中，y 变成了 5。如果要总结一下，那么 generator 就是： 1. yield 可以出现在任何表达式中，所以可以随时暂停执行，比如 foo(yield x, yield y) 或在循环中。 2. 调用 generator 只是看起来像函数，但实际上是创建了一个 generator 对象。只有调用 next 才会再次启动 generator。next 还可以向 generator 对象中传值。 3. generator 返回的不是原始值，而是有两个属性的对象：value 和 done。当 generator 结束时，done 会变成 true，之前则一直是 false。可是 generator 和回调大坑有什么关系呢？因为 yield 可以暂停程序，next 可以让程序再次执行，所以只需稍加控制，就能让异步回调代码顺序执行。用 generator 平坑 Node.js 社区中有很多借助 generator 实现异步回调顺序化的库，比如 suspend、co 等，不过我们重点介绍的还是 Q。它提供了一个 spawn 方法。这个方法可以立即运行一个 generator，并将其中未捕获的错误发给 Q.onerror。比如前面那个解方程的函数，用 spawn 和 generator 实现就是： .... (function calculate(i) { Q.spawn(function* () { i = yield Q.all([qTail(res[i],res[i+1]),qHead(res[i],res[i+1])]) .spread(function(tail,head){ variables[i] = tail; res[i+1] = head; return i+1; }) if(i === l-1) { variables[i] = res[i]; console.log(i + ":" + variables[i]); process.exit(); }else { calculate(i); } }); })(0); ... 代码和前面用 Promise 实现时并没有太大变化，只是去掉了 then，看起来更简单了。不过记得执行时要用 >=v0.11.2 版本的 Node.js，并且要加上 --harmony 或 --harmony- generator。你会看到和前面相同的结果。至于寻找最大文件那个例子，在 spawn 里定义一个 generator，然后在有 then 的地方放上 yield 就行了。具体实现就交给你了。由于篇幅所限，本文没有展开介绍 Promise 和 generator 在错误处理上的优势，这在实际工作中也是很重要的部分，应该认真研究。参考资料 7 中对此介绍得比较详细，建议认真阅读。 84 2014 年 6 月《架构师》参考资料 Managing Node.js Callback Hell with Promises, Generators and Other Approaches,Marc Harter,2014.02.03 在 Node.js 中用 Q 实现 Promise – Callbacks 之外的另一种选择指令式 Callback，函数式 Promise：对 node.js 的一声叹息 How-to Compose Node.js Promises with Q,Marc Harter,2013.08.14 Analysis of generators and other async patterns in node generators in v8,Andy Wingo,2013.05.08 A Study on Solving Callbacks with JavaScript Generators,James Long,2013.06.05 V8 JavaScript Engine-Issue 2355:Implement generators 本文源码原文：http://www.infoq.com/cn/articles/nodejs-callback-hell 投稿信箱：editors@cn.infoq.com 85 86 2014 年 6 月《架构师》快乐 Node 码农的十个习惯作者 Zeke sikelianos ，译者吴海星从问世到现在将近 20 年，JavaScript 一直缺乏其它有吸引力的编程语言，比如 Python 和 Ruby，的很多优点：命令行界面，REPL，包管理器，以及组织良好的开源社区。感谢 Node.js 和 npm，现如今的 JavaScript 鸟枪换炮了。Web 开发者有了强大的新工具，接下来就看他们的想象力了。下面这个提示和技巧清单，能让你和你的 node 程序保持快乐。 1. 用 npm init 开始新项目 npm 有个 init 命令，可以引导你完成创建 package.json 文件的过程。即便你非常熟悉 package.json 和它的属性，也可以把 npm init 当作将你的新程序或模块导入正轨的简便办法。它可以聪明地为你设置默认值，比如通过上层目录的名称推断模块名，从 ~/.npmrc 中读取创作者的信息，以及用你的 git 设置确定代码库。 mkdir my-node-app cd my-node-app npm init 2. 声明所有依赖项在将模块安装到项目本地时坚持使用 --save ( 或 --save-dev) 是个好习惯。这些选项会将指定的模块添加到 package.json 的 dependencies（或 devDependencies）清单中，并使用合理的默认 semver 范围。 npm install domready --save 注意，现在 npm 使用插入符风格的 semver 范围： "dependencies": { "domready": "^1.0.4" } 3. 指定启动脚本在 package.json 中设定 scripts.start，你就可以在命令行中用 npm start 启动程序了。这个非常方便，因为克隆了你的程序的其他 node 开发人员不用猜就能轻松运行它。额外奖励：如果在 package.json 中定义了 scripts.start，你就不需要 Procﬁle 了 (Heroku 平台用 Procﬁle 来声明在你程序的 dynos 上运行什么命令 )。使用 npm start 会自动创建一个作为 web 进程的 Procﬁle。这里有个启动脚本示例： "scripts": { "start": "node index.js" } 投稿信箱：editors@cn.infoq.com 87 4. 指定测试脚本就像团队中的所有人都应该可以运行程序一样，他们也应该可以测试它。package.json 中的 scripts.test 就是用来指定运行测试套件的脚本的。如果你用 mocha 之类的东西运行测试，一定要确保把它包含在 package.json 里的 devDependencies 中，并且指向安装在你项目本地的文件，而不是全局安装的 mocha： "scripts": { "test": "mocha" } 5. 不要把依赖项放在源码的版本控制中很多 node 程序使用的 npm 模块带有 C 语言写的依赖项，比如 bson、ws 和 hiredis，这些依赖项必须在 Heroku 的 64 位 Linux 架构下进行编译。编译过程可能非常耗时。为了让构建过程尽可能的快，Heroku 的 node buildpack 在下载和编译完依赖项后会缓存它们，以便在后续部署中重用。这个缓存是为了降低网络流量并减少编译次数。忽略 node_modules 目录也是模块创作者推荐的 npm 实践。应用程序和模块之间少了一个区别！ echo node_modules >> .gitignore 6. 用环境变量配置 npm 以下内容摘自 npm 配置：所有以 npm_conﬁg_ 开头的环境变量都会被解释为配置参数。比如说环境中有 npm_ conﬁg_foo=bar 时，会将配置参数 foo 设置为 bar。任何没有给出值的环境配置的值都会设置为 true。配置值对大小写不敏感，所以 NPM_CONFIG_FOO=bar 也一样。最近在所有的 Heroku 构建中都有程序的环境。这一变化让 Heroku 上的 node 用户无需修改程序代码就可以控制他们的 npm 配置。习惯 #7 是这一方式的完美例证。 7. 带着你自己的 npm 注册中心最近几年公共 npm 注册中心出现了突飞猛进式的增长，因此会偶尔不稳定。所以很多 node 用户开始寻求公共注册中心之外的方案，他们或者是出于开发和构建过程中速度及稳定性方面的考虑，或者是因为要放置私有的 node 模块。最近几个月冒出了一些可供选择的 npm 注册中心。Nodejitsu 和 Gemfury 提供收费的私有注册中心，此外也有一些免费的，比如 Mozilla 的只读 S3/CloudFront 镜像和 Maciej Małecki 的欧洲镜像。在 Heroku 上配置 node 程序使用定制注册中心很容易： heroku conﬁg:set npm_conﬁg_registry=http://registry.npmjs.eu 8. 追踪过期的依赖项如果你编程的时间足够长，可能已经领教过相依性地狱的厉害了。好在 Node.js 和 npm 接 88 2014 年 6 月《架构师》纳了 semver，即语义化版本管理规范，设置了一个健全的依赖项管理先例。在这个方案下，版本号和它们的变化方式传达的含义涉及到了底层代码，以及从一个版本到下一版本修改了什么。 npm 有一个很少有人知道的命令，outdated。它可以跟 npm update 结合使用，能够找出程序的那些依赖项已经过期了，需要更新： cd my-node-app npm outdated Package Current Wanted Latest Location ------- ------- ------ ------ -------- express 3.4.8 3.4.8 4.0.0-rc2 express jade 1.1.5 1.1.5 1.3.0 jade cors 2.1.1 2.1.1 2.2.0 cors jade 0.26.3 0.26.3 1.3.0 mocha > jade diﬀ 1.0.7 1.0.7 1.0.8 mocha > diﬀ glob 3.2.3 3.2.3 3.2.9 mocha > glob commander 2.0.0 2.0.0 2.1.0 mocha > commander 如果你做的是开源的 node 程序或模块，可以看看 david-dm，NodeICO 和 shields. io，你可以用这三个优秀服务所提供的图片徽章在项目的 README 或网站上显示生动的依赖信息。 9. 用 npm 脚本运行定制的构建步骤随着 npm 生态系统的持续增长，开发和构建过程的自动化选择也会随之增长。Grunt 是迄今为止 node 世界中最流行的构建工具，但像 gulp.js 这种新工具，以及普通的老式 npm 脚本也因为较轻的负载受到欢迎。在你把 node 程序部署到 Heroku 上时，要运行 npm install --production 命令以确保程序的 npm 依赖项会被下载下来装上。但那个命令也会做其它事情：它会运行你在 package.json 文件中定义的所有 npm 脚本钩子，比如 preinstall 和 postinstall。 { "name": "my-node-app", "version": "1.2.3", "scripts": { "preinstall": "echo here it comes!", "postinstall": "echo there it goes!", "start": "node index.js", "test": "tap test/*.js" } } 这些脚本可以是行内 bash 命令，或者也可以指向可执行的命令行文件。你还可以在脚本内引用其他 npm 脚本： { "scripts": { "postinstall": "npm run build && npm run rejoice", "build": "grunt", "rejoice": "echo yay!", "start": "node index.js" } } 投稿信箱：editors@cn.infoq.com 89 10. 尝试新东西 ES6，也就是被大众称为 JavaScript 的 ECMAScript 语言规范的下一版，其工作名称为 Harmony。 Harmony 给 JavaScript 带来了很多振奋人心的新特性，其中很多已经出现在较新版本的 node 中了。 Harmony 实现了很多新特性，比如块作用域、生成器、代理、弱映射等等。要在你的 node 程序中启用 harmony 的特性，需要指定一个比较新的 node 引擎，比如 0.11.x，并在启动脚本中设置 --harmony 选项： { "scripts": { "start": "node --harmony index.js" }, "engines": { "node": "0.11.x" } } 11. Browserify 客户端 JavaScript 有乱如麻团般的遗留代码，但那并不是语言本身的错。由于缺乏合理的依赖项管理工具，让 jQuery- 插件拷贝 - 粘帖的黑暗时代延续了好多年。感谢 npm，带着我们步入了前端振兴的年代：npm 注册中心像野草一样疯长，为浏览器设计的模块也呈现出了惊人的增长势头。 Browserify 是一个让 node 模块可以用在浏览器中的神奇工具。如果你是前端开发人员， browserify 将会改变你的人生。可能不是今天，也不是明天，但不会太久。如果你想开始使用 browserify，请参阅这些文章。你有哪些习惯？不管你已经做过一段时间 node 程序，还是刚刚开始，我们都希望这些小技巧能对你有所帮助。如果你有一些（健康的）node 习惯想要跟大家分享，请在发 tweet 时带上 #node_ habits 标签。编码快乐！作者简介本文最初由 Zeke sikelianos 发表在 Heroku 上。Zeke 在 Heroku 工作，用 ruby 和 coﬀeescript 编写开源软件。他从事设计师这一职业已经有 14 年了，信奉信息自由的精神，并且相信用计算机可以创造出美好的事物。查看英文原文：10 Habits of a Happy Node Hacker 原文：http://www.infoq.com/cn/articles/node.js-habits 90 2014 年 6 月《架构师》避开那些坑 | Void 修复 bug 与解决问题——从敏捷到精益作者 Cecil Dijoux ，译者邵思华关于精益的定义有许多，但其中最令我感到鼓舞的是精益企业研究所主席 John Shooke 在它的著作《管理精益》中所描述的一段话：精益通过提高员工的水平来保证产品开发。在这个定义的基础上，这篇论文接下来解释了精益是怎样提高人员的水平的：方法就是解决问题。这一定义揭示了以下管理实践的美妙之处：仔细设计你的工作，让你能够清晰地看见所发生的问题（以及同时出现的学习机会），并在问题出现后以科学的方式解决。在与使用敏捷方法进行软件开发的团队共同工作时，我曾经有过一些误解：起初时，我混淆了 bug 和问题的概念，并且确信敏捷过程就是精益，因为它能够使 bug 变得可见。在最后的几个月里，在我头脑中的概念开始渐渐清晰起来，回想起当初的情景，我开始相信，我所在的敏捷团队产生的 bug，与精益系统产生的学习机会并不是一回事：后者表明在我的团队中确实存在着质量问题，而在其它许多团队身上我也看到了同样的问题。写这篇文章的目的，是为了描述我对bug与质量问题这一点上的思考方式是怎样逐渐变化的。这对于读者更好地理解造成bug产生的质量问题，并相应地提高绩效能够起到一些启示作用。并通过一些真实的故事描述来看清楚真正的问题所在。（先声明一点：我们并不假设所有的敏捷团队都对此问题抱有类似的误解）什么是 bug ？在软件工业中，一个 bug 可以代表任何形式的系统错误（NullPointerException、 Http 404 错误代码或是蓝屏……）、功能性错误（在我单击 B 的时候，系统本应执行 Z，却最终执行了 Y）、性能问题以及配置错误等等。在精益的术语中，一个 bug 必须能够按照下一节提到的定义进行清晰的表达，才能说它是一个问题。请相信我，我所见过的（和自己产生的）bug 中，95% 以上都不像是某种问题 ——性能问题或许是个常见的例外情况，但有趣的是，它们也是绩效的一部分，不是吗？什么是问题？让我们在这里做一个标准的定义吧。在《丰田模式：精益模式的实践》（Toyota Way Field book）这本书中，Jeﬀrey Liker 定义了一个问题所需的四个方面的信息： 1. 当前的实际绩效 2. 预期的绩效（标准绩效或目标绩效） 3. 以当前绩效和目标绩效之差所体现的问题严重程度 4. 问题的范围和特点正如 Brenée Brown 在 TED 所做的一次关于漏洞的演讲中所说的一样，如果你不能评估某个漏洞，那么它就不存在。从更实用的角度来说，如果你不能解释在绩效差距上的问题所在，那么很可能是由于你并没有花足够的时间去思考它。投稿信箱：editors@cn.infoq.com 91 在开始着手解决一个问题之前，重要的一点是要清晰地表达它，花一定时间去理解它（按照精益专家 Michael Ballé 的说法：要善待它），并且克制住直奔解决方案的冲动。我们都听说过爱因斯坦的名言：“如果我只有一小时的时间去解决一个问题，我会首先用 55 分钟去思考问题，最后用 5 分钟去思考解决方案。”没有人说这是件容易的事。在软件开发敏捷团队的情境中，绩效指标或许是一张燃尽图（表示工作量与延迟）、bug 数量、系统响应时间（质量）、客户对已提交的用户故事的评价（以总分 10 分来表示客户满意度），以及每个 Sprint 提交的用户故事（或用户故事总点数）数量（生产力）。按照这些指标，可以有以下这些问题存在：质量：这个页面的响应时间目标是在 500ms 以内，而在 5000 个并发用户的情况下，我们测量到的结果是 1500ms。质量：在 Sprint 结束时仍未解决的 bug 数量（2 个，而不是 0 个）工作量 / 延迟：我们预计这个用户故事需要 3 天时间完成，而实际上用了 8 天才完成生产力：在 Sprint 结束时，整个团队共提交了 5 个完成的用户故事，而之前的计划是完成 7 个。客户满意度：我们希望每个用户故事都能够得到 8 分以上（满分 10 分），而在上个 Sprint 结束后，有两个用户故事的客户满意度低于这个分数（6.5 分和 7 分）。怎样从 bug 中分析问题所在？ Bug 的出现往往是系统中产生了更常见问题的一种症状，而对于精益团队来说，将这些症状与真正的问题相关联起来是至关重要的。可以这么说，正如米开朗基罗从大理石碎片中发现它的美丽，并最终打造成迷人的雕像一样，精益团队的任务（例如某些团队会将持续改进作为他们每日工作内容的一部分）就是发挥他们的洞察力，从大量的 bug 中发现问题，并将其抽取出来。实现这一点需要进行细致地分析，并将这些原始的问题转化为学习的机会。我发现了一种着手进行这种分析的良好方式，就是将所有 bug 分门别类，并且理解每个 bug 类别的权重。大多数情况下，某个 bug 类别就体现了造成某个现有问题的原因，或者它本身就是一个问题。这种关联性可以帮助你以正确的顺序处理这些问题，并首先从对整个操作绩效影响最大的问题开始解决。如果你仍然不确定应该从何处着手，那么优先解决质量问题是比较保险的做法。 92 2014 年 6 月《架构师》示例 1：敏捷开发中的情景当时我在这个使用敏捷开发的团队中担任经理一职。和许多团队一样，我们团队也不是一个跨职能的团队（典型的 Scrum-but），而是一个负责后台的团队。它在某个迭代内负责构建基础服务端软件，以便让应用团队在之后的迭代中使用这部分功能。我们按照 Paretos 原则（即 80-20 原则）对产生的 bug 进行了一些分析，并且找出了一个占总数约 20% 的 bug 类别：这些 bug 都是由应用团队所提出的，与我们团队所建立的后台软件所暴露的 API 对“隐式”这一概念的定义有关。当应用团队在使用我们提供的功能时，经常会发生遗漏了某些输入参数，或者是缺少了某些输出数据等问题……因此他们就会为我们创建一些 bug，而我们的团队则会说：嘿！这个 API 已经隐式地表明了它不会返回这些数据。我们同时注意到了这些 bug 的持续时间，通常从创建直到关闭为止一共持续了大约 4 个星期。（在最好的情况下）在以一个月为周期的迭代的最后阶段会进行代码发布，客户端团队则可以在下一个迭代时使用这些代码。因此当客户端团队创建了 bug，并指派给原来的开发者时，往往距离她开发那些代码时已经过去了两三个星期，开发者不得不再度拾起这段代码…… 为了处理这种情况，我们决定改变一下工作的方式，将相关人员组织在一起，而产生一个相关联、跨职能并且跨技能的团队。采用了新的方式之后，我们注意到这些“隐式 API”相关的 bug 数量大幅下降了（约 50%）。最令人欣慰的是，这种类型的 bug 的持续时间下降到了几个工作日以内。当然，这个数字有一定的水分，有些 bug 虽然被发现了，但是并没有记录下来，因为开发者们现在进行结对编程，于是许多 bug 直接在座位上就解决了。虽然成果是显著的，但我总感觉到还有些不适之处，却说不出究竟是哪里出了问题。之后不投稿信箱：editors@cn.infoq.com 93 久我才发觉，从精益的角度来说，我们目前还有两个不足之处： 1. 首先，我们的系统中依然存在 bug，因此我们不得不重复劳动，这使得整个开发系统出现了生产力的浪费。但是由于缺乏内建的质量标准，我们无法保证服务端开发者所开发的 API 不存在问题。此外，对于错误的处理也没有真正的标准，我们的解决手段就是：遇到问题就坐下来一起解决。 2. 尽管结果非常显著且令人振奋，但它与团队的每日绩效没并有什么直接的关联，团队也无法立即采取行动并在第二天直接看到结果。我们只是从宏观上在 6 个月结束后的发布中才能够看到这一效果：即在 bug 总数中与 API 相关的 bug 只占少数。因此我们看到：建立一个跨技能的团队确实能够在某种程度上改进质量，但我们还未能提供一种有效的方法，让我们能够每天监控它的情况，并采取相应的行动。示例 2：精益开发中的情景时间转眼间过去了几年，我还是任职于同一家公司中，但目前的职位是项目主管及教练，负责一个大型的多团队、多种技术的敏捷项目的实施。某一个团队遇到了一个很有挑战的技术难题，他们要与某个大家都没有什么经验的技术进行整合。整个团队在过去的两个 Sprint 中没有交付任何用户故事，他们深陷于质量问题（例如 bug）中难以自拨。当第二个 Sprint 结束后，依然没有任何完成的用户故事（比方说，按照我们对完成的定义来看，该用户故事在功能性需求上需要做到没有任何 bug）可以交付。因此在回顾会议中，整个团队一致决定，将每周进行 bug 评审（在精益中称为红箱分析）。在第一次会议中，团队为所遇到的问题建立了一个 Pareto 模型。我们创建了一张表格，将 bug 类别放在一列里，bug 的数量和 bug ID 则分别用余下的几列来表示。之后的目标是逐个排除每种 bug 类别背后的根本问题，首先从发生次数最频繁的开始。为了鼓励团队成员就这一话题展开交流，Scrum Master 决定将这张 Pareto 表格贴在 Scrum 公告板与 bug 数量的旁边，并且每天对其进行更新。在每天早上的站立会议上，团队都会报告当前的 bug 情况，而新产生的 bug 都会按照其分类添加到该表格中。这种方式能够使团队更明显地意识到每日质量性能的变化情况，同时也是实现 PDCA 中的 C——Check（检验）的一种良好方式。当问题被根除之后，这方面的 bug 应该至少在一周之内不复存在了。不过，某些时候还是会发生这些 bug，而这也是需要学习的地方。举一个例子，该团队已经认识到了 bug 类别中有一种属于回归缺陷，即对软件的改动破坏了原本能够正常工作的特性。这种 bug 多数情况下发生在图形用户界面端，因为对这一部分进行自动化测试是非常困难的事。我们所找出的一个根本问题在于，初级程序员并不总是完全理解他们对代码的改动可能会造成的影响。对此问题的解决措施是在流程中加入一个新的步骤，在提交代码之前先让某个更资深的开发者进行代码复审。这一步骤大概只需要 15 分钟，但能够大幅降低回归缺陷出现的次数。此外还将对每次发布的 bug 数量进行每日评估（每天发布两次）。这种方式还能够提高初级开发者的技能水平。最终，所有的问题都得到了解决，结果是令人惊叹的：所有的问题都通过标准流程（在提交代码之前进行代码复审）得以一一根除。每日的 bug 数量直线下降，每个迭代周末能够提交的包括完整功能并且无 bug 的用户故事数量也在上升。3 个月之后，该团队就从之前产生 bug 数量最多的困境中摇身一变，成为了整个项目中高质量、高效率团队的代名词。这种方式相比之前的方法显得更为精益。因为它对每日绩效（质量）和生产力（提交的用户故事数量）产生了直接的影响，并且为团队带来了新的操作标准。 94 2014 年 6 月《架构师》将一个敏捷团队转变为学习团队经历过了以上两个示例之后，加上我从这次经历中所学到的经验，我将为你推荐一种将敏捷团队转变为精益和学习团队的路线图： 1. 对绩效进行评估，让它可为众人所见，并且每天都要对它展开讨论。我能够理解这一点对于某些非主流的敏捷教练来说是难以忍受的，但事实可能会令你感到沮丧：如果我们需要进行改进，那么首先要做的第一件事就是评估。此外，最重要的一点是，只有面对现实，才能进行深刻的学习。网络巨擎（谷歌、亚马逊、Twitter 及 Facebook）或者实践领导者（Etsy）都是这样做的：他们对每件事情都进行评估，如果他们仅仅关注于计算用户故事的点数，就不可能达到如今的绩效。在敏捷团队方面有个实际的例子可供参考：除了 Sprint 燃尽图之外，还要展示质量绩效（没有关闭的 bug 数量、每次发布的 bug 数量、每种类别的 bug 数量，等等）、客户满意度（例如对交付的用户故事按照总分 10 分进行评分），并且每一天都对燃尽图没有达到预期目标的原因进行分析。 2. 确保使用精益的方式表达问题对于某个问题的表达必须包含两个方面：所观察到的绩效和目标绩效。Pareto 是一种将原始的 bug 进行分类处理的优秀工具，但还要专门进行分析，以理解每个类别是如何影响到绩效的。 3. 这种方式可以保证你已经清晰地为划分了问题的类型，并且从商业绩效的角度以正确的次序分别进行处理。 4. 当问题出现时逐一分析解决精益式解决问题方法的关键之一，就在于不要试图同时解决多个问题。你只需要专注于一个问题，理解它如何影响你的绩效指标，并确保你理解造成该问题的原因所在。投稿信箱：editors@cn.infoq.com 95 进行校验很遗憾，根据我的经验来看，我们通常会倾向于忽略这一步骤。如果你的预估与现实不符、你的软件不能正常工作，那很好！你是否可以从中学到些什么？如果你所想象中会发生的事与实际发生的事产生了偏差，那这一段偏差就是可以从中进行学习的地方。这正是在第二个示例中的团队所做的事。正如 Stephen J. Spear 在他的著作《Chasing the Rabbit》中所写的一样，这是你的组织中的系统在向你发出的一种声音：“在我身上还有一些你所不了解的东西，但如果你愿意倾听，我就会告诉你。”团队正是这样才能够从工作与流程中快速地培养自己的专业技能，并真正地成为一支梦想中的团队。从敏捷到精益我从 2004 年开始成为一名敏捷实践者，而在过去的几年中，我的思维方式渐渐转为精益。正是它帮助我跨越了一些单纯依靠敏捷无法跨过的障碍。按我的经验来看，精益已经被证明是一种有效的手段，它能够帮助你超越敏捷，建立起一种持续改进的实践，并为团队带来直接的绩效提高和激励作用。而明确地区分 bug 与问题这一方式已经被证实是对持续改进的一大助力。如果你也开始了这一相同的过程，你是否能指出 bug 与问题之间有哪些关键的区别因素吗？关于作者 Cecil Dijoux 在 Operae Partners 担任精益 IT 教练，他是一位具有 25 年国际经验的 IT 专家。他对探索 21 世纪的管理方式（精益、敏捷、Enterprise 2.0 等等）充满热情。Cecil 在他的博客 http://thehypertextual.com/ 中写了大量有关于互联世界中的组织文化方面的文章，有法语和英语两个版本。纽约时报在线和 Read Write Enterprise 曾经专门报道过他的一篇博客文章。Cecil 还是一位国际性的演讲者，并且还是一份法语电子书“#hyperchange - petit guide de la conduite du changement dans l'économie de la connaissance”的作者，书中主要描写了关于知识经济时代的管理方式的变化。查看英文原文：Bug Fixing Vs. Problem Solving - From Agile to Lean 原文：http://www.infoq.com/cn/articles/bug-ﬁxing-problem-solving 96 2014 年 6 月《架构师》不要就这么放弃了 SQL 作者 Lukas Eder ，译者石岩 SQL 这门语言已经稳定地发展了的 20 多年。同时，Java 客户端代码中冗长的 JDBC API 和 Java 语言缺乏一流的 SQL 支持的情况，使得 ORM 开发框架开始渐渐占据一席之地，例如后来作为标准加入到 JPA 和 Criteria API 中的 Hibernate。然而，出于性能上和表述上的考虑，一些用户还通过复杂的 SQL 查询语句和数据库进行交互 - 这种复杂性和 JPA 中所覆盖到的特性是相悖的。如果 SQL 和 JPA 越来越背离，我们的数据交互模式应该何去何从？最近的 TopConf 2013 大会对我的影响软件大会是我们行业在未来的 5 到 10 年将如何进展的新趋势和新思维的指向标。Topconf 是一场在美丽的爱沙尼亚，塔林新举办的令人期待的大会，相当多的技术演讲都是关于大规模、分布式数据处理，以及新兴的技术和范例。第二天的开场主题演讲是由 GridGain 公司的创始人和 CEONikita Ivanov 所做的一场关于记忆体内运算方面的演讲。之后不久来自 Hazelcast 的 Christoph Engelbert 举办了一个比赛演讲，不少的演讲都是关于异步编程和响应式编程，后者是一种新兴的范式，起源于 Scala 的“subculture”，通过共用服务器上的可计算资源，来处理水平伸缩的情况。无论何时，只要“垂直伸缩”和“水平伸缩”这样时髦的名词出现，一些广为人知的 NoSQL ——比如MongoDB 或者Cloudera（Hadoop）也会跟随出现。Nikita Ivanov 和 Christoph Engelbert 都提到了一个很好的观点，当我们在考虑伸缩问题的时候，这一观点将对我们的想法起到更真实和实际的影响。垂直伸缩还是水平伸缩？集中化还是分布式？首先，DRAM 的价格在过去几年飞速下跌，你都不敢想象十年前的记忆体内计算（那时候大概 1 美元 /MB），而现在很多公司有能力把他们所有的在线交易数据全放到内存中（大概 1 美元 /GB）。就像 Nikita 说的，99% 的公司都没有 9TB 大的在线数据量，这是在可支持的范围内的。这就允许把大量的数据从磁盘中（毫秒级别的访问）转移到内存中（纳秒级别的访问），而不用实际上改变软件架构！换句话来说，不需要使用什么新奇的技术，就可以使遗留系统得到量级的提速。这对正在从 COBOL 迁移至 Java，而又不太情愿替换关系数据库的大公司非常重要。再换句话来说，也许实际上我们并不需要新的数据存储范式。不是吗？另一方面，数据量仍然在不断变得越来越大，而且人们想进行数据分片和数据分布式，物理上让数据更接近用户。即便是真的有这么一台可以计算的机器，可以迅速地处理越来越大的记忆体内计算，将巨大的数据通过网线传输，也会连续遇到网络延迟、包丢失和别的原因导致的性能问题等方面所造成的困扰。 Hazelcast 实施了一种“新的”范式，即把计算转向数据，而不是把数据转向计算。这也是 OLAP 数据库一直以来长时间在做的事情。现代的 RDBMS 融入基于 SQL 的语言，在接近数据的位置执行存储过程，这种语言很复杂而且很具有表述力。实际上，这甚至很像早期的共享主机系统，比如 IBM 7094，那时候开发者在中央计算引擎上分享时间槽。所以这并不是新的范式。我们只是在体验分布式和集中化计算的周期振荡，基于可用的资源和这些资源的力量。如果说 NoSQL 是分布式的强大力量，那么下降的 DRAM 价格就是集中化的强大力量。投稿信箱：editors@cn.infoq.com 97 同时，企业级 Java 中发生了什么？这些主题是怎么关联到最近 Charles Humble 在 InfoQ 的调查，关于我们怎么在 Java 中访问关系数据库的呢？根据他和 Martin Fowler 的观察，通常人们似乎对 ORM 变得越来越不满了。这些情感变化很大一部分是因为 ORM 会发生是一种泄漏的抽象（Leaky Abstractions）的这一事实。Joel Spolsky 很久之前就已经观察到了这一点。最近 JEE 7 中的 JPA 2.1 标准升级引入了一些的功能，可以更好地和“高级”的数据库特性进行集成，例如存储过程。关系数据库变得更符合 SQL 的标准，这个标准在不断地朝无法用 JPA 表述的方向发展。通过 ISO/IECSQL:1999 标准，我们可以利用分组集和（递归式的）通用表表达式。有了 SQL：2003 标准，我们已经有了非常复杂的开窗函数和 MERGE 语句。有了 SQL:2008 标准，我们可以执行分段的 JOIN 语句。通过 SQL:2011 标准，现在我们可以和临时数据库进行交互操作（现在 IBM DB2 和 Oracle 都已实现）。上述这些特色没有一个在 JPA 中或者别的大多数 Charles Humble 所列举的 ORM 中有所体现，除了 jOOQ——Java 建模 SQL 中一种类型安全的内部领域特定语言（在 Topconf 大会上也有相关主题的演讲）。也就是说，当数据管理市场以快速的步伐扩大的时候，企业级 Java 社区还在慢慢地以小版本号的幅度更新着持久化 API。未来会发生什么？我们可以说的是，在未来几年软件技术会快速地变化。以下是一些将会被质疑的范式：数据存储 RDBMS 已经很好地服务于我们，并且在将来继续很好地服务于我们。它们的创建基于很复杂的和很可靠的理论——关系理论，这种模型能够适用于许多问题的解决。其它的类型的数据存储则会继续浮现，在非 RDBMS 市场中争夺新的优势。关于为什么应该选择别的数据存储而不是调整现有的，有两个基本的原因： • 对于高度层次型的或者非结构化的数据，关系数据模型不够用。 • ACID 不能满足极端的水平伸缩情况，网络潜在问题导致在分布式系统中所有的 A-C-I-D 都变成难以解决的问题。但是，当说到集成列存储（也被称为 NewSQL），更多的像是让老象学习新技能，关系型数据库制造者最终也会集成经过验证的 NoSQL 功能。语言命令式（和面向对象）编程在最近几年，已经受到函数式编程极大的挑战。显著的挑战者有 Scacla，Javascript，C# 3.0，VB 9 和 Java 8。一个简单的解释是，函数式编程让计算逻辑更加容易地接近数据。同时，产生的副作用是期望中的，这也被 Simon Peyton Jones 自己确认，当时他在和 LINQ 的创造者 Erik Meijer 讨论编程语言的未来。另一方面，Erik Meijer 创造的 LINQ 的人气，已经证明声明式查询语言是复杂的数据库交互的一种好范式。SQL 本身在之前提到的多样的新标准上不断提升。眼下，Facebook 已经开源了他们自己的 ANSI-SQL，它是建立在 Apache Hadoop 之上的，基于自己编写 98 2014 年 6 月《架构师》的查询语言。可以说，这些语言范式中没有一个可以被替代。 SQL 无所不在在数据处理上 SQL 无所不在，这让我们更加了解到为什么 Charles Humble 发现，在使用类似 Hibernate 这样传统的 ORM 时，会让人越来越不爽的重要原因。这些工具已经解决了以下两个问题： • CRUD 的重复性 • 缓存，可以提高磁盘访问速度。智能缓存是很困难的，即便是实现了很多实体级别的 SQL 缓存功能的 Hibernate。 Hibernate 或者 JPA 的缓存机制之所以能够现实，是因为 ORM 策略已经深深地和 JPQL 集成。由于缺乏原生查询功能，很难绕过缓存的核心机制。但是别忘了内存变得多么的便宜？缓存大多数数据可以保证很少量地访问磁盘。如果数据不再从磁盘上访问（毫秒级），而是从内存中访问（纳秒级）会怎么样？当数据库已经把所有相关的数据缓存到内存中，我们依然需要完整的和复杂的二级缓存吗？数据库不仅有能力把在线交易数据一直放在内存中，而且它们早就可以实现一些复杂的缓存机制了。想想 Oracle 的游标缓存，查询结果缓存，和标量子查询缓存吧。虽然 JPA 依然是 CRUD 操作的优秀工具，但以 SQL 为中心的工具正在被越来越多的人选择使用，比如：MyBatis 或者 jOOQ（都是“后 JPA 框架”）表明了一种需要再次更加接近 SQL 的确定需求。ANSI-SQL 标准不断发展，把不断革新的数据库的各种功能进行标准化，比如：Oracle，SQL Server，PostgreSQL，通常是那些很难集成到 JCP 甚至是今后的 JPA 版本中的一些特性。JPA 2.1 支持存储过程，但是在客户端代码管理的这些支持，看起来和在 JDBC 中实现的可调用语句（CallableStatements）一样单调乏味。另外， JPA 2.1 虽然有了各种新的与存储过程相关的注解，但并没有把嵌入式的用户自定义函数加入到 SQL 语句中，而这些却被不知名的 CriteriaQuery API 不充分的表述出来。大会上的所有关于 jOOQ 演讲，我都在问观众他们使用 CriteriaQuery 幸福吗。他们的回答是一致的不幸福。总结 RDBMS 仍旧在不断拥抱新的功能，按照 ANSI SQL 进行自我标准化，并逐渐放弃 JPA 2.x。在这几次变化中，JPA 规范看起来局限了数据存储市场进行的革新。EclipseLink 最近通过 JPA 扩展支持 MongoDB，表明了标准制定者并不确定他们将走向何方。但是有一件事情是确定的。我们不会这么快放弃 SQL。那么为什么不再次拥抱它？查看英文原文：Don’t jump the SQL ship just yet 感谢邵思华对本文的审校。原文：http://www.infoq.com/cn/articles/SQL-relevance-NoSQL 投稿信箱：editors@cn.infoq.com 99 封面植物栀子花灌木，高 0.3-3 米；嫩枝常被短毛，枝圆柱形，灰色。叶对生，革质，稀为纸质，少为 3 枚轮生，叶形多样，通常为长圆状披针形、倒卵状长圆形、倒卵形或椭圆形。产于山东、江苏、安徽、浙江、江西、福建、台湾、湖北、湖南、广东、香港、广西、海南、四川、贵州和云南，河北、陕西和甘肃有栽培；生于海拔 10-1 500 米处的旷野、丘陵、山谷、山坡、溪边的灌丛或林中。国外分布于日本、朝鲜、越南、老挝、柬埔寨、印度、尼泊尔、巴基斯坦、太平洋岛屿和美洲北部，野生或栽培。模式标本采自我国，具体地点不详。本种作盆景植物，称“水横枝”；花大而美丽、芳香，广植于庭园供观赏。干燥成熟果实是常用中药，其主要化学成分有去羟栀子甙，又称京尼平甙 (GENIPOSIDE)、栀子甙 (Gardenoside)、黄酮类栀子素 (Gardenin)、山栀甙 (Shanzhjside) 等；能清热利尿、泻火除烦、凉血解毒、散瘀。叶、花、根亦可作药用。从成熟果实亦可提取栀子黄色素，在民间作染料应用，在化妆等工业中用作天然着色剂原料，又是一种品质优良的天然食品色素，没有人工合成色素的副作用，且具有一定的医疗效果；它着色力强，颜色鲜艳，具有耐光、耐热、耐酸碱性、无异味等特点，可广泛应用于糕点、糖果、饮料等食品的着色上。花可提制芳香浸膏，用于多种花香型化妆品和香皂香精的调合剂。栀子花含挥发油，可提取芳香浸膏，用作调香剂；根、花、叶、果可入药，果有消炎解毒的功效，主治肺热咳嗽；根可清热、利湿、凉血、解毒，主治感冒高热、黄疸型肝炎等；成熟的栀子花果实为橙红色，可作黄色染料。架构师 2014.6月刊每月 8 号出版本期主编：侯伯薇责任编辑：杨赛发行人：霍泰稳读者反馈 / 投稿：editors@cn.infoq.com InfoQ 中文站新浪微博： http://weibo.com/infoqchina 商务合作：sales@cn.infoq.com 15810407783 本期主编：侯伯薇，InfoQ 中文站译者团队主编侯伯薇，生于丹东凤城，学在春城长春，工作在滨城大连 ; 虽已年过而立，但自问童心未泯 ; 对代码热情不减，愿与天下程序员共同修炼，不断提升。译有《学习 WCF》、《 Expert C# 2008 Business Objects》。

架构师 (2014年6月刊). pdf

patrick002

贡献于2015-03-15

相关文档