Limbo: 简单访问远程数据库

简聊一下 轻松协作

对于 nodejs 生态来说,使用 mongoose 作为 Model 模块是再好不过的一件事,其一大特点就是简洁优雅的 Schema 定义,提供了每个键值的类型验证,数据验证,索引声明,虚拟键,并自带实例化方法的扩展,大大节省了开发的成本。但是在考虑开放数据的时候,一切就显得不那么美好了。

在打造简聊这款应用的过程中,我们就实实在在的遇到了这样的问题。由于需要使用 Teambition 的用户和团队数据,并且当简聊更新了用户数据之后,在 Teambition 中能实时的将这些更新推送到用户那里。按照惯例,我们最初使用的是 restful 接口。

第一阶段,使用 restful 接口

restful 接口的应用面最广,但是仍然存在很多不足,比如接口在参数和结构上限制较多,在考虑修改接口 api 的时候,往往会顾虑客户端的兼容性,而一旦客户端程序有新的需求,则需等待接口的更新。另一个麻烦的地方是需要做签名校验,对于内部的应用来说,我们完全可以通过防火墙来控制特定 ip 对端口的访问,签名在此处就显得有点多余。

第二阶段,单独拆封 Schema

然后我们想到了将 Schema 拆封成一个单独的仓库,nodejs 有良好的模块管理,在不同的应用中,我们只需要将这些模块引入进来,既做到同步更新,又做到 DRY。相对于 restful 接口的缺点就是,对于数据的调用入口过多,而且应用之间互相是不知情的。例如在简聊中有更新用户数据,在 Teambition 中就无法得知,并推送给其他客户端。

第三阶段,远程过程调用(rpc)

这个阶段和 restful 接口其实类似,我们在 Teambition 的后端进程中将一些接口方法暴露出来,这样我们的客户端程序就能通过简单的 rpc 方式调用这些接口。例如我们导出了 user.update 方法,在客户端代码中使用 rpc.call('user.update', params, callback) 即可调用相应的过程。这样的调用行为与使用本地代码无异,可能是目前能找到的最简单直接的方式了。

第四阶段,rpc 与 mongoose 的结合

事情可以变得更简单,由于目的主要是为了操作数据库,所以我们开发了一个模块 limbo,将 mongoose model 中所有方法暴露出来,以命名空间来划分,实现了在客户端与服务端程序一致的使用体验。

例如我们在服务端程序中使用 limbo 连接 mongodb,只需要做如下声明:(以下的代码都以 coffeescript 作为示例)

1
2
3
4
5
6
7
8
9
10
11
limbo = require 'limbo'

# 定义 Schema
UserSchame = (Schema) ->
  # 这里的 Schema 即 mongoose.Schema
  new Schema
    name: String
    email: String

# use 方法用作区分不同数据库连接的命名空间,一般参数选择数据库名就行
db = limbo.use('test').connect('mongodb://localhost:27017/test').load 'User', UserSchema

使用方式就与 mongoose 一致了

1
2
3
4
user = db.user
# user 是一个 limbo 中用于封装 model 的一个对象,你可以直接使用 user.model 来直接调用 mongoose model
user.findOne _id: 'xxxx'
user.create name: 'xxx', email: 'yyy'

下面是 limbo 中最激动人心的地方,你可以导出一个 collection 中的所有方法到 rpc server 中,只需要通过一个简单的声明

1
limbo.use('test').bind(7001).enableRpc()

下面我们就要提到如何在客户端程序中调用这些方法

1
2
3
4
5
6
7
8
9
10
11
# 在客户端也需要初始化一个 limbo 命名空间,需要与服务端一致,链接改为服务端的域名和端口号
db = limbo.use('test').connect('tcp://localhost:7001')

# 下面有两种方式来使用 rpc
# 1. 使用 call 方法
db.call 'user.findOne', _id: 'xxxx', ->
# 2. 使用方法链
db.user.findOne _id: 'xxxx', ->
# 第二种方式存在一个延迟,必须要在 limbo 与服务端程序握手成功之后才可以使用,
# 否则会抛出一个对象不存在的异常,不过在一般的应用中,
# 初始化所需的时间都会长于这个链接所需时间,所以延迟可以忽略不计了

可以看出,上面的第二种方式与服务端在本地使用 mongoose 的方式一模一样,这种黑魔法式的调用方式应该是广大码农喜闻乐见的。

limbo 另一个值得称道的功能是可以在服务端程序监听这些远程调用的事件,这得益于 nodejs 的 event 对象,limbo 本身就继承于 EventEmitter 对象,所以我们在每次远程调用后会触发一个事件给服务端程序,而在服务端只需要简单的监听这个事件即可

1
limbo.on 'test.user.findOne', (user) -> ...

正是这种 rpc 加事件反馈的机制,让简聊Teambition 可以实现简单实时的数据交换。我们将 limbo 托管在 github 上开源,是深知它还存在很多可以改进的地方,所以不免庸俗的说一句,欢迎 issue 和 pr~

最后,欢迎访问我们的新产品简聊,一款基于话题的轻量级协作应用。

给 Github Page 设置域名

Github 免费提供了很棒的静态站托管服务 github pages,并且为每人准备了一个二级域名 username.github.io。

但是对于喜欢个性又爱折腾的码农来说,使用别人的域名,是万万不能忍受滴,所以 github 支持了绑定个人域名。

英语不错的可直接传送官方文档 Tips for configuring a CNAME record with your DNS provider,如我这样记性不好的,就看下面的流程:

首先,你得有个自己的域名,比如这个 jingxin.me,然后我的目标是绑定到 sailxjx.github.io,并支持所有二级域名的跳转,如从 sailxjx.github.io/blog 会自动转到 jingxin.me/blog。

然后,我们要创建 CNAME 记录,这一步要在个人域名托管的 dns 服务上操作,添加一条 CNAME 记录,指向 sailxjx.github.io,这样,就实现了通过 jingxin.me 访问 github page 内容的目的。通过 dig 命令可以查看是否生效,这个时候如果你用 ping 或者 nslookup 会看到两个域名的 ip 是一样的。

1
2
3
4
5
$ dig jingxin.me +nostats +nocomments +nocmd
;jingxin.me.                  IN  A
jingxin.me.             346   IN  CNAME sailxjx.github.io.
sailxjx.github.io.      3346  IN  CNAME github.map.fastly.net.
github.map.fastly.net.  46    IN  A 103.245.222.133

最后,当然是告诉 github 需要自动从 sailxjx.github.io 跳转到 jingxin.me,是需要在相关的 repository 中添加一个 CNAME 文件,里面保留一行域名记录(不包含 http 等 schema 部分),比如这里,push 之后就可以在项目的设置中看到这样的提示

