透明思考 - Thoughts

个体与交互重于过程和工具

2010-07-26T05:22:00Z

曾经我认为，敏捷的各种实践，只要有了标准化的动作，加上一点点定制，加上PDCA/SDCA，就能做好。迈向敏捷之路，是可以唯一定义并且重复实施的。比如说持续集成，大师说 “在自己的计算机上启动一个自动化build”是重要的──我们把它叫做“本地构建”。做不好本地构建，提交构建失败率就会高，对持续集成的信心就会失去。这个问题，和它的解决方案，都是确定且可重复的。

可是这个团队让我吃惊了。他们一直没有真正意义上的本地构建。但他们真的相信持续集成──不仅仅是几个领导，是整个团队，真的相信：如果每天发现的小问题不能及时解决，那么到版本上线时一定会被客户骂得狗血淋头。他们不想被骂，他们也不想同一个战壕里的战友被骂，所以他们就把持续集成做好了。尽管没有真正意义上的本地构建，就靠着原始简单的代码评审，更认真的态度，他们就真的把持续集成做好了。

这个团队颠覆了一些正在我脑中渐渐成型的东西，让我想起了一些原本印象深刻但被渐渐遮掩起来的东西，比如敏捷宣言的第一条：个体与交互重于过程和工具。

面对巨大组织时强烈的无力感、无助感会让“敏捷推行人”们（包括我自己在内）不自觉地选择把自己的定位拔高──也许真是想帮助更多的人，也许只是想从残酷的现实中逃开，抑或两者兼而有之。但这些人不会做高层面的事情。于是离开低层面、离开具体事务的结果就是不知道该做什么，就是把敏捷推行简化为过程和工具的推行。

有一个敏捷推行人对我说，我负责几十个项目的改进，如果每次只到一个项目去做具体的事，对整体的帮助很小。我对她说，也许你救不了所有的鱼，但被你救的这一条鱼，它会在乎，它会得救。在反复思考如何拯救所有鱼的过程中，其实你什么也没有做，没有一条鱼真的得救。

敏捷的改变，最终是一个一个人的改变。过程和工具会帮助你。但如果把敏捷简化成过程和工具，你就在一步步远离敏捷，因为你已经违背了敏捷宣言的第一条原则。

不做小叮当

2010-07-14T13:14:00Z

ZD亲热地搂着我的肩膀说：“还是你有本事啊，这次才看到你的能力有多强。”我苦笑着说：“我的英名早晚要毁在你手上。”

他是我的客户，也是老乡，而且常常配合很默契。

第一次，二百多人的团队分散在两个城市五个办公地点。ZD对我说，那个产品，发货量巨大，是整个公司最赚钱的部门，客户遍布全球，要是把它搞定了，意义重大。（当时ZB在旁边热情澎湃，被我俩联手泼了一盆冷水。那是我第一次发现，和ZD配合有不需准备的默契。）我沉吟良久，说它真的风险太大，我真的不敢做。但最后我还是去了，因为一个不能让ZD知道的理由。

第二次，一支孤零零的团队正在被一个巨兽客户折磨得要死要活。ZD对我说，这次能让客户感受到我们的变化，要是把它搞定了，意义重大。我又沉吟良久，说它真的真的风险太大，我真的真的不敢做。但最后我还是去了，又是因为一个不能让ZD知道的理由。

我跟他说，其实只是运气好。他笑笑，不信，或者说是装着不信。

小熊说，每个问题解决者都有多拉A梦情结，而康夫每次痛扁技安之后灿烂的笑容便是对小叮当最好的褒奖，是他继续从口袋里掏出法宝的源动力。我不得不承认，挑战一下自己并且挑战成功（不论这成功的原因是什么）的感觉是很爽的。我想ZD一定也知道我的爽感，所以他笑而不语。

所以，尽管真的很想亲眼看到这个大雪球轰然滚下的最后一刻，尽管真的很嫉妒小熊的博客比我写得更有料并且更有文采，还是应该抽身了。让自己沉浸在小叮当帮助康夫破涕为笑的愉悦之中，这不是我想要的。

何况，ZD你懂的，我不能等到英名真的毁在你手上的那一天。

出新意于法度之中

2010-07-12T13:11:00Z

周末去看了邱志杰的展览。对他的舞蹈课很是喜欢。

