分析一道“微信”面试题

前一段时间，一道疑似“微信”招聘的面试题出现，可能有不少读者已经了解过了。这道题乍一看挺难，但是细细分析却还算简单，我们甚至可以用多种手段解题，用不同思想来给出答案。

网上零零碎碎的有一些解答，但是缺乏全面梳理。我认为通过这道题，有必要将前端多重知识点“融会贯通”，在这里和大家分享。

本讲知识点如下：

enter image description here

题意分析

我们来先看看题目：

实现一个 LazyMan，按照以下方式调用时，得到相关输出：

LazyMan("Hank")
// Hi! This is Hank!
 
LazyMan("Hank").sleep(10).eat("dinner")
// Hi! This is Hank!
// 等待10 秒..
// Wake up after 10
// Eat dinner~
 
LazyMan("Hank").eat("dinner").eat("supper")
// Hi This is Hank!
// Eat dinner~
// Eat supper~
 
LazyMan("Hank").sleepFirst(5).eat("supper")
// 等待 5 秒
// Wake up after 5
// Hi This is Hank!
// Eat supper

当面试者拿到这道题目的时候，乍看题干可能会有点慌张。其实很多面试失败是“自己吓唬自己”，在平时放松状态下写代码，也许解题不在话下。

下面我们就从接到题目开始，剖析应该如何进行分析：

• 可以把 LazyMan 理解为一个构造函数，在调用时输出参数内容

• LazyMan 支持链式调用

• 链式调用过程提供了以下几个方法：sleepFirst、eat、sleep

• 其中 eat 方法输出参数相关内容：Eat + 参数

• sleep 方法比较特殊，链式调用将暂停一定时间后继续执行，看到这里也许应该想到 setTimeout

• sleepFirst 最为特殊，这个任务或者这个方法的 优先级最高 ；调用 sleepFirst 之后，链式调用将暂停一定时间后继续执行。请再次观察题干，尤其是最后一个 demo，sleepFirst 的输出优先级最高，调用后先等待 5 秒输出 Wake up after 5，再输出 Hi This is Hank!

我们应该如何解这个题目呢，从拿到需求开始进行分析：

• 先从最简单的，我们可以封装一些基础方法，比如 log 输出、封装 setTimeout 等

• 因为 LazyMan 要实现一系列调用， 且调用并不是顺序执行的，比如如果 sleepFirst 出现在调用链时，优先执行；同时任务并不是全部都同步执行的 ，因此 我们应该实现一个任务队列 ，这个队列将调度执行各个任务

• 因此每次调用 LazyMan 或链式执行时，我们应该将相关调用方法加入到（push）任务队列中，储存起来，后续统一被调度

• 在写入任务队列时，如果当前的方法为 sleepFirst，那么需要将该方法放到队列的最头处，这应该是一个 unshift 方法

这么一分析，这道题就“非常简单”了。

我们来试图解剖一下这道题目的考察点：

• 面向对象思想与设计，包括类的使用等

• 对象方法链式调用的理解和设计

• 小部分设计模式的设计

• 因为存在“重复逻辑”，考察代码的解耦和抽象能力

• 逻辑的清晰程度以及其他编程思维

常规思路解答

基于以上思路，我们给出较为常规的答案，其中代码已经加上了必要的注释：

class LazyManGenerator {
  constructor(name) {
    this.taskArray = []

    // 初始化时任务
    const task = () => {
      console.log(`Hi! This is ${name}`)
      // 执行完初始化时任务后，继续执行下一个任务
      this.next()
    }

    // 将初始化任务放入任务队列中
    this.taskArray.push(task)

    setTimeout(() => {
      this.next()
    }, 0)
  }

  next() {
      // 取出下一个任务并执行
    const task = this.taskArray.shift()
    task && task()
  }

  sleep(time) {
    this.sleepTask(time, false)
    // return this 保持链式调用
    return this
  }

  sleepFirst(time) {
    this.sleepTask(time, true)
    return this
  }

  sleepTask(time, prior) {
    const task = () => {
      setTimeout(() => {
        console.log(`Wake up after ${time}`)
        this.next()
      }, time * 1000)
    }

    if (prior) {
      this.taskArray.unshift(task)
    } else {
      this.taskArray.push(task)
    }
  }

  eat(name) {
    const task = () => {
      console.log(`Eat ${name}`)
      this.next()
    }

    this.taskArray.push(task)
    return this
  }
}

function LazyMan(name) {
  return new LazyManGenerator(name)
}

简单分析一下：

• LazyMan 方法返回一个 LazyManGenerator 构造函数的实例