pages-section.png

下面就是短暂的等待了,快的话立即就生效了。

多余的话

除了使用 CNAME,github 还提供了另一种做法 Apex domains,由于官方并不推荐,所以这里也就不介绍了。

回调 vs 协同程序

原文地址:Callbacks vs Coroutines

最近 Google V8 引擎的一个补丁提供了 ES6 生成器,一篇叫做“用 Javascript 生成器来解决回调问题的研究”的文章引发了很大的争议。虽然生成器到目前为止仍然需要 --harmony--harmony-generators 选项才能激活,但是它已经值得你跃跃欲试!在这篇文章中我想要阐述的是自己对于协同程序的体验,并且说明为什么我认为它们是一种好方法。

回调和生成器

在认识回调和生成器之间的不同之前,我们先来看看生成器在 Nodejs 或浏览器这种由回调主宰的环境中是怎样发挥作用的。

首先生成器是回调的一种扩展,有些类型的回调就是用来“模拟”生成器的。这些“futures”,“thunks”,或“promises” —— 无论你怎么称呼,都是用来延迟执行一小段逻辑的,就好比你 yield 了一个变量然后由生成器来处理其他的部分。

一旦这些变量 yield 给了调用方,这个调用方等待回调然后重新回到生成器。见仁见智,生成器的原理和回调其实是一样的,然而下面我们会说到使用它的一些好处。

假如你还是不太清楚该怎么使用生成器,这里有一个简单的例子实现了由生成器来控制流程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
var fs = require('fs');
function thread(fn) {
  var gen = fn();
  function next(err, res) {
    var ret = gen.next(res);
    if (ret.done) return;
    ret.value(next);
  }

  next();
}
thread(function *(){
  var a = yield read('app.js');
  var b = yield read('package.json');
  console.log(a);
  console.log(b);
});
function read(path) {
  return function(done){
    fs.readFile(path, 'utf8', done);
  }
}

为什么协同程序会使代码更健壮

对于传统的浏览器或 Nodejs 环境,协同程序在自己的堆栈上运行每个“纤程”。这些纤程的实现各不相同,但是它们只需要一个很小的栈空间就能初始化(大约4kb),然后随需求增长。

为什么这样棒极了?错误处理!假如你使用过 Nodejs, 你就会知道错误处理不是那么简单。有些时候你会得到多个包含未知边际效应的回调,或者完全忘了回调这回事并且没有正确的处理和汇报异常。也许你忘了监听一个“error”事件,这样的话它就变成了一个未捕获的异常而让整个进程挂掉。

有些人喜欢使用进程,而且这样也挺好,但是作为一个在早期就使用 Nodejs 的人来说,在我看来这种流程有很多地方值得改进。Nodejs 在很多方面都很出色,但是这个就是它的阿喀琉斯之踵。

我们用一个简单的例子来看看由回调来读写同一个文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
function read(path, fn) {
  fs.readFile(path, 'utf8', fn);
}
function write(path, str, fn) {
  fs.writeFile(path, str, fn);
}
function readAndWrite(fn) {
  read('Readme.md', function(err, str){
    if (err) return fn(err);
    str = str.replace('Something', 'Else');
    write('Readme.md', str, fn);
  });
}

你可能会想这看起来也没那么糟糕,那是因为你整天看到这样的代码!好吧这是错误的:)为什么?应为大多数 node 核心方法,和多数第三方库都没有 try/catch 他们的回调。

下面的代码会抛出一个未捕获异常而且没有任何方法能捕获它。就算内核检测到这个异常并且告诉调用方这可能是一个错误点,大多数回调都有未知的行为。

1
2
3
4
5
6
7
8
function readAndWrite(fn) {
  read('Readme.md', function(err, str){
    throw new Error('oh no, reference error etc');
    if (err) return fn(err);
    str = str.replace('Something', 'Else');
    write('Readme.md', str, fn);
  });
}

所以生成器是怎么来优化这一点的?下面的代码片段用生成器和 Co 库来实现了相同的逻辑。你可能会想“这只是一些愚蠢的语法糖而已” - 但是你错了。只要我们将生成器传给 Co() 方法,所有委派给调用方的 yields,特别是强健的错误处理都会由 Co 来委派。

1
2
3
4
5
co(function *(){
  var str = yield read('Readme.md')
  str = str.replace('Something', 'Else')
  yield write('Readme.md', str)
})

就像下面这样,Co 这样的库会将异常“抛”回给他们原本的流程,这意味着你可以用 try/catch 来捕获异常,或者任其自流由最后 Co 的回调来处理这些错误。

1
2
3
4
5
6
7
8
9
co(function *(){
  try {
    var str = yield read('Readme.md')
  } catch (err) {
    // whatever
  }
  str = str.replace('Something', 'Else')
  yield write('Readme.md', str)
})

在编写 Co 的时候貌似只有它实现了健壮的错误处理,但是假如你看一下 Co 的源代码你会注意到所有的 try/catch 代码块。假如你用生成器你需要将 try/catch 添加到每个你用过的库中,来保证代码的健壮性。这就是为什么在今天看来,用 Nodejs 编写健壮性代码是一件不可能完成的任务。

生成器对于协同程序

生成器有时会被当成“半协同程序”,一个不完善,仅对调用方有效的协同程序。这让使用生成器比协同程序的目的更明确,好比 yield 能被当成“线程”。

协同程序要更加灵活一些,看起来就像是普通代码块,而不需要 yield:

1
2
3
4
var str = read('Readme.md')
str = str.replace('Something', 'Else')
write('Readme.md', str)
console.log('all done!')

有些人认为完整的协同程序是“危险的”,因为它不清楚哪个方法有没有延迟执行线程。个人来说我认为这种争论很可笑,大部分延迟执行的方法都很明显,比方说从文件或套接字中读写,http 请求,睡眠等等延迟执行不会让任何人感到惊讶。

假如有些不友善的方法,那么你就 “fork” 它们来强迫这些任务变成异步的,就像你在 Go 中做的一样。

在我看来生成器可能比协同程序更危险(当然比回调好得多)——仅仅是忘记一个 yield 表达式就可能让你费解或在它执行下面的代码时导致未知的行为结果。半协同程序和协同程序两者各自有优缺点,但是我很高兴现在至少已经有了其一。

让我们来看看你用生成器可以怎样实现新的构造方法。

用协同程序实现简单的异步流程

你已经看到一个简单读/写表达式看起来比回调更优雅,我们来看看更多的内容。

假设所有操作默认按顺序执行简化了模型,有些人声称生成器或协同程序使状态变得复杂化,这事不正确的。用回调处理状态也是一样的。全局变量依然是全局变量,局部变量依然是局部变量,而闭包依然是闭包。