创新不得和以前重复，这是艺术界的游戏规则；创新会越来越难，这是艺术史的规律；在早期，更多的事不用多加思索的本能选择，游戏越往后，组合、颠覆等可以开发创意就越来越经常被依赖；而是否被认可为创新，这是由之前已经出现过的现象以及众人的裁定所决定的。
在很大程度上，艺术家并不像传说中的那样自由，相反，自由和个性要通过艰难的开发才最终会获得。因此，你必须去研究整个系统，你必须形成一种能够开发创造力的工作机制。

缺乏创意或是坐井观天，如果一定要选的话，究竟哪一个更糟？和Miya说，想一想，如果有一天我也变成这样，以为自己看见的一个小圈就是整个天空，挺可怕的。何况，井里的创意，又能有什么好玩的。

Cygwin的包管理器

2010-07-08T08:08:00Z

apt-cyg : install tool for cygwin similar to debian apt-get

需要先安装wget、bzip2、tar和gawk。

现在就可以体面地找软件和装软件了。

apt-cyg find gcc
apt-cyg install gcc

对象训练营：简介

2010-07-01T02:33:00Z

对象训练营是 ThoughtWorks 历史悠久的入门培训课程，而其中谈到的对象原则和实践历史就更悠久。面向对象的思想明显地分为两个阵营：

Rational。强调建模，推崇UML和形式化方法。这些人最初使用ADA为军方开发软件，系统本身并不复杂。软件正确性非常重要，因此重视对设计的评审。
Tektronics，一家电子设备测试工具制造商。强调示波器的可插拔性。使用新的编程语言Smalltalk，因为它的灵活性。这支团队中涌现了Ward Cunningham、Kent Beck、Sam Adams等敏捷世界的大师。使用Smalltalk，他们在设计和编码之间快速切换，这也是现在Agile的基本工作方式。

80年代中期Tektronics团队解散，Sam Adams加入KSC咨询公司，当时在IBM负责与KSC接口的Fred George从他那里学到了Tektronics的对象思想。后来Fred George加入ThoughtWorks，并开创了对象训练营。因此本课程是基于Tektronics的对象思想，而不是Rational的。

本课程采用苏格拉底式教学法，简单说就是学员自己教自己。我们会用问题来引导你，但不会手把手地教你正确答案。你会受阻，但这是好事。正如Fred Brooks所说：“好的判断来自经验，而经验来自糟糕的判断。”记住受阻的时刻，并从中学习，这些经验会成为未来良好判断的基础。

本课程至少3/4的时间会用来给学员自己动手练习编程。如果你喜欢编程，这些练习会很有趣。我们会针对练习中写出的代码展开讨论，所以每次讨论都会把某个pair的代码用投影展示出来供大家讨论。一开始也许你不好意思展示自己的代码，但是请大胆展示。被批评是最好的学习机会。

课程内容分为两大部分：（一）对象原则与敏捷实践，（二）设计模式。

持续集成铁的纪律是怎样炼成的

2010-06-29T07:03:00Z

持续集成问题说到底是人的问题

有一种常见的观点认为：持续集成是一系列技术问题；只要安装配置了适当的持续集成工具，解决了某些构建、测试自动化的技术问题，持续集成建设就能顺利开展。但实际上，持续集成建设中很少出现高难度的、超出团队本身能力范围的技术问题，涉及的工具也大多通用。持续集成建设中遭遇的一些典型难题，归根结底都不是技术问题，而是人的问题：

构建失败率高：背后的原因是开发人员质量意识不足，习惯把质量保证的责任全部丢给测试人员
构建修复难：背后的原因是开发人员在本地开发机无法重复构建过程，难以定位问题
在失败构建上继续提交代码：背后的原因是构建结果不够公开、受重视不足

持续集成建设就是提升团队质量能力的过程

建设一个运转良好的持续集成体系的过程，就是在培养每个团队成员重视质量的意识，就是在帮助团队发现交付“最后一英里”潜藏的问题、并督促团队解决这些问题。为了保持项目的健康，需要整个团队的努力：

加强对质量的关注，代码经过必要的自检再提交
制定简明严格的提交纪律，构建失败及时修复
用构建监视器显示持续集成状态，使项目健康情况公开可视
为开发人员提供本地构建能力，以方便自检和问题定位

《持续集成建设》引言

2010-06-24T05:37:00Z

