思考 | Tony Bai

八月 15, 2008

CHECKLIST多是类似如下的东西，举一个代码CHECKLIST的例子：

- 参数的书写是否完整？不要贪图省事只写参数的类型而省略参数名字。
- 参数命名、顺序是否合理？
- 参数的个数是否太多？
- 是否使用类型和数目不确定的参数？
- 是否省略了函数返回值的类型？
- 函数名字与返回值类型在语义上是否冲突？

我们常常遇到的一个问题就是在进行source peer review的时候是根据每一个CHECK item去从头到尾看一遍代码(如果有50个CHECK items的话，那就从头到尾看50遍代码)还是记住所有CHECK items，然后只看一遍代码，显然我觉得后者在目前实施的可能性是最大的，也是实施最普遍的。

但是效果呢？估计还是看50遍代码较好，但是的确不太具备可操作性，投入的工作量太大，很多人也不会接受。

也有很多人采用折中的方式，比如说一共有10个人参与source peer review，每个人只关注其中的5项check item，然后一起walk through一遍代码。甚至在有些公司采取强制每个人必须能针对自己负责的check item提出问题，否则影响个人绩效之类的方法。

以上是看到公司的一个文档的CHECKLIST时突然想到的，没想出更好的solution。我想可能更多的人是不去记忆Checklist的，而是直接凭经验对代码评头论足的:)

从座位调换看文化差异

最近我们开发部正在讨论搬家事宜，搬家后的一个重点就是要调换和安排座位，恰好上周在Google黑板报上也看到了一篇题目为“Google如何调换座位”的文章，本来很平常的一件事，但在不同的公司里却恰恰能体现出来不同的公司文化。

换座位想必大家都经历过，从小学到高中，座位一般都是老师安排好的，或是按照大小个排队，走进教室，轮到哪个座位，哪个座位就是你的，我想大多数中国的中小学调座位的方法都大同小异。工作后，调座的策略一般都是以项目组为单位，大家坐在一起便于沟通交流。但是如果你看了Google黑板报上那篇文章中的座位调换方法后，想必你一定会感觉很是惊奇，因为大多数人从不曾想过还可以这样换座位，这里暂不论Google采用的方式是否是最好的一个，但就其方式本身，却能反映出Google公司与众不同的企业文化。

在通常的公司里，一般来说换座位都是自顶向下的：即领导指定秘书做座位安排，秘书按照项目组划分区域，然后让项目经理细化座位。而在Google，这种方式是自下而上的，Google把鼓励员工创新始终是放在第一位的，公司内将创新习以惯之，且不限于软件研发领域，几乎任何事情普通员工都可以参与，员工地位平等，从那篇文章中也可以看出领导在分座位的时候也是没有特权的。在这种氛围下，员工的能动性得以充分发挥。

国内公司多数采用的还是自顶向下的驱动文化，在这种文化熏陶下，久而久之，员工们的创新意识将被打磨殆尽，说句不好听的，都变成了IT力工、瓦工了。