我们用例子来说明这个流程,假设你需要请求一个 web 页面,解析其中的链接,然后同步请求所有的链接并输出他们的 Content-types。

这里是一个使用传统回调的例子,没有使用第三方流程控制库。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
function showTypes(fn) {
 get('http://cloudup.com', function(err, res){
   if (err) return fn(err);
   var done;
   var urls = links(res.text);
   var pending = urls.length;
   var results = new Array(pending);
   urls.forEach(function(url, i){
     get(url, function(err, res){
       if (done) return;
       if (err) return done = true, fn(err);
       results[i] = res.header['content-type'];
       pending || fn(null, results);
     });
   });
 });
}

showTypes(function(err, types){
  if (err) throw err;
  console.log(types);
});

这么简单的一个任务被回调搞得毫无可读性。再加上错误处理,重复回调的预防,存储结果和他们本身的一些回调,你会完全搞不懂这个方法是用来干嘛的。假如你需要使代码更健壮,还需要在最后的方法处加上 try/catch 代码块。

现在下面有一个由生成器实现的相同的 showTypes() 方法。你会看到结果和用回调实现的方法是一样的,在这里例子中 Co 处理了所有我们在上面需要手工处理的错误和结果集的组装。被 urls.maps(get) 方法 yield 的数组被平行执行,但是结果集然后是保持不变的顺序。

1
2
3
4
5
6
7
8
9
10
11
12
function header(field) {
  return function(res){
    return res.headers[field]
  }
}
function showTypes(fn) {
  co(function *(){
    var res = yield get('http://cloudup.com')
    var responses = yield links(res.text).map(get)
    return responses.map(header('content-type'))
  })(fn)
}

我并不是建议所有的 Npm 模块使用生成器并且强制依赖 Co,我仍然建议使用相反的方法 —— 但是在应用层面我强烈推荐它。

我希望这能说明协同程序在编写无阻塞的程序时是一个强有力的工具。

软件与配置

前段时间不间断的开发新项目,实际是想得多,写得少,最后落实到代码中,大概也就200多k文件。现在回头看一下,觉得还挺满意的,因为每个新项目会找出些不一样的地方,不求做到最好,但求标新立异,否则岂不是失去了开发的意义,也辜负了“程序猿”这个需要些许创造性的工作。

每次新项目达到一个阶段,能回顾一下,总是极好的。这次细想一下,有什么值得总结的地方,就又回到了“软件配置”这个极庸俗的话题上来了。

在我看来,任何软件都少不了配置,但是在之前的文章中我也提到过,配置是软件的大敌。任何软件配置越复杂,学习成本也就越高,这是一种反人类的趋势,所以这种软件,要么被更新,更简单的软件取代,要么就根本无人问津,消失在软件的海洋中。

当然,配置也可以被广泛的定义,形式是多种多样的,有些还是群众们喜闻乐见的,不能一棒子打死了。下面谨罗列一下我心目中的配置文件类型,和它们的适用范围。

第一阶段,单纯的key-value

这应该是最常见的一种配置,也最接近配置文件的本意。所谓人各有所好,软件在部署的过程中会遭遇不同的平台,也会遇到不同的适用情况和环境,这个时候就需要依靠配置文件来告诉软件应该怎样正确的运行。操作系统中的环境变量就是一种最常见的配置,PATH定义了用户需要的可执行文件的搜索范围,SHELL决定了和人交互的shell版本。在web应用中,数据库连接,域名,api签名秘钥等等都应当以配置的形式出现,否则就是给懒惰的开发者增加麻烦。

为什么说是“懒惰的开发者”,应为这些配置其实都可以通过在源代码中通过if-else条件来解决,要是碰到个勤快的开发(也许也是愚蠢的开发),就会把签名秘钥写在代码中,通过if-else来判断哪种环境应该调用哪种签名生成规则。但是在编程界,“懒惰是一种美德”,前面的做法非但徒增开发的难度,也不够灵活,用逼格更高的话来说,就是“不够优雅”。

所以需要用到key-value类型的配置。通常情况下,这种配置文件的出现形式会是一个json文件或是一个xml文件。假如这种配置文件不需要做到跨语言调用的话,跟进一步的做法是直接使用软件可用的脚本语言,通常会于源代码的语言保持一致。像我们写nodejs应用,使用js文件来做配置,就会比用json来的更加灵活。

第二阶段,预定义方法

下面提到的配置类型都有别于狭义的配置文件。比如说某些预先定义好的方法。我们可以在软件中预先定义好一些方法,这些方法我们不知道会不会用到,也不知道什么时候会用到,唯一明确的一点就是,我们知道这些方法能接受哪些参数,并且会得到哪些输出。我们在定义这些方法时,假如能确保他们的参数形式保持一致,那就更好了。这样对于习惯拿来主义的用户或我们自己,就更加的便利了。

具体的例子,比方说rails中的路由就是个这样的例子(从routes.rb文件的位置也可以看出它就是个配置文件),作者给我们定义好了一系列的方法,getpost,最有意思的就是resource。我们知道这些方法需要什么样的参数,能得到什么样的效果,假如我们不用这些配置,那么写上完整的路由控制代码,也能达到一样的目的。但是不需要,因为我们“很懒惰”。

第三阶段,钩子

如果你对于软件的使用者有足够的信心或信任,那么完全可以将一些接口留给用户来实现,软件中的钩子就是一个很好的例子,这在很多full-stack的框架中是很常见的,另一个场景是git的hook,在每个命令的前后,git都预留了钩子由用户来实现,这样它的可玩性就高了很多,到了github上,网站把很多常用的钩子打包成一个个模块,用户只需要给需要的模块打上勾就行了,这也可以称为配置的一种形式。

第四阶段,可编程性

这已经脱离了配置的范畴了,一些软件提供强大的api,用户通过这些api来拓展软件,甚至集成到软件本身。比如nginx使用lua来作为对单纯配置的拓展,实现了任何你所需要的功能。而github有一个很有意思的项目,叫做hubot,是一个智能机器人项目,以消息的输入输出作为基本要素,用户可以加上任意的adapter,为hubot增加应答规则。其核心非常简单,但是众人拾柴火焰高,也许日久天长,这种基于规则库的低级智能,真的能发展成影响到每个人生活方方面面的智能管家。

第五阶段,无配置文件

从智能的话题延伸出去,既然软件本身需要具有智慧,那么为什么不能领悟它自己的需求,而要由人来给它写好配置?最起码,软件要能记忆曾经执行的过的操作,记录过的配置。

以两个monitor软件为例,’supervisor’是一款老牌的进程监控软件,由python写成,’pm2’是后起之秀,由nodejs写成,但是他们都不局限于监控python或nodejs进程,而可以做到全平台任意进程的监控。