软件开发的最后一英里

在任何软件开发过程中都有一个重要的部分：通过某种构建（build）流程，将已经编写好的源代码变成可用、能为客户创造价值的软件。尽管知道构建的重要性，但是我们仍然会经常因为构建中的各种问题而惊讶不已。曾有多少次，在所有人都认为“开发已经完成”之后，我们还要经历漫长而痛苦的编译、打包、联调、测试、上线过程？在代码都已经写好之后，我们还曾付出了多少个通宵的代价让软件真正可用？

编写源代码不是软件开发的全部。从源代码构建出可用的软件，这个过程也被称为“软件开发的最后一英里”：胜利似乎就在眼前，但各种潜藏的危机可能这段短短的路程变得艰难万分。

持续集成就是构建过程

构建之所以如此困难，是因为在绝大多数软件组织中，构建过程有以下几个特点：

它是一个神秘的、不可见的、只（模糊地）存在于少数人大脑中的过程
它是一个需要人工操作的、耗时费力的、容易出错的过程
它是一个偶尔为之的、缺乏练习的、充满未知风险的过程

为了减少“最后一英里”的浪费，让艰险的最后一英里成为坦途，我们需要将构建过程明晰化、自动化、频繁化。持续集成就是一个将构建过程明晰化、自动化、频繁化的实践。通过使用软件工具来实现自动化的构建过程、展示构建结果，原本虚无的构建过程就成为了一个实际存在的、可以重复进行的、可以被有效管理的实体。从这个意义上来说，持续集成就是构建过程本身：只有以持续集成的形式呈现的那部分构建过程，才是确定并可靠的；“最后一英里”中尚未被纳入持续集成的部分，仍然是不确定和有风险的。

团队空间

2010-06-18T06:10:00Z

Martin Fowler说，一个好的团队空间，要有大面的墙作为信息辐射器，团队要围着大桌坐以保持眼神接触，要有自然光线和看到外面景色的落地大窗。

ThoughtWorks北京的办公室，Martin Fowler认为是一个好的团队空间。

这个空间又如何？除了缺少自然光，也是个不错的团队空间。

谁需要分布式事务？

2010-06-16T13:25:00Z

有个项目，用 Tuscany 实现了 SCA 。然后呢，服务与服务之间会互相调用。然后呢，因为你不知道被调用的下一个服务被部署在什么地方，所以就需要分布式事务。一切多么的合理。

Bullshit.

Martin Fowler说，分布式对象设计第一原则：不要分布你的对象。如何利用多个进程？集群，而非分布。

因为很显然，如果应用程序本身是无状态的，分布式对象基本上无法带来任何集群不能提供的好处：性能，吞吐量，都不可能在涉及跨进程调用的情况下超过进程内调用。唯一可能的好处是，能够把应用程序分成小块，分别部署在不同的机器上。

是的，这就是这个项目需要分布式对象（以及，分布式事务）的真正原因。当然，不是因为一台服务器不能负载整个应用程序，而是因为一个邪恶的原因：把功能模块与服务器硬件绑定。你已经买了功能A，还想要功能B吗？请购买功能B──和它所在的整个服务器。不管你的访问量是否大到需要一台真正的服务器，我们粗制滥造的程序会把它的性能都用尽的。

是的，再一次地，一个企业级超复杂技术的漂亮广告词被扯开之后，归根结底就是一个制造浪费从而制造需求的邪恶玩意。Fxxx IBM。

一只土贼

2010-06-13T13:32:00Z

我承认一开始我认为小熊就是一只土贼。有次内部讲session的活动，别人的主题都是有模有样的理论结合实践，小熊搬把凳子往中间一坐，胶片也没有，开口第一句就是很土的话：

“其实搞客户就是将心比心。你想想他的利益是什么，帮他把事情搞定了，他就喜欢你了。”

好吧，确实是很有sense的实话。不过这种没有理论高度的话游沁说也就罢了，作为我司的咨询师用湖南塑料普通话这么讲出来，咋就觉得那么土呢？

在广州呆了一段时间之后我就发现这个小海龟基本上是故意装土，装得很土那么别人就觉得自己很洋于是就愿意跟他嘻嘻哈哈。处女座在人际关系上的感觉就是特别敏感哈。而且他有两个特别的好处，第一很会画画，第二对浪费极其敏感。我最喜欢和这种完美主义强迫症患者一起工作。