• 在 LazyManGenerator constructor 当中，我们维护了 taskArray 用来存储任务，同时将初始化任务放到 taskArray 当中

• 还是在 LazyManGenerator constructor 中，将任务的逐个执行即 next 调用放在 setTimeout 中，这样就能够保证在开始执行任务时，taskArray 数组已经填满了任务

• 我们来看看 next 方法，取出 taskArray 数组中的首项，进行执行

• eat 方法将 eat task 放到 taskArray 数组中，注意 eat task 方法需要调用 this.next() 显式调用“下一个任务”；同时返回 this，完成链式调用

• sleep 和 sleepFirst 都调用了 sleepTask，不同在于第二个参数：sleepTask 第二个参数表示是否优先执行，如果 prior 为 true，则使用 unshift 将任务插到 taskArray 开头

这个解法最容易想到，也相对来说容易，主要是面向过程。关键点在于对于 setTimeout 任务队列的准确理解以及 return this 实现链式调用的方式。

事实上，sleepTask 应该作为 LazyManGenerator 类的私有属性出现，因为 ES class 暂时 private 属性没有被广泛实现，这里不再追求实现。

设计模式解答

关于这道题目的解答，网上最流行的是一种发布订阅模式的方案。相关代码出处：lazyMan。

但是其实仔细看其实现，也是上一环节中常规解法的变种。虽然说是发布订阅模式，但是其实仍然是 next 思想执行下一个任务的思路，该实现 publish 和 subscribe 方法分别是完成执行任务和注册任务逻辑。我认为这样的代码实现有一点“过度设计”之嫌，更像是往发布订阅模式上去靠，整体流程不够自然。

当然读者仍可参考，并有自己的思考，这里我不再更多分析。

再谈流程控制和队列、中间件启发

这道题目我们给出解法并不算完，更重要也更有价值的是思考、延伸。微信题目较好地考察了候选者的流程控制能力，而流程控制在前端开发者面前也非常重要。

我们看上述代码中的 next 函数，它负责找出 stack 中的下一个函数并执行：

next() {
    // 取出下一个任务并执行
    const task = this.taskArray.shift()
    task && task()
}

NodeJS 中 connect 类库，以及其他框架的中间件设计也都离不开类似思想的 next。比如生成器自动执行函数 co、redux、koa 也通过不同的实现，可以让 next 在多个函数之间执行完后面的函数再折回来执行 next，较为巧妙。我们具体来看一下。

senchalabs connect 和 express

具体场景：在 Node 环境中，有 parseBody、checkIdInDatabase 等相关中间件，他们组成了 middlewares 数组：

const middlewares = [
  function middleware1(req, res, next) {
    parseBody(req, function(err, body) {
      if (err) return next(err);
      req.body = body;
      next();
    });
  },
  function middleware2(req, res, next) {
    checkIdInDatabase(req.body.id, function(err, rows) {
      if (err) return next(err);
      res.dbResult = rows;
      next();
    });
  },
  function middleware3(req, res, next) {
    if (res.dbResult && res.dbResult.length > 0) {
      res.end('true');
    }
    else {
      res.end('false');
    }
    next();
  }
]

当一个请求打开时，我们需要链式调用各个中间件：

const requestHandler = (req, res) => {
  let i = 0

  function next(err) {
    if (err) {
      return res.end('error:', err.toString())
    }

    if (i < middlewares.length) {
      middlewares[i++](req, res, next)
    } else {
      return
    }
  }

  // 初始执行第一个中间件
  next()
}

基本思路和面试题解法一致：

• 将所有中间件（任务处理函数）储存在一个 list 中

• 循环依次调用中间件（任务处理函数）

senchalabs/connect 这个库做了很好的封装，是 express 等框架设计实现的原始模型。这里我们简单分析一下 senchalabs/connect 这个库的实现。

用法：

首先使用 createServer 方法创建 app 实例，

const app = createServer()

对应源码：

function createServer() {
  function app(req, res, next){ app.handle(req, res, next); }
  merge(app, proto);
  merge(app, EventEmitter.prototype);
  app.route = '/';
  app.stack = [];
  return app;
}

我们看 app 实例“继承”了 EventEmitter 类，实现事件发布订阅，同时 stack 数组来维护各个中间件任务。

接着使用 app.use 来添加中间件：