假如初次使用这两款软件,更多的人会习惯于’supervisor’的操作方式,先写好一个配置文件,也许叫做supervisor.conf,定义好有哪些程序需要运行,执行文件的路径,环境变量,等等。然后我们敲下’supervisord start’来让这些进程运行起来,一切看起都很完美。

然后我们开始使用pm2,一开始会惊奇于它没有要求任何配置文件,你找到需要执行的文件,敲下pm2 start app.js,程序就开始执行,然后我们就可以通过start|restart|reload|kill等一系列命令操作这个进程。这个过程没有任何要求编写配置文件的步骤。

这怎么可能?我一开始的反应是这样,然后开始在各个目录中翻找所谓的’默认配置’,发现一无所获,后来我阅读了pm2的源代码,发现其实所有的配置,都在第一次启动进程的时候被忠实的记录下来。事情本该如此,既然第一次我已经告诉了软件需要的所有参数和变量,为什么有那么多的软件,还需要进行人为的干预来决定需要的参数,这不是一个优秀软件应该具备的素质。

我最近在修改一个在团队内部用了一段时间的部署工具sneaky。一直以来它都工作的很好,唯一的烦恼是在发布一个新项目前需要编写一段配置文件,填上发布的目标地址,端口,必要的时候再加上一些钩子。近期的一次更新已经将原本需要的5到6个配置项缩减到最少1个。下一步,当然是干掉配置文件。我们告诉它,把软件部署到某某服务器,然后到了下次,我们需要干同样的事时,软件已经比我们先知道它要做的事。这才是软件的未来。

金钱与开源(part2)

接上篇金钱与开源(part1)

虚拟小费

有一些项目设立了“小费”机制来展现你(对某人)的赏识。我比较熟悉的两个是TipTheWebGitTip。我不确定TipTheWeb是否还有人维护。GitTip比较新一些,而且现在看起来更流行。

两者都建立在道德的基础上,TipTheWeb的Eric Ferraiuolo是个非常和善和高尚的人,他们的目标就和字面上看起来一样,为了使互联网变得更好。GitTip的Chad Whitacre看起来同样也是为互联网做一些好事。

给某人一些小费看起来就像是行善。这在你不知道什么是合适的礼物情况下,一种展现对某人爱心和赞誉的方式。能让人在精神上和物质上得到满足。

话虽如此,我仍旧怀疑这种方式能提高项目的创建量。难道程序员仅靠这些捐款就能付得起房租?我肯定是不行的。

金钱肯定是有来源的,所以我不认为完全靠这种方式能支持一个开源项目进行下去。某种程度上,GitTip上的一些人有“真实的工作”,并且决定将一部分钱用来做捐助。在GitTip上给小费,然后希望人们对你负责,这看起来有点尴尬。小费是果而非因,也就是说,“我喜欢你所以才给你小费”,而不是,“我希望你为我做点事情,所以才给你小费”。

我不反对捐助。事实上,我觉得它很重要,这是我们这些有经济自由的人的一种道德需要。然而,我做过计算,尝试找出一种能让我的捐助利益最大化的方式,每个月给某个开发者5美元并不能让我伤筋动骨。这看起来更像是一个游戏,对另一个人表示尊敬和赞扬,并附带一点点金钱奖励。

这与花大价钱雇佣开发者来创造软件不一样。但是缺少了一种交易关系,这里能得到的收益是很少的。做营销的方式林林总总,我不觉得这种方式能有很高的商业价值。为什么不去雇佣这些开发者,然后得到更高的回报呢?

给小费的方式既有趣,又让人感觉愉悦。但是我很怀疑它是否真的能改变世界。这并不能保证你过上无忧无虑的生活,而且我感觉假如你真的靠小费来生活,那么它可能会改变你(编写代码)的初衷。

这让我想到了另一种有前途但是同样存在问题的方式。

奖金

无论何时我们都得对于钱的问题万分小心。很多研究发现事物的动机有外因和内因之分。假如我为了五美元去做一些事情,我可能享受不到免费做这件事的乐趣。就像Merlin Mann说的:“世界上有两种价值:免费,和成本。”

当然,“我将花X美元来请你帮我写Y功能”在软件界是一种通行的方式。大部分情况下,就我经验而言,它并不能取得很好的效果。任何人都不可能给出一个等价的条件。

一旦延期很久,双方都不会满意。通常这个时候甲方和乙方就开始扯皮,事情就杯具了。

BountySource是这个领域的后起之秀,它有一些有趣的特征。“Backers”既可以是个人也可以是公司。利用融资的形式来支付小费的想法很有吸引力,这样你就不必为某个个体负责了。而且,集成Github Issues的想法也很聪明。

但是我仍然十分怀疑BountySource能改造开源软件现有的生态环境。一个显而易见的缺陷就是奖励实在是微乎其微。而且,现在钱被提到了前面,热情就被商业所取代了。

举个例子,我刚刚获知在这个实现SemVer 2.0规范Issue中有一笔87美元的赏金。

事实是,我已经和其他人一起着手写这样一份规范(在当时还很模糊)。一旦完成,我能遵守规范的唯一方式就是重写整个node-semver。这总共需要两周邹游的时间,包括将改动提交到npm上来让它起作用。

所以,虽然87美元看起来很诱人,但是我不能仅凭87美元来过两个礼拜。就算它有870美元,8700美元甚至87000美元,提高奖金也不是最好的办法。它尽最后的努力来使一个社区满足你的需求。假如社区根本不关心这事,那么他们也不会关心你或你的需求。

奖金机制在这里存在的问题就是,软件有时候并不是一个有着明确边界的产品。增加一个功能看上去更像收养一只小猫,而非投递一件包裹。假如你无论如何都想收养这只小猫,但是有些人想要花钱来让你收养另一只,就算能行,最后也会事与愿违。强扭的瓜不甜,最后可能导致的是一个糟糕的软件。

奖金可能在一个项目负责人希望激励成员找出bug或添加功能的时候有用。但是,项目负责人不可能给出组有的钱来请人开发(假如这样的话,还不如直接雇佣他们了)。假如一个项目负责人简单的声明,“我觉得x功能很有用,欢迎大家来实现它。”这已经起到了激励作用,奖金就完全没有必要了。最理想的情况,就像Mikeal Rogers出钱请人来找bug,这只是一种让人写代码的营销手段。

奖金只有在一个有明确目标的项目中才会起作用,就像查找安全漏洞。漏洞奖励计划发现给予奖金会比直接雇佣一个安全专家来的更行之有效。找出一些其他的有明确胜利目标的场景也是很有意思的。