然后小熊就搞出了史上最华丽的故事墙。在他的感染下我也搞出了一个华丽的大屏幕CI监视器。并且开始用各种华丽的方式工作，虽然还不如他华丽哈。

今天小熊感到很兴奋，表示我们的工作很有意义，并且立下了要出名的目标。我觉得他可以出名。唯一的缺陷就像（忘了是谁）说胡适的：“这个人路子是对的，就是没读过多少书。”我们大部分人都是理论结合实践，他要把实践结合一下理论，拔高一下再写出来，一定会出名。

总之，我觉得这只土贼有可能成为国内最好的敏捷BA。所以我现在开始收集他的签名。

（还有哈，顺便给这个帅锅BA蒸个女盆友～～小熊表示青春痘都冒出来了的日子还是有点造孽～～有意的女童鞋可以找我报名～～）

关于内部工具开发的若干建议

2010-06-12T15:54:00Z

（本文都是基于某些现状与设想的建议，没有得到实践验证。仅供参考，责任自负。）

作为一个超级大软件企业的内部工具开发部门，需要考虑几个重要问题：

避免作恶
发布管理
技术支持

在考虑开发一个工具提供什么价值之前，首先考虑可能造成什么伤害。世界上有很多的开源工具。这些工具不仅仅是源代码的堆积，其中融入了一些最优秀的软件开发者在某一领域的经验与智慧。贸然开发一个新的工具，哪怕只是对现有开源工具的包装，都可能导致很多人失去学习这些经验与智慧的机会。优先考虑知识的普及。教人读《 J2EE Development Without EJB 》比开发又一套框架要好，虽然做起来会更难。春天的旁边是一个好的框架，因为它重视知识的传递而非包装现有代码。

使用业界公认的依赖管理工具来发布。通过邮件发给用户一个“XxxxXxx-V001R002C004B035SP02.exe”是不负责任的。使用 Maven2 或者 YUM 或者 APT 或者 RubyGems 这样体面的依赖包管理工具来发布你的作品。这样能让用户知道自己得到的每个版本都是经过某种发布流程的而不是一个野版本，并且使你的工具能以最低成本与其他依赖包集成。如果公司的信息安全规定禁止普通开发人员上外网从而导致他们无法使用这些体面的依赖管理工具来搭建自己的工作环境，给他们搭一个内部私服，并把下载新依赖的请求委派到互联网。这不仅有利于你自己的工作，而且能让开发人员的生活变得更容易，他们会因此感谢你。

（Windows到现在也没有一个体面的依赖管理工具，所以Windows is stupid。）

用一个简单易用的Bug跟踪工具来管理所有的支持要求，例如 Trac 就很好。建立一个邮件列表，把所有曾经提出支持要求的人都加进去。给用户建立社群，他们就会自己解决绝大部分的愚蠢问题。不要为了漂亮的界面而把事情搞得复杂。用户提问，你解答，把这些事情都变得就像发一个邮件那么简单，你就能得到一个社群──你确实应该考虑充分利用邮件，因为用户不会在知道了支持人员的邮件地址之后还记住你的在线支持社区地址。向那些体面的开源社区学习，向Google学习，看看他们是如何响应用户需求的。

最后，开放源代码。尽管概率很小，但确实有些用户会给你贡献源代码（至少在他们失去耐心继续等待你的fix时）。像Microshit那样暴露几个莫名其妙的编程接口然后宣称“我们的软件具有可扩展性”是不够的，因为扩展永远都会在你没有想到的地方发生。不要把工具的开发者和用户隔开，因为那些用户很可能是比你更好的软件开发者。开放你的SVN地址，把它和开发指南的链接放在工具介绍的第一页上，就像绝大多数体面的开源项目所做的那样。及时并真诚地感谢那些给你贡献代码的人，以及那些checkout了你的代码库并嘲笑它的人，因为他们会让你的软件变得更好。

最后的最后，随时准备抛弃你自己的任何东西，从一段源代码，到一个功能，甚至整个软件。如果你的目标是让别人的工作更容易的话。

配置分布式的CruiseControl

2010-06-07T13:22:00Z

这个文档描述得不是很清楚，因此记录一遍。首先需要同时下载 src发布包和 bin发布包。

解开src发布包，在其中build distributed插件，然后把contrib目录copy到bin发布包解压后的目录：