app.use('/api', function(req, res, next) {//...})

源码实现：

proto.use = function use(route, fn) {
  var handle = fn;
  var path = route;

  // default route to '/'
  if (typeof route !== 'string') {
    handle = route;
    path = '/';
  }

  // wrap sub-apps
  if (typeof handle.handle === 'function') {
    var server = handle;
    server.route = path;
    handle = function (req, res, next) {
      server.handle(req, res, next);
    };
  }

  // wrap vanilla http.Servers
  if (handle instanceof http.Server) {
    handle = handle.listeners('request')[0];
  }

  // strip trailing slash
  if (path[path.length - 1] === '/') {
    path = path.slice(0, -1);
  }

  // add the middleware
  debug('use %s %s', path || '/', handle.name || 'anonymous');
  this.stack.push({ route: path, handle: handle });

  return this;
};

通过 if...else 逻辑区分出三种不同的 fn 类型：

• fn 是一个普通的 function(req,res[,next]){} 函数

• fn 是一个普通的 httpServer

• fn 是一个普通的是另一个 connect 的 app 对象（sub app 特性）

对于这三种类型，分别转换为 function(req, res, next) {} 的形式，具体我们不再分析。最重要的执行过程是：

this.stack.push({ route: path, handle: handle })

以及返回：

return this

以上就完成了中间件即任务的注册，我们有：

app.stack = [function1, function2, function3, ...];

接下来看看任务的调度和执行。使用方法：

app.handle(req, res, out)

handle 源码实现：

proto.handle = function handle(req, res, out) {
  var index = 0;
  var protohost = getProtohost(req.url) || '';
  var removed = '';
  var slashAdded = false;
  var stack = this.stack;

  // final function handler
  var done = out || finalhandler(req, res, {
    env: env,
    onerror: logerror
  });

  // store the original URL
  req.originalUrl = req.originalUrl || req.url;

  function next(err) {
    // ...
  }

  next();
};

源码导读：out 参数是关于 sub app 的特性，这个特性可以暂时忽略，我们暂时不关心。handle 实现我们并不陌生，它构建 next 函数，并触发第一个 next 执行。

next 实现：

function next(err) {
    if (slashAdded) {
      req.url = req.url.substr(1);
      slashAdded = false;
    }

    if (removed.length !== 0) {
      req.url = protohost + removed + req.url.substr(protohost.length);
      removed = '';
    }

    // next callback
    var layer = stack[index++];

    // all done
    if (!layer) {
      defer(done, err);
      return;
    }

    // route data
    var path = parseUrl(req).pathname || '/';
    var route = layer.route;

    // skip this layer if the route doesn't match
    if (path.toLowerCase().substr(0, route.length) !== route.toLowerCase()) {
      return next(err);
    }

    // skip if route match does not border "/", ".", or end
    var c = path.length > route.length && path[route.length];
    if (c && c !== '/' && c !== '.') {
      return next(err);
    }

    // trim off the part of the url that matches the route
    if (route.length !== 0 && route !== '/') {
      removed = route;
      req.url = protohost + req.url.substr(protohost.length + removed.length);

      // ensure leading slash
      if (!protohost && req.url[0] !== '/') {
        req.url = '/' + req.url;
        slashAdded = true;
      }
    }

    // call the layer handle
    call(layer.handle, route, err, req, res, next);
}

源码导读：

• 取出下一个中间件

var layer = stack[index++]

• 如果当前请求路由和 handler 不匹配，则跳过：

if (path.toLowerCase().substr(0, route.length) !== route.toLowerCase()) {
  return next(err);
}

• 若匹配，则执行 call 函数，call 函数实现：

function call(handle, route, err, req, res, next) {
  var arity = handle.length;
  var error = err;
  var hasError = Boolean(err);

  debug('%s %s : %s', handle.name || '<anonymous>', route, req.originalUrl);

  try {
    if (hasError && arity === 4) {
      // error-handling middleware
      handle(err, req, res, next);
      return;
    } else if (!hasError && arity < 4) {
      // request-handling middleware
      handle(req, res, next);
      return;
    }
  } catch (e) {
    // replace the error
    error = e;
  }

  // continue
  next(error);
}

注意：我们使用了 try...catch 包裹逻辑，这是很必要的容错思维，这样第三方中间件的执行如果出错，不至于打挂我们的应用。

较为巧妙的一点是：function(err, req, res, next){} 形式为错误处理函数，function(req, res, next){} 为正常的业务逻辑处理函数。因此通过 Function.length 来判断当前 handler 是否为容错函数，来做到参数的传入。

call 函数是 next 函数的核心，它是一个执行者，并在最后的逻辑中继续执行 next 函数，完成中间件的顺序调用。

NodeJS 的框架 express，实际就是 senchalabs connect 的升级版，通过对 connect 源码的学习，我们应该更加清楚流程的调度和控制，再去看 express 就轻而易举了。

Senchalabs connect 用流程控制库的回调函数及中间件的思想来解耦回调逻辑；Koa 则是用generator 方法解决回调问题（最新版使用 async/await）。事实上，也可以用事件、Promise 的方式实现，下一环节，我们就分析 Koa 的洋葱模型。

Koa 的洋葱模型

对 Koa 中间的洋葱模型的分析文章上不少，著名的洋葱圈图示我也不在自己画了，具体使用不再介绍，不了解的读者请先自行学习。

我想先谈一下面向切面编程（AOP），在 JavaScript 语言为例，一个简单的示例：

Function.prorotype.before = function (fn) {
  const self = this
  return function (...args) {
    console.log('')
    let res = fn.call(this)
    if (res) {
      self.apply(this, args)
    }
  }
}

Function.prototype.after = function (fn) {
  const self = this
  return function (...args) {
    let res = self.apply(this, args)
    if (res) {
      fn.call(this)
    }
  }
}

这样的代码实现，是我们能够在执行某个函数 fn 之前，先执行某段逻辑；在某个函数 fn 之后，再去执行另一段逻辑。其实是一种简单中间件流程控制的体现。不过这样的 AOP 有一个问题：无法实现异步模式。

那么如何实现 Koa 的异步中间件模式呢？即某个中间件执行到一半，交出执行权，之后再回来继续执行。我们直接看源码分析，这段源码实现了 Koa 洋葱模型中间件：

function compose(middleware) {
  return function *(next) {(
    if (!next) next = noop();

    var i = middleware.length;

    while (i--) {
      next = middleware[i].call(this, next);
      console.log('isGenerator:', (typeof next.next === 'function' && typeof next.throw === 'function')); // true
    }

    return yield *next;
  }
}

function *noop(){}

其中，一个中间件的写法类似：

app.use(function *(next){
  var start = new Date;
  yield next;
  var ms = new Date - start;
  this.set('X-Response-Time', ms + 'ms');
});

这是一个很简单的记录 response time 的中间件，中间件跳转的信号是 yield next。

较新版本的 Koa 已经改用 async/await 实现，思路也是完全一样的，当然看上去更加优雅：

function compose (middleware) {
  if (!Array.isArray(middleware)) throw new TypeError('Middleware stack must be an array!')
  for (const fn of middleware) {
    if (typeof fn !== 'function') throw new TypeError('Middleware must be composed of functions!')
  }

  return function (context, next) {
    let index = -1
    return dispatch(0)

    function dispatch (i) {
      if (i <= index) return Promise.reject(new Error('next() called multiple times'))
      index = i
      let fn = middleware[i]
      if (i === middleware.length) {
        fn = next
      }
      if (!fn) return Promise.resolve()
      try {
        return Promise.resolve(fn(context, function next () {
          return dispatch(i + 1)
        }))
      } catch (err) {
        return Promise.reject(err)
      }
    }
  }
}

我们来重点解读一下这个版本的实现：

• compose 传入的 middleware 参数必须是数组，否则抛出错误

• middleware 数组的每一个元素必须是函数，否则抛出错误

• compose 返回一个函数，保存对 middleware 的引用

• compose 返回函数的第一个参数是 context，所有中间件的第一个参数就是传入的 context

• compose 返回函数的第二个参数是 next 函数，next 是实现洋葱模型的关键

• index 记录当前运行到第几个中间件

• 执行第一个中间件函数：return dispatch(0)

• dispatch 函数中，参数 i 如果小于等于 index，说明一个中间件中执行了多次 next，我们进行报错，由此可见一个中间件函数内部不允许多次调用 next 函数

• 取出中间件函数 fn = middleware[i]

• 如果 i === middleware.length，说明执行到了圆心，将 next 赋值给 fn

• 因为 async 需要后面是 Promise，我们包一层 Promise

• next 函数是固定的，它可以执行下一个中间件函数

function next () {
  return dispatch(i + 1)
}

如果读者不好理解，可以参考应用示例：

async function middleware1(ctx, next) {
  console.log('1')
  await next()
  console.log('2')
};

async function middleware2(ctx, next) {
  console.log('3')
  await next()
  console.log('4')
};

如果读者还是难以理解，我给出一个简版逻辑：

function compose (middleware) {
  return dispatch(0) 
  function dispatch(i) {
    fn = middleware[i]
    if(!fn) return
    return fn(() => dispatch(i + 1))
  }
}

co 库不再神秘

说到流程控制，也少不了大名鼎鼎的 co 库。co 函数库是 TJ 大神基于 ES6 generator 的异步解决方案，因此这里需要读者熟练掌握 ES6 generator。目前虽然 co 库可能不再“流行”，但是了解其实现，模拟类似场景也是非常有必要的。

我们这里不解读其源码，而是实现一个类似的自动执行 generator 的方案：

const runGenerator = generatorFunc => {
  const it = generatorFunc()
  iterate(it)

  function iterate (it) {
    step()

    function step(arg, isError) {
      const {value, done} = isError ? it.throw(arg) : it.next(arg)

      let response

      if (!done) {
        if (typeof value === 'function') {
          response = value() 
        } else {
          response = value  
        }

        Promise.resolve(response).then(step, err => step(err, true))
      }
    }
  }
}

代码解读：

• runGenerator 函数接受一个生成器函数 generatorFunc

• 运行 generatorFunc 得到结果，并通过 iterate 函数，迭代该生成器结果

• iterate 函数中执行 step 函数，step 函数的第一个参数 arg 是上一个 yield 右表达式的“求出的值”，即下面对应的 response

• 这里需要考虑 response 的求值过程，它通过 value 计算得来，value 是 yield 右侧的值，它有这么几种情况：

• yield new Promise()，value 是一个 promise 实例，那么 response 就是该 Promise 实例 resolve 后的值

• yield () => {return value}，value 是一个函数，那么 response 就是执行该函数后的返回值

• yield value，value 是一个普通值，那么 response 就是该值

• 我们最终统一利用 Promise.resolve 的特性，对 response 进行处理，并递归（迭代）调用 step

• 同时利用 step 函数 arg 参数，赋值给上一个 yield 的左表达式值，并返回下一个 yield 右表达式的值

执行代码：

function* gen1() {
  yield console.log(1)
  yield console.log(2)
  yield console.log(3)
}

runGenerator(gen1)

或者：

function* gen2() {
  var value1 = yield Promise.resolve('promise')
  console.log(value1)

  var value2 = yield () => Promise.resolve('thunk')      
  console.log(value2)

  var value3 = yield 2
  console.log(value3)
}

 runGenerator(gen2);

最后还是附上 co 的实现：

function co(gen) { // co 接受一个 generator 函数
    var ctx = this
    var args = slice.call(arguments, 1)

    return new Promise(function(resolve, reject) { // co 返回一个 Promise 对象
        if(typeof gen === 'function') gen = gen.apply(ctx, args) // gen 为 generator 函数，执行该函数
        if(!gen || typeof gen.next !== 'function') return resolve(gen) // 不是则返回并更新 Promise状态为 resolve

        onFulfilled() // 将generator 函数的 next 方法包装成 onFulfilled，主要是为了能够捕获抛出的异常

        /**
          * @param {Mixed} res
          * @return {Promise}
          * @api private
         */
        function onFulfilled(res) {
            var ret;
            try {
                ret = gen.next(res)
            } catch (err) {
                return reject(err)
            }
            next(ret)
        }

        /**
          * @param {Error} err
          * @return {Promise}
          * @api private
         */
        function onRejected(err) {
            var ret
            try {
                ret = gen.throw(err)
            } catch (err) {
                return reject(err)
            }
            next(ret)
        }

        /**
          * Get the next value in the generator,
         * return a promise.
         *
         * @param {Object} ret
         * @return {Promise}
         * @api private
         */
        function next(ret) {
            if(ret.done) return resolve(ret.value)
            var value = toPromise.call(ctx, ret.value) // if (isGeneratorFunction(obj) || isGenerator(obj)) return co.call(this, obj);
            if(value && isPromise(value)) return value.then(onFulfilled, onRejected)
            return onRejected(new TypeError('You may only yield a function, promise, generator, but the following object was passed: ' + String(ret.value) + '"'))
        }
    })
}

如果读者对于以上内容理解有困难，那么我建议还是从 generator 等最基本的概念切入，不必心急，慢慢反复体会。

总结

这道“著名”的“微信”面试题，绝不只是网上分析的几行代码答案那么简单，本讲我们从这道题目出发，分析了几种解决方案。更重要的是，在解决方案的基础上，我们重点剖析了 JavaScript 处理任务流程、控制触发逻辑的方方面面。也许在小型传统页面应用中，这样“相对复杂”的处理场景并不多见，但是在大型项目、富交互项目、后端 NodeJS 中非常重要，尤其是中间件思想、洋葱模型是非常典型的编程思路，希望读者能认真体会。

最后我们分析了 generator 以及 Koa 中间件实现原理，也许读者在平时基础业务开发中接触不到这些知识，但是请想一想 redux-saga 的实现、中间件的编写，其实都是这些内容运用体现。进阶即是如此，如果不掌握好这些“难啃”的知识，那么永远无法写出优秀的框架和解决方案。