然而,上面的只是一些例外,而不是常态。公司使用开源软件的时候通常并不会急着要某一个功能,或者在早期就发现一堆的bug。他们会与一些程序要保持联络来让他们的需求得以实现。这并不是明确的要求给程序加某个改动,而是在他们需要的时候,可以保证让程序加上这些特征。就像让某些人随时待命一样。

顾问合同

另一种给开源软件筹款的方式是签订一份顾问合同,用户可以向专家咨询,而专家则会仔细的对待这些问题。这可能包括登陆到某个系统或者临时帮程序员做debug,或解释一些稀奇古怪的错误消息,或检查代码来找出为什么它跑起来会这么奇怪。

Joyent付给我钱就是应为他们需要我来帮忙调试Node和npm的一些问题。

我想这应该是公司给开源软件开发者付钱的最通行的一种做法,相比于雇佣一个专业领域的开发者,这种做法更经济。

公司经常会使用很多不同的开源软件。假如签订顾问成本的开销比雇佣人来专管所有这些软件的成本要小,那么公司就可以从中获得好处了,他们可以花更少的钱,得到更好的服务。

此外,至少在理想情况下,这种激励并不让人反感。在产品中找问题是不可避免的,虽然这并不是很有趣。假如我知道我涉及其中,那么我会尽量写出强健,简单而容易调试的软件。这对每一个人都有好处,即使对于那些不为我的软件花钱的人。

当然,你任然可以发现有些不尽如人意的地方。但是“假如你给我X美元每个月,那么我会在24小时内回你邮件,并且每个月用N小时来解决你的问题。”要比“假如你现在给我X美元,我会在三个月内拿出你要的Y功能(而且不会有错)。”容易理解的多。在我平日的生活中,我仍然能感觉到在做着喜欢的工作,而且能帮助到有困难的用户。金钱是很有吸引力的一个东西,但不是至高无上的。

然而,这种方式任然存在很多问题。

我们的开源软件变得越来越模块化,而且相互依赖,“开发者”会变得很难追踪。这可能很快就会导致相互指责。假如你和某一个依赖我的代码的开发者签了合同,他们可能就会为了修改我的bug而迁怒于我,而且他们通常与我的想法不同。这种“分包”管理的方式看起来并不是很行之有效。

其次,大部分开源软件开发者并不擅长做顾问。擅长Javascript,运维或C语言不表示你就做给出最好的客户支持,或者你该做出那些改动。结果就是,开发者被大公司牵着鼻子走。软件变得越来越大而臃肿。这并不是一件很可怕的事,反正有大公司为它买单。但是它却忽略了中小型公司做需要的效率问题。

我们的软件变得越来越模块化和互相依赖,而且大部分开发者并不擅长推销他们的服务,那么第三个问题产生了。服务提供者必须很清楚明白自己能提供那些服务。比方说,你能对Node提供支持,但是你肯定不能保证对npm中的所有模块提供支持。

在理想世界中,这些都是可以解决的问题。这里有一大堆的问题,而且有无数的社会和技术问题等着人来解决。一个用户怎么可能找到合适的人来解决这些问题?又如何为这些问题公平的买单?你怎么才能避免开发者们在合作问题上起争端呢?

分出合理的技术水平,合理的分配收入,给正确的开发者分配任务,这是一个综合性的复杂问题。假设这不是很难而且现在已经有人能解决这个问题,是不现实的。

未来

我希望开源软件在某一天能被看成是一个“吃香的”职业,尤其是当你并没有在公司里获得一个“真正的”职位时。假如更多的人能享受自由的生活方式,而不用为他们的财政问题担心,这就更好了。这也可能应发更多的有趣的争论,像是为一个项目兼职,或是为开源软件的工作做出一些改变。

在技术行业中,人们始终能找到一起合作或创业的机会,或者给公司打工。我有很多很好的工作经历,通常是在不完全封闭的公司。然而,我并不认为这是让我们作为社会的一员而做出最大贡献的最佳方法。

那些自由软件开发者所得比不上其所付出,这是很可悲的。而更可悲的是某些人对这些做出巨大奉献的开发者的苛求。他们做出了巨大的贡献,而大部分却入不敷出。

大部分人都能做这类工作,而且可能会更有效率。但是,为了满足经济需要,他们最后还是找了份工作,这看起来是一种低效的做法。假如开源软件开发者能获得足够的动力和激励,谁能想象我们的发展会有多迅速?

附录:没有提及的话题

  1. 为什么我做开源软件的时候更有创造力也更快乐?

  2. 为什么开源软件对技术行业有帮助?

  3. 对开放才算开源?“开放源代码” 对比 “开放式开发”

我不能对这些问题做出解答,应为这篇文章已经够长的了。我的目的不是在这里卖开源软件。请在今后的文章中关注这些话题。

参考

Money and Open Source

金钱与开源(part1)

注:本文作者是npm的作者Isaac Z. Schlueter,也是nodejs的主要作者之一

“我们需要找到更好的方法来为开源软件筹资”,这是我近几年反复思考的一个问题,下面我要说的或许是一种解决方案。

大部分开发者在传统的合作方式下都干得不错。激励方式也很简单:努力工作,改善产品,帮助团队完成产品,然后取得共赢。当一切正常时,这种方式很好。你会发现自己很有归属感,而且在不断的自我提高。

但这并不适用于所有人。出于愚蠢的安全性考虑,你可能需要牺牲一些灵活性和创造力。至少,它会限制你的软件的适用范围,因此它能提供的价值也仅止于此。

自从我开始全身心投入编写开源软件,我感觉非常愉快,而且更有创造力了。事实上,我不会接受一份要求我放弃编写开源软件的工作,我也很有幸能有足够的资本来避免做出这种荒唐的决定。当然,这也可能导致很坏的结果,但是我很幸运的用这些时间来写了npm,然后JoyentNode.js开始迅速发展起来,现在我在干的正是这些。

艺术家和浪客

可悲的是,很多有望成为开源软件界超级明星的人并没有我这么幸运。没有钱是万万不能的,而最实际的赚钱方式就是找一个工作。

很多雇主希望“让”雇员用“私人的”时间来处理自己的项目,或者至少能贡献给公司的项目(通着这些项目会带有一份公司的保密条款)。这并不是很明智,“自由(free)”时间并不“免费(free)”,将精力全花在工作上会让你失去应有的生活。

有些人则放弃了在公司工作的机会,成为了一个自由职业者,换句话说,一个挨着饿的艺术家。他们用最少的时间来接一些活,然后将剩余的时间和创造力花在开发开源软件上。但这是一种很窘迫的生活方式,特别是需要供孩子上学的时候,甚至连抚养孩子都有困难。