cd $CC_SRC/contrib/distributed
ant
cd $CC_BIN
cp -r $CC_SRC/contrib ./contrib

修改$CC_BIN/cruisecontrol.sh，在其中包含distributed插件的classpath：

... ...
CCDIST=$CCDIR/contrib/distributed
CCDIST_BUILDER=$CCDIST/dist/builder/
CCDIST_CORE=$CCDIST/dist/core/
CCDIST_JINICORE=$CCDIST/jini-core/
CCDIST_JINILIBDL=$CCDIST/jini-lib-dl/jsk-dl.jar
CCDIST_CONF=$CCDIST/conf

EXEC="$JAVA_HOME/bin/java $CC_OPTS \
-Djavax.management.builder.initial=mx4j.server.MX4JMBeanServerBuilder \
-Djava.security.policy=$CCDIST_CONF/insecure.policy \
-Dcc.library.dir=$LIBDIR -Djetty.logs=$JETTY_LOGS -jar \
$LAUNCHER -lib $JAVA_HOME/lib/tools.jar \
-lib $CCDIST_BUILDER:$CCDIST_CORE:$CCDIST_JINICORE:$CCDIST_JINILIBDL:$CCDIST_CONF \
$@ -jmxport 8000 -webport 8080 -rmiport 1099" 

echo $EXEC
$EXEC &
echo $! > cc.pid

在$CC_BIN/config.xml中指定需要分布的工程：

<plugin name="distributed" 
   classname="net.sourceforge.cruisecontrol.builders.DistributedMasterBuilder"/>
... ...
<distributed>
  <ant antscript="/usr/bin/ant" 
   antworkingdir="/path/to/my/project" />
</distributed>

打开Lookup server：

cd $CC_BIN/contrib/distributed/dist/lookup
ant

然后，把cc_agent.zip拷到Agent机器上，修改conf/agent.properties配置，ant启动，就好了。

（郁闷地搞了一下午的心得是：不要尝试在Windows上做任何严肃的开发工作。Stupid Windows.）

如何做一个能害死人的自动化测试工具

2010-05-29T14:34:00Z

你是一家大公司里不得志的程序员。和你同年进公司的那些人在核心业务上拼命工作，被客户骂，加班，交付，开庆功会，拿奖金。而你，不知道怎么的被放到一个叫做“测试工具开发”的边角部门里，干着一些不疼不痒不影响公司业绩的工作。你恨。你要报复。你要拿回本该属于自己的一切。

现在我教你怎么做。

首先，你要启动一个自主开发自动化测试工具的项目。让老板们相信自动化测试的重要性并不困难，世界上有无数的文章和书籍在讲这件事，你们公司请的咨询顾问一定也会说到这件事，这些都是你的帮手。真正难的部分是“自主开发”。你用得上一个百试百灵的招数。告诉老板们，一个自主开发的工具可以由自己来维护和支持，只有这样才能把核心技术的命脉掌握在自己手里，而不用向别人支付维护支持的费用──小心，千万不要提到那些开源的工具，因为老板们万一真的弄懂了“开源”这两个字的含义，你的整个大计划就泡汤了。拿IBM的RFT当靶子。除了后面我会说到的各种好处之外，IBM的咨询价格足以帮你吓到老板从而启动这个项目。

然后，你要精心选择一个自动化测试执行引擎。你需要这么一个引擎，因为你不能自己去做一个──工作量还在其次，要是连这都能做，你也就不在这个边角部门里郁闷了。同时这个引擎又不能太稳定，更不能太开放，这都是你大计划中不可或缺的要素。所以，你看，我说过了，RFT就是最好的靶子：它的开放程度确保了你要花好几个月时间才能把它嵌在自己的工具里而且以后再也不会有别人尝试干这件事。而且，想想吧，当你跟老板们报告说你hack了IBM的软件从而省下了licence费用时，他们该有多开心。

接下来，你要发明一套自己的测试脚本语法。沿用RFT的语法当然轻松，但这样使用它的人就会发现自己使用的其实是RFT，然后在该死的互联网上找到相关的资料。不能让这样的事发生。始终记住，你的目标是让自己变得重要。你发明的语法应该基于XML。不仅因为实现简单，而且因为它能确保测试脚本无法被阅读和重构，从而让使用这工具的人跪在你脚边求你支持。关于使用XML的好处，稍后我还会说到。

当然你不希望向领导演示时用记事本编辑XML。所以你得同时实现一个支持拖拽的测试用例编辑界面。把一个测试步骤表示为一个图标，把几个图标往测试用例里一拖，一个测试用例就好了。别忘了，执行用例的功能也得在这个界面里实现。千万别为了偷懒而实现一个命令行来执行用例，这很重要。好了，现在你可以去演示了，领导一定会喜欢的。“鼠标拖拽其实比键盘输入慢多了！”旁边一个傻逼顾问叫喊着。领导们不会听懂他的话。不用理会他，更不要尝试跟他争论，那只会给你自己带来麻烦。

现在这个工具可以小范围试用了。那些麻烦的用户会抱怨：“我每次都要重复这几个同样的操作！我想把它们合并成一个步骤！”镇静。不要骂他们（尽管你一直就想骂他们）。记得吗？让测试用例不可被重构是你大计划中的一部分。现在你要笑容可掬说。我们早就考虑到了这个问题，我们的工具可以把几个步骤封装成一个更大的、具有业务含义的东西……嗯，姑且把它叫做“操作词汇”吧。现在我就来帮助你们做这个抽象和封装。当然了，操作也要用XML来承载，并且在提供给用户时要先做一次编译或者打包或者加密，总之是不能让他们看到源文件。这样他们才能永远依赖你。

小范围试用很重要。你必须努力工作，帮用户写测试用例，帮他们封装操作，找你能找到的一切资源来帮他们，然后把投入二十个人月干出来的成果全都描述成你的工具带来的神奇变化。放心，你只需要这么干一次（或者两次）。为了把这些愚蠢的家伙踩在脚下，有时你就得先纡尊降贵。这是策略。

试用结束，你回到自己的办公室，这些愚蠢的用户还会不停地找你帮忙更新被封装的操作。这是设计中的一环。现在你应该做一个中央服务器，把他们的测试用例和操作全都保存在上面，让他们每次执行测试都从服务器上取用例脚本。然后告诉他们，这叫云计算，这叫测试工厂。当然这些傻瓜不会懂得云计算是什么玩意，但他们会发现你帮他们更新操作的速度变快了，然后他们就会认为这就是云计算带来的效果。把他们感谢你的话搜集起来，很快你就会用得上。

现在万事俱备，可以向老板汇报了。这次汇报的重点是两个关键词。这也是今后宣传这个工具时的常用语。一定要背熟。

关键词1：“第四代自动化测试工具”。你要告诉老板，用Java啦Ruby啦C#啦这些编程语言来编写测试用例，那是第三代（前两代是什么就随便你编吧）。第四代的特征就是“基于操作词汇”──也就是图形界面上可以拖的那个玩意，尽管你知道它背后就是一坨不能读、不能改、连SVN合并都困难的XML。

关键词2：“测试工厂”。这时候把界面打开，连上中央服务器，让老板看试点项目的测试用例。“坐在办公室就能知道所有项目的测试进展情况。”这句话是杀手锏。老板们一定会喜欢，而且会帮你推广这个工具。

只要被推广到更多的项目组，你就会变成红人。现在前面那些设计决策的重要性就逐渐体现了。因为测试用例不可重构，任何一个项目想要正经用你的工具都得找你帮忙做操作词汇，为此你就可以成立一个部门，拉更多的人来给你打这份苦工，自己当领导。但你又怕别人真的用得太多太频繁，那样的话你就得疲于支撑了。放心，因为RFT不稳定，因为每次执行都要连到中央服务器来取用例，因为不能通过命令行或者Ant之类的办法把它放进持续集成，还因为用鼠标拖拽就是比用键盘慢得多，自动化测试的进展会非常缓慢，你大可以安心享受自己的新办公室。

先别急着享受，好事才刚开始呢。那些深思远虑的设计决策确保了很多项目不会认真用你的工具。这时候作为推行先进自动化测试理念的红人，你正好可以在老板耳边吹吹风，让他们强迫所有项目使用。强迫的方式有很多，但你必须记住的手段是给测试人员做职业技能鉴定考试：必须学会用你的工具才能评级加薪。这招的关键在于一箭双雕：不仅可以强迫他们使用，而且确保了他们没时间没动力去了解别的测试工具──你当然不想这些傻瓜突然冒出来说“这个开源的工具比我们自己的好用多了，而且还有那么多社区高手在维护和支持，为什么不用它”，对吧？