这就是我们和社会面临的困境。开源软件给软件工业带来了巨大的好处,也就意味着,给所有工业领域提供了巨大的帮助。假如专注于开源软件的都是一些幸运和热情的人,那么这里面就存在很多未经发掘的潜力股。

假如我们想继续从开源软件中得到好处,特别是想让这种好处最大化的话,我们就得找出一种为它买单的方式。除了能让开源软件开发者吃饱喝足以外,付款也能将他们的努力与现实世界联系在一起。

下面我会提到一些这个领域的开发现状。每一个都一些致命的缺点,而且我还能找到解决这些问题的办法。我不认为这会让我们觉得悲观,这些需要解决的问题反而让我们觉得正朝着正确的方向前进。

合同,训练,咨询……

许多开发者通过签订短期合同来为喜欢的项目工作。虽然这有时是一个不错的赚钱养家的方式。但是我并不认为它从根源上解决了开源软件筹资的问题。

这与成为一个传统雇员,然后用空余时间来处理开源项目没什么不同。这并不能让开发者直接通过他们的开源项目来盈利。就像做培训和别的一些活一样,这并没有真正的为开源软件筹资,这只不过是你通过开源软件找到了一份工作而已。

话虽如此,合同当然可以资助一个人其他的开源活动,同样提供临时援助也能帮助创业者步入正轨。

专职员工

一种为开源软件筹资的方式是让雇员在工作时间为开源项目做贡献。这正是Node核心项目的运作方式。Joyent,StrongLoop, Voxer, Mozilla, LearnBoost, 和Microsoft的雇员都会将他们的部分工作时间花在Node上面。

(注:我没有在这里囊括那些用私人时间开发项目的人。这当然也很重要,但是“动用你的私人时间来做项目”正是这里遇到的问题。)

这样的效果相当好,事实上带来的好处是,能让软件更符合他们大部分用户的需求。当公司付给你薪水的时候,你就会觉得有必要为自己的代码负责。假如一个团队完全不考虑用户需求的开发软件,这会显得相当的不靠谱。

任何能给开源软件生态系统带来益处的方法都值得鼓励。 但是这种方式也存在一些问题。

当一个社区项目由现实中的企业驱动时,往往企业会利用它的优势地位,来做出一些符合自己利益的改变。从长远来看,这会损害项目的可靠性和预期目标。Joyent的高级副总裁Bryan Cantrill对这些事情可能导致的严重后果有一个很精彩的演讲:企业反开源模式:大错特错

就算企业能考虑尽量避免上面的情况发生(这样做得很少),表面上(对企业)的优待条件也会给社区带来损害。开源社区的很多人认为企业的利益本质上就是邪恶的。这样说并不客观,但是考虑到这些企业的反开源模式,这样说也并不是毫无道理。

此外,这种解决方案的可能性微乎其微,作为企业雇员,开源项目完全符合企业利益的情况是微乎其微的。当然,大多数使用Node的公司可能不能让Nodejs核心开发者雇员做出一个像样的商业应用,嗯~,可能是运气的问题吧。

实在太长了,未完待续… :)

参考

Money and Open Source

软件极简主义

今天回家的路上,竟然刮起了大风,虽然骑行艰难,但是想想公交中的闷热,倒是觉得凉爽多了。

在路上的时间是无聊的,于是就喜欢胡思乱想,很多自以为很棒的点子其实都是在这种不经意间想到的,办公室里的久坐反而显得效率低下了。回味一下最近做的几个项目,高屋建瓴的想想当初的设计,突然很想写一些关于软件设计的文章。就着饮料和巧克力(来点酒么?),今天就来写写软件极简主义吧。

Google了一圈,也没找到对“软件极简主义”的定义,姑且当做是我的独创吧。一般认为“极简主义”是设计界的一种风潮,但是软件发展至今,好像也渐渐有了这样的趋势,甚至我认为这是未来的必然,我们经常听人说“flexible”这个词,字面上来看就是“灵活的”,但是具体到这个软件是否灵活,就不太好判断了。但是,简单的软件,一定是灵活的。

极简主义的的大敌

软件极简主义的三个大敌:配置文件,冗余的参数,和大量复杂的接口。

很多人热爱配置,迷恋配置,认为越多的配置项意味着软件越强大,适用范围越广,但这是九十年代的事了。实际我们仔细翻翻常用的软件,90%的配置都是多余,没有人明白他是做什么的,也没有人希望去改变他。比方很多软件的configure文件,常常能列出上百个配置项,但是我们真的需要这么多吗?不,我们需要默认的那些值就行了。何谓默认?因为软件的设计者觉得这些是最优化也最有可能被选择的配置,那么既然是最优配置,我们又有什么理由去改变他们?

再说说冗余的参数,linux中有一个非常强大的命令’tar’,从man文件看来他起码有二十来个参数,但是我真的需要这么多参数吗?其实我只要记住压缩是-c,解压是-x就可以了,那么何必为了1%的功能而去加上这99%的参数呢。

最后是复杂的接口,举个栗子,全文搜索引擎solr非常强大,能满足我们对于文档索引的各种需求。但是他使用起来可不简单,原因我想就是因为他那种sql式的查询接口,把一件很单纯的事情搞复杂了。我们来设想一下,需要找出包含某几个关键词的文章,必要的条件是什么?关键词,文档,没了。而文档是存储在服务器的,为什么我们提供了关键词之后,仍需加上各种条件,他才能告诉我们想要的答案呢?我想软件发展到一定的智能,他就应该像一部能说话的百科全书,提问,然后告诉我们答案即可。

凡事都要对比着看,所以我们找点软件来对比一下。

redis 与 sql

redis很灵巧,所有源代码加起来不满5M,但是他很强大,hash结构能取代我们80%对于sql的需求。他也有配置文件,但是选项很少,而且每一项都有详尽的注释,并且使用默认配置就可以应对大部分的情况。唯一值得诟病的就是他的接口种类繁多,但好在这些接口很有规律可循,你只需了解了redis的基础数据结构,那么跟着官网的文档就很容易搞懂所有接口的用途,而且大部分的接口都只接受3个以内的参数,这可好记多了。我刚接触redis的时候,只花了半个小时就能玩得起来,我想面对sql恐怕没人能这么轻松的掌握吧。

cake 与 grunt

cakegrunt是nodejs中两个管理任务的模块,后者的名声更大一些,前者甚至不能说是一个模块,他只是coffeescript中附带的一个小工具。我曾尝试使用grunt来做任务管理,但是当我看到grunt官网那长长的一段initConfig时,就望而却步了。就像是我希望在墙里敲个钉子,你却给了我一台破城锤。我只不过想要给每个任务起个名字方便我以后调用和查阅而已,所以cake的一行命令足矣。