强行推广之后，你接到的支撑需求肯定会剧增。这时你得好好培训一下客服的小弟。要让他们分清用户的来头。如果是老板重视的项目，如果办公室离你或者离老板很近，就得大力支持。如果来自什么边远山区的支撑需求，那就把它撂到一边凉快去吧。这些边远山区经常会提些奇怪的需求，例如“能不能不连中央服务器执行用例？我们这里无法连通公司内网”。让小弟们直接回复“不行”就可以了。无法连通公司内网的人同样无法有效地跟领导告状，不用担心他们。

好了。现在你已经从一个边缘程序员成功晋升为公司的红人。不仅有一帮小弟鞍前马后，而且一大帮项目头头们都得求着你优先支撑。这快感，又岂是交付一两个项目、开一两次庆功会所能比拟的？恭喜你。你不仅改变了自己的命运，还很有可能改变整个公司的命运呢。

噢，差点忘了最重要的……千万别用你们的测试工具来给自己的项目做自动化测试。微软那帮傻逼把这种行为叫做“吃自己的狗食”，可你做的是毒药，吃下去会害死自己的。切记，切记。

界，越界，以及自制轮子的邪恶本质

2010-05-25T12:29:00Z

做工具需要知道界限。一个好的工具，应该只做一件事并把它做好，是为高内聚；应该以最容易、信息量最少的方式与其他工具集成，是为低耦合。这些道理，Eric Raymond 早就说过了，不应该再重复。

（跑题：GUI迷恋者的盲点在于，他们没有意识到鼠标点击是一个蕴含了多大信息量的操作。在1024×768的屏幕上找到一个48×48的图元然后向右拖拽530像素。啧啧。不懂得文本和命令行的重要性的人不配做工具。）

持续集成工具应该做的事就是让集成能够被“持续”起来。“集成什么”和“怎么集成”是软件开发者自己的事。测试工具应该做的事就是帮助编写和运行测试用例。“测试什么”和“怎么测试”是软件开发者自己的事。这就是一个明确并且信息量最小化的边界。

而坏的工具则总是尝试越界。通过把软件的集成过程本身纳入持续集成工具会让软件被集成得更好吗？不会。只会让软件开发者更加不了解自己的集成。通过把软件的测试过程本身纳入测试工具会让软件被测试得更好吗？不会。只会让软件开发者更加不了解自己的测试。其结果是，拥有现场信息和能力、应该关注这些事情的人不去关注，只管盲目堆代码而不管得到什么软件；没有能力关注这些事情的人被不断求助──他们也没有真正去关注，因为他们没有能力。

简而言之，试图用越界的工具大包大揽软件的质量保证，其结果是没人关注软件的质量。

推论是，自制轮子的工具本质是邪恶的。自制轮子的人没有办法像开源社区那样拒绝越界的非法要求。他们只能迫于上下两方面的压力把不该自己做的事纳入自己的产品中，并因此陷入不断为别人的事提供支撑而没有时间做好该做的事的泥沼。这种邪恶本质是内生的：不仅因为这些工具一定会越界，而且因为这些工具会被强加于人。因此自制轮子的工具永远不如开源工具。

（我知道我的客户会有一些人看我的博客。对了，这就是写给你们看的。你们知道我在说什么。）

知识·欲望·绑架

2010-05-22T12:17:00Z

掌控了那么多知识，而又不愿意提供给其他人使用，又有什么意义呢？但正是因此，我谈到了欲望。罗杰·培根对知识的渴求不是一种欲望，他是想用科学给上帝的子民造福，因此他不是为了知识而寻求知识。而本诺那种欲望仅出于无法满足的好奇心，以及拥有才智的自傲。对一个僧侣来说，那不过是一种转化和抑制自身肉欲的手段。
书本的益处就在于让人阅读。一本书是由论及其他符号的符号构成的，而这些符号又论及别的事物。如果书本不被人通过眼睛阅读，那书上面的符号就不能产生概念，书就成了哑谜。这座藏书馆的诞生也许是为了拯救这些书籍，而如今藏书馆却是为了埋葬这些书而存在，因此它成了叛逆的诱因。

──翁贝托·艾柯，《玫瑰之名》