zmq 与 rabbitmq

zmq是我见过的最具有极简主义风格的软件(组件)。一方面他要面对的任务非常繁杂,在异步通信中所有我们可能遇到的情况,他都为我们考虑到了,但是他又将底层的复杂问题掩盖起来,让我们看到一个光滑的表面,深藏功与名。同样来看看他的同行rabbitmq,关键词:中心服务,多线程,模式单一,最后一个特点,慢!而仅有1.7M的zmq,快是最直观的感觉,而分布式和扩展性则是锦上添花。有人说zmq就像乐高积木,每个人都能搭出他想要的形状,这话一点都不错。

不是结束的结语

软件的设计日新月异,将来肯定会接触到更多优秀的软件,也许哪天我想法变了,也许哪天遇到了更神奇的方案,可能我会补充在这里。

介绍 Coffeescript 中的列表推导式

列表推导式是一个很著名的语法结构,它的特点是能让代码更简短,优雅,而且易于阅读。捎带些函数式编程特点的语言都支持这种语法结构,例如lisp家族和python。coffeescript作为一门年轻的语言,自然而然的继承了这个特点。

我们先看看这种语法和普通循环的区别:

1
2
3
4
5
6
arr = [1, 2, 3]

for i, v of arr  # use for..of loop
    arr1[i] = v * 2

arr2 = (v * 2 for i, v of arr)  # use list comprehension

可以看到本来需要两行的代码变成了一行,这对于略有装逼犯情结的码农来说,心理上的满足感自然是无与伦比的。优点也是显而易见的,就是可读。在有些语言中,这种语法还会产生一个新的作用域,不会污染外界的变量,比方说ruby。

我们再来看看一些进阶用法,下面是带上if条件的列表推导式:

1
2
arr = [1, 2, 3]
arr1 = (v * 2 for i, v of arr) if arr?

一般的列表推导式返回的结果是一个一维数组,这在我们需要对某个object中的值做转换时会产生不便(key会丢失),这个时候我们可以采用一种变通的方法:

1
2
obj = {a: 'a', b: 'b'}
obj1[k] = v + v for k, v of obj1 if obj1?

没加两边的括号和加了括号是有区别的,像上面这种结构,可以理解为将for..of结构中的第二行搬到了等号左边,其中的临时变量k, v当然也是可以直接使用的,而且后面if条件是对整个循环生效的,而不是单独加在每个循环中的,比较好理解吧。

熟练掌握了列表推导式之后,编写代码的时候会更加得心应手,对于代码重构,想必也是极好的。

相关文档

一个例子验证 Do 在 Coffeescript 中干了什么

使用jslint的时候有可能会见到这样的提示

Don’t make functions within a loop

一直没有太在意这个警告,直到最近做项目的时候还真的碰到了因为这个问题产生的bug。

那么下面就用一个例子来看看在循环中定义方法会产生什么样的后果吧。

1
2
3
array = [1, 2, 3]
for num in array
  setTimeout (-> console.log num), 1

得到的结果是’3,3,3’,而不是预期的’1,2,3’,先不说为什么,我们来看看coffeescript给出的解决方案。

1
2
3
4
array = [1, 2, 3]
for num in array
    do (num) ->
        setTimeout (-> console.log num), 1

在这里不得不佩服Jeremy Ashkenas的无限创造力,短短一个do,就解决了这么让人纠结的问题。下面来看看编译成javascript之后的结果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
(function() {
  var array, num, _fn, _i, _len;

  array = [1, 2, 3];

  _fn = function(num) {
    return setTimeout((function() {
      return console.log(num);
    }), 1);
  };
  for (_i = 0, _len = array.length; _i < _len; _i++) {
    num = array[_i];
    _fn(num);
  }

}).call(this);

下面我们来解释一下为什么上面的代码会有问题,以及这个do为我们做了些啥。

关于javascript的作用域,我们可以看一下这篇文章的引用

JavaScript’s scopes are function-level, not block-level, and creating a closure just means that the enclosing scope gets added to the lexical environment of the enclosed function.

大意是说

JavaScript的作用域是方法级别,而非块级的。创造一个闭包可以将作用域限定在这个封闭的方法中

这里的for..in循环在其他语言中就是一个块级的作用域,但是Javascript并不买它的帐,于是最后在方法中调用的num就变成了整个作用域中最后的状态(3)。解决的办法就是在循环中创建闭包,让num当成参数传入闭包,那么它在方法作用域中就不会受外部的变化而改变(实际上完全可以当成一个新的变量,不信你传个object进去,在闭包中的任何修改,都不会对外部作用域的object产生影响的)。

coffeescript用do关键字为我们将这种操作最简化,所以,尝试一下吧。

参考文档

关于公司架构的一些吐槽

写了这么多文章,技术屌丝味太浓了,以前每次想写点随想也是起了个标题就没下文了,正好今天早上看到了一篇喷技术创业的文章,文中观点不敢苟同,趁着早晨清醒的时刻,咱也文艺范一次,写点有感而发的文字。

很多公司,无论大小,都想将部门划分的细之又细。所谓麻雀虽小,五脏俱全。随意拉一张公司的组织结构图出来看看 – 总裁办,行政部,人力资源部,技术部,产品部,市场部,客服部,运营部。。。别人有的我们就得有,别人没有的我们也得有,不论有些部门是不是必须,只要一两个人也能成立个部门。不明真相的人跑来一看,瞧,多正规,高端洋气上档次。

且不论其他职能部门,我就来说说跟研发关系最大的一些部门,以及如何显得他们的工作是不可或缺的。

产品部

产品部本身就是一个比较扯的部门,因为这个词打击面太大,整天挖空心思想点子的,想的是不是产品?没日没夜扣腚的,做的是不是产品?上线后胆战心惊监测的,维护的是不是产品?我们尊崇’less is more’,谁也说不清产品到底是个啥玩意,但是就有这样一个部门,叫做“产品部”。

再回到这篇文章的观点,技术人员过于注重技术,而忽略了对产品的思考,所以需要专门设置这样一个产品经理的职位来构思整个产品的走向。看似有理,但是他的前提是“技术人员不会思考产品”,这就是一个弥天大谎,我见过的大部分技术人员,对于项目的细节,业务逻辑的理解都比普通产品高出不知道多少个档次,我们不能纸上谈兵,只有真正理解了产品实现的业务逻辑,才能提出更有建设性和创新性的意见,这叫站在巨人的肩膀上。但是我看到的很多产品是,进入公司一个礼拜都不到,以前从来没有用过公司的产品,就能洋洋洒洒写出一大篇设计文档来,而问到为什么要这样改,则又支支吾吾,说不出个所以然,最后来一句我看到某某网站也是这样做的,所以我们也要这样做。

回到技术人员的自我修养上来,我认为每个研发应该视自己开发的产品如孩子一般,在关注技术进步之余,能花时间来培养这个孩子,让其更健壮,更优雅,更招人待见。同时,也要多看看外面的世界,试用别人的产品,包括竞争对手的,以和自己创造的孩子进行对比。技术人员提出的产品改进意见往往更务实,更切中要害。

将这种视如己出的概念再推广到所有员工身上,其实人人都可以为产品添砖加瓦出谋划策,那么,产品部门存在的价值何在?

测试部

测试可以分为好多类:1.做黑盒的。2.做白盒的。3.自动化测试。 我们一一道来。

先说第一种,做黑盒的。很多公司曲解了黑盒的意思,认为做黑盒就是一个功能开发好了,你拿去用,不出问题就行了。这样就把软件开发变成了一个劳动密集型行业,这样的测试与拿到内测账号的用户有什么区别。更何况我们有些测试人员的使用经验可能还不如用户。这样的测试,效率既低下,效果还不明显。

再说第二种,做白盒的。一些公司有白盒测试,其实就是看看代码。很多公司认为,这个人写代码不行,就让他做测试吧。这是一个大大的误区,对测试人员的要求应该比研发更高,因为我认为读代码往往比写代码更难。上面这种做法的后果就是,一些人做白盒测试的时候,一旦看到不明白的地方,就跑来问研发,需要研发手把手的一条条教来,这不光是浪费双方的时间,也是在做无用功。我相信任意一个合格的研发人员,在提测之前应该都对代码做完整细致的自测。

最后说说第三种,做自动化测试的。这个其实要求较高,很多公司没有,即使有也是认为装个hudson写写配置文件就算自动化测试了。而我认为的自动化测试应该有很强的编码能力,能写出简单有效的单元测试用例,能配置不同的运行环境来确保软件的跨平台性,能进行性能测试,来保证软件的工作效率。这都对测试人员提出了较高的要求,这种人少之又少,而我见到的大多数测试人员连apache的vhost文件都不会写。

真正的测试人员应该得到相当的尊敬,因为他们需要对业务和代码都有很深的理解,他们比程序员更细心,既能防止程序员犯一些低级的错误,又能在一些容易忽略的问题是上保持警惕。

假如找不到这样合适的测试人员,测试部就没有存在的意义。

UED部

UED这个词是个舶来品,你甚至很难找到合适的中文替代词,只能用“用户体验”这种虚无缥缈的词来囊括。很多公司的UED,其实就是美工。

我自认为对设计和绘画不在行,所以我很尊重设计师的工作。设计师负责原型和效果设计,程序员负责实现,这是由人的左右半脑分工决定的,而且一个好的设计师,简而美的设计,应该是先在公司内部群体中产生认同感,才能让更多的用户认可。

下面是我的吐槽,一些我见过的设计师,可能读过一本Don’t Make Me Think,就能自诩得到了设计的精髓,接着就对页面开始做大刀阔斧的改革,也不需要其他人的意见,因为设计师都有一些自负天才的心理在作怪(嗯,其实程序员也有)。更有甚者,是一天一小改,三天一大改,也没有统一的风格,去别的网站东边抄一块,西边抄一块,就变成了咱家的东西。别人做瀑布流,我们也搞瀑布流,别人做下拉刷新,我们也用下拉刷新,可是从来没有独创的功能被人认可,这也是“一直在模仿,从未被超越”的典型了。

再说到“用户体验”这个词上,世界上恐怕再也找不到这样一个百搭的词了。一个按钮加大点可以叫用户体验,换个字体也叫用户体验,但是众口难调,人的大脑是很奇怪的,你喜欢的未必是人家喜欢的。所以真正需要做到的是在公司这个小范围内赢得众人的认同,然后将风格延续下去,这样才能让更多的用户接受乃至迷恋这种风格。有个很成功的例子就是苹果。

这里又要说到关于设计师和程序员两类人的区别了。我认为一个好的设计师和一个好的程序员应该是可以互补并相互学习的。我以前的一个研发经理,技术上肯定是毋庸置疑的,但是也做得一手好画,从鼠绘到原型到效果图,无所不能。这样的人才非常难得,但并不是没有,一个诸葛亮是远远高于三个臭皮匠的。而更多的人可以在学习中达到这个高度。

理想中的组织架构

任何组织发展壮大之后,人员就会变得复杂,管理难度相应也会增大。职场如战场,公司就是一个缩小的社会,我们不妨就从历史中找个例子出来。清廷倒台之前,曾有一番关于“共和”还是“立宪”的争论,两派人争得不可开交,最后的结果我们知道,共和派取得了胜利。

“共和”和“立宪”的根本区别还是权力集中在何处。相比帝制的独裁,“立宪”在名义上是说君主也要遵纪守法,权力还是集中于小部分人(真正的“立宪”君主只是个象征,内阁还是要选举的)。而“共和”则将权力下放于大众,政府则是大众意志的集中。

开源软件的圣经《大教堂与市集》其实也表达了这样一种思想。软件开发由自上而下的瀑布流发展到今天的开源模式,最有代表性的就是github flow。就是任何人都有权利对产品提出改进意见,并且可以亲自来实现这些功能,而项目的管理者(owner)在更新自己的产品之余,还需要接受来自四面八方的(pull request)。owner有权力决定这些功能的加入,也有义务鉴定这个功能的风险。

同样对公司的管理也是这样,权力不应该集中于个人,每个员工都应该有发言权。每个员工都应该有自由发挥的空间,来实现自己需要的功能。同时也不能忽略了合作的重要性,所以在日常的工作中,需要三两人一组,作为一个cell,可以是同一个部门中志同道合的人,也可以是不同部门中可以互补的人(比如设计师和程序员)。以cell为最小单位,来完成每个任务。最基本的目标:追求效率,追求自我提高,追求快乐工作。

这对个人也是有要求的,就是每个人都需要能独当一面。我想谁都不会愿意与一个一无所知和整日拖沓的同事合作吧(MM除外)。同时,管理层(owner)的责任就是协调cell之间的工作,有权力决定cell提出的功能的去留,也有义务听取大家的意见。

这也是我觉得创业公司比大公司好的一个原因,就是你有决定权,或者能将意见直接反馈到管理层,而不需要经过大公司死板结构的层层汇报。同样,这样的办事效率也是很多公司望尘莫及的。赠人玫瑰手有余香,以开放的心态接受他人,那么他人也会以同样的姿态来回报你。

最后贴一个豆瓣上的小段子,娱乐一下。不同部门员工吃饭时聊些什么