Andy

读书时间《咨询的奥秘 – 成功提出和获得建议的指南》

Hu Zhenbo — Sun, 21 Feb 2010 09:38:26 +0000

《咨询的奥秘》很早以前看过一遍，似懂非懂。虽然那时候我没有做过咨询工作，但感觉它讲的其实就是人与人相处、沟通的道理。成为一个咨询师之后，重新拾起再看了一遍。于是我真的明白了，这还是人与人之间相处和沟通的问题。不管你做的职业是否被称为咨询师，其实你在很多时候都充当着咨询师的职责，比如那个教作者种花的农夫。

权且允许我做一些粗浅的点评。

咨询第一法则：无论客户和你说什么，问题始终存在
咨询第二法则：无论问题最初看起来怎样，它始终是人的问题
咨询第三法则：不要忘记客户是按时间付费的，而不是解决问题的程度付费的

评：没有客户愿意承认他们存在问题，他们“只是希望你帮助他们在原有基础上进行改进而已”。他们不会承认他们存在问题，他们更不会承认这是他们人的问题，既然他们没有问题，那么你就别指望他们按照“解决问题”的程度付费。

百分之十承诺法则：不要承诺会有百分之十以上的改进
百分之十解决法则：如果不小心取得了超过百分之十的改进，要保证这部分改进不会被注意到

评：已经说了，客户不会承认他们存在问题，如果你不小心帮他们解决了50%的问题，那你不是陷他们于不义吗？同样，对于任何向你寻求帮助的人，你在帮助他们的同时要给足他们面子，他们才会再次寻求你的帮助。

玛威法则：不论客户在做什么，给他一些其它方面的建议

评：咨询的力量，很多都源于此。你有没有经常感觉到被旁人”一点通”？让一个外来力量介入，就是要这个“一点通”。

赏识规则：如果你在意谁得到了赏识，你就永远不可能完成任何事
孤独守卫者幻想：如果客户没有表现出对你的赏识，那就假装他们对你的杰出工作感到震惊 — 但千万不要忘记这只是你自己的幻想，而不是事实

评：作为一个外来力量，在那种”孤独“的地方，总希望得到一些鼓励。而经常的，你并没有收到任何赏识。放下，这是第一要务，不要在意那些赏识，不要被它左右。自信，保持应有的自信以及清醒，这是第二要务。无论如何，作为一个咨询师，你要有力量相信自己。

舍比法则：如果他们没有雇佣你，就不要为他们解决问题

评：在不恰当的时候，主动去帮助别人，会起到相反的作用。记住，你只是咨询师，你的工作是在别人需要的时候帮助他们，而不要摆出一幅父母或者导师的样子。没有人喜欢被教育。

鲁迪芜清甘蓝规则：一旦你消除了头号问题，第二号问题就会升级
艰难法则：如果你不能接受失败，你就不能成为顾问
艰难法则的转换：失败一定是有可能被战胜的
很艰难法则：一旦你消除了头号问题，那么第二号问题就会升级
最艰难法则：帮自己甚至比帮别人还困难

评：没有人能消除所有问题，问题会源源不断，甚至有可能会失败。既然咨询师不能帮助客户解决所有问题，那么咨询师就要懂得在恰当的时候离开。

橙汁测试：我们能做这件事，这是所需的费用。

评：要得到别人的信任和尊重，不是信口开河，不能作践自己。

医学上第一大秘密：90%的疾病都会不治而愈
玛威第一大秘密：对能够自我治疗的系统，要温柔地处理
玛威第二大秘密：再三治疗一个能自愈的系统，将最终产生一个不能自愈的系统
玛威第三大秘密：每一个处方都有两部分：药物和确保药物正确使用的方法
玛威第四大秘密：如果他们以前做的没有解决问题，那么告诉他们做些别的试试
玛威第五大秘密：确保他们付给你足够多的酬金，以让他们能按照你说的去做。咨询中最重要的就是确定正确的酬金
玛威第六大秘密：知道如何不如知道何时

评：存在即是合理，即使在你眼里看起来多么不合理。不要去给那些本来挺好的东西去动刀，结果可能不是治疗而是破坏。在手术台上，作为主刀医师，你应该有足够的地位得到别人的协助，你应该懂得如何正确使用正确的药物，你应该知道在何时下刀，不然，手术就会失败。

伯登规则：如果你不能修改，那就把它作为特色
粉饰规则：如果你不能以之为特色，那就粉饰之
逆粉饰规则：如果什么东西被粉饰了，那它肯定需要被改善

评：咨询师的精力和能力也是有限的，暂时缓住客户有时候是必要的，但不要忘了那些问题还是需要被解决。

斯巴克斯解决问题法则：偶然解决了问题会妨碍我们找出谁是问题的制造者

评：解决问题是客户请你的原因，但解决人的问题才是咨询师的最终目的。

三的法则：如果在你的计划中不能想出三个可能出错的地方，那么你的想法就有什么地方出错了
泰坦尼克效应：认为灾难不可能发生的想法经常导致不可想象的灾难

评：永远要保持谨慎，头脑发热只会害了你

改变第一法则：是黄瓜变得更像腌菜，而不是盐水变得更像黄瓜
普瑞斯科特腌菜原则：试图经过长时间去改变一个大系统的小系统，最有可能它自己被改变

评：咨询师，你永远是个外来者。你要先做好改善，再想他妈的改变。

快餐谬误：没有不同加上没有不同加上没有不同，最终等于明显的不同

评：在该坚持的地方坚持，在该坚守的地方坚守。当你屡次不再坚持，不再坚守，可能你觉得无大碍，但是最终会产生大变化。

新东西法则：没有新东西会好用
潘多拉疹子：没有新东西会好用，但人们总是希望这次能有所不同

评：还是那句话，存在即使合理，先不要急着去做大改动，别给自己惹来麻烦。

水牛套勒：你能让水牛去任何地方，只要它们愿意去那儿

评：你永远无法改变客户，除非他们愿意自己改变，你能做的，就是让他们开始愿意改变。

营销第一法则：顾问处于两种状态之一：空闲或者繁忙
营销第二法则：获得客户的最佳方法就是有客户
营销第三法则：每周至少花一天时间曝光自己
营销第四法则：客户对你的价值，比你对他们的价值重要的多
营销第五法则：不要让一个客户的业务超过你业务总量的1/4
林尼生存法则：为了能对自己说是，就要能对客户说不
营销第六法则：最好的营销工具就是满意的客户
营销第七法则：放弃你最棒的主意
营销第十法则：营销是为了质量，而不是数量

评：无论是顾问，还是谁。在当前的人群中塑造你的口碑，才是最好的营销自己的方法。当然，良好的交际和沟通是非常必要的。慷慨也是必不可少的，没有舍，就不会有得。不要轻易去破坏关系，那些关系可能对于别人不重要，但对你来说很重要。

定价第一法则：定价有很多功能，金钱交换只是其中一种功能
定价第二法则：他们付给你越多，对你的爱越多；付给你越少，尊重越少
定价第三法则：金钱通常是价格中最小的部分
定价第四法则：定价不是零和游戏
定价第五法则：如果你需要钱，就别接受工作
定价第六法则：如果他们对你的工作不满意，就别拿钱
定价第七法则：金钱不仅仅是价格
定价第八法则：价格不是一件事，它是谈判达成的协议
定价第九法则：确定一个让你不会后悔的价格
定价第十法则：所有的价格都基于感觉，无论是你的还是客户的

评：以正确的态度对待价格，以正确的方法利用价格。价格是你赢得的，不是别人失去的，是你给别人创造了价值之后应得的。基于此，要给自己设定一个合理的价格，没有尊严的价格只能让你变得更加没有尊严。但你做的事情，一定要让这个客户觉得值回票价。价格是客户付出的，是他们在意的，你应该合理的利用这个作用，来帮助咨询工作的成功，比如定金。

信任第一法则：除了你以外，没有人介意你让别人失望的原因
信任第一法则：信任花费数年才取得，但只消数月便可失去
信任第一法则：当人们不再信任你时，他们不会告诉你
信任第一法则：获得信任的技巧，就是避免使用任何技巧
信任第一法则：人们决不会说谎 — 在他们自己眼里
信任第一法则：信任你的客户，同时也要切牌
信任第一法则：永远不要不诚实，即使客户要求你这样
信任第一法则：绝不承诺任何事
信任第一法则：兑现你的诺言
信任第一法则：把它写下来，但要在信任的基础上

评：建立信任是一件很不简单的事情，是一件需要始终如一的事情。但建立信任也很简单，就是不要给别人太多期望，同时始终坦诚地对待人和事情。不要耍什么技巧，也不需要给自己找任何理由，那都没有意义。但是，信任，不是无条件的，信任的同时，你也需要合理地保护自己。用公开的方式防范别人作假的可能，用协议来保护双方的信任。

农场教训：
决不用廉价的种子
精心准备的土壤是所有园艺的奥秘
时令是决定性的
扎地最牢的植物是那些自己发展自己根基的植物
过多浇水产生的只是娇弱而不是强壮
尽管你尽了最大努力，一些植物还是会死亡

评：咨询，是帮助人成长以及正确成长的职业。最重要的是在你离开之后。

澳洲东海岸-梦幻之旅

Hu Zhenbo — Sun, 17 Jan 2010 07:18:05 +0000

回到墨尔本，从上周六出发，历经澳洲东海岸的一周梦幻之旅结束了。

先是繁华都市悉尼的二日暴走。

之后飞临冲浪天堂黄金海岸，他们是来自世界各地的冲浪爱好者，也包括我们。

Kirra海滩一望无际的白色沙滩

途中又顺路游览了恬静怡人的布里斯班

最后一站来到潜水天堂凯恩斯，见识了神奇的澳洲土著和热带雨林的奇观

以及最最最梦幻的海底世界

澳洲这片土地真是充满了惊喜。

Rails系统性能优化之路

Hu Zhenbo — Sat, 16 Jan 2010 13:13:24 +0000

这篇文章讲述的是我们在一个Rails on Jruby系统的性能优化之路上披荆斩棘的故事。

优化之前

在开始性能优化之前，有几点必须明确：

1. 性能优化的对象：并不是所有页面都需要优化，而且首先应该选择那些访问率最高、性能瓶颈最大的页面来进行优化。

2. 性能优化的目标：性能优化必须有一个具体的目标，即要达到的响应时间和吞吐量。有了目标，我们就知道目前离目标的距离，需要优化的力度；同时，也知道在何时停止优化。

3. 伴随优化的测量：没有测量的性能优化很可能让你缘木求鱼。

优化之路

下面，分别从多个方面看一下性能优化中的一些实践。

缓存

缓存是性能优化的一大利器。Rails本身对缓存机制有很好的支持。

客户端缓存

一般而言，对于客户端缓存的原则是：对动态html页面不作任何缓存，永久缓存任何其它类型的文件。

Rails很好地支持了这个原则。比如：

stylesheet_link_tag(”application”)

生成的页面元素是：

大家都注意到在css文件后面有个时间戳，这其实是一个小计策：当文件发生改变的时候，时间戳也发生了改变；而客户端会认为这是一个新链接，就会重新获取文件。有了这种机制的支持，我们可以很放心地在客户端对静态文件进行永久缓存，而不用担心过期问题。

服务端缓存

Rails提供了三种服务器端缓存方式：page cache，action cache和fragment cache。对于动态页面，fragment缓存使用的机会会比较多。

让我们看一个例子：一个产品页面片段，片段上面的部分信息对于所有用户都是一致的，但另一部分对于不同权限用户是不一致的。在admin登录时，能看到a链接，b按钮和c复选框；在一般用户登录时，能看到b按钮和c复选框；未登录用户只能看到c复选框。

一种很简便的缓存策略是根据用户标志进行缓存，即对用户p1缓存，对p2也进行缓存，那么我们就可以根据用户的标识以及产品的标志来定位缓存。

但是，这种缓存策略存在一个问题，即缓存数量太大：同一个产品片段存在n份不同的拷贝，n = admin用户的数量 + 一般用户的数量 + 1 （未登录用户）。而且，对于同一种权限的用户来说，他们对同一个产品的缓存是一样的。

消除这种重复的策略是根据用户的类型来对缓存进行分类，那么对于一个产品而言，它只会有3份并且不重复的缓存，3 = 1 （admin权限） + 1 （一般权限） + 1 （未登录用户）。

这可能是一个比较简单的例子，比较容易想到。但在一些很复杂的情况下，可能就会迷惑。其实原则就是：消除重复，根据片段的根本特征差别来对缓存进行分类。但这里引起了另外一个问题：如果根本特征的区别需要对很多数据进行大量的计算，那么缓存就失去了它的意义。所以，要把握好权衡。缓存，最重要的是为了减少数据的重复获取，减少重复计算。

另外，缓存的清理策略是至关重要的：何时清除缓存，以及如何定位失效缓存。对于要求实时性的页面，可以使用 rails提供的sweeper机制来进行缓存清理。但sweeper有个不方便的地方是需要对相关的action都逐一进行声明。我们的系统巧妙地利用了rails的observer：在observer检测到数据的更新时对相关缓存进行清理。

计算结果缓存

在一个request的生命周期之内，有些数据不会改变，或者我们不关心改变，则可以通过对结果缓存以避免重复计算。

def length
@length ||= end – start
end

内存

来看个例子：我们要在一个页面中显示一百个产品的信息，产品信息从一个信息搜索平台获取。下面的代码是从搜索结果数据集创建产品对象：

records.map { |record| Product.new record }

但这里有个问题，Product是一个ActiveRecord类，但页面显示结果并不需要这么“重量级”的对象。取而代之以轻量级的对象会减少内存的消耗，并提升速度。

数据库

性能的瓶颈往往不在语言级别，而在IO上。对数据库的优化是重中之重。

在数据库的优化上有一些耳熟能详的方法，比如：

增加适当的索引以加快查询。有些很好的工具可以帮助我们找到性能的瓶颈，比如分析execution plan。
缩小transaction的粒度以减少锁的见时间。
避免多次创建transaction的开销（如下代码）

Product.transaction do
search_results.each do |search_result|
Product.create(search_result)
end
end

大型查询

对于像报表类的大型查询，要绕过ActiveRecord，而直接使用数据库驱动。同时，对于多表连接的查询，可以考虑几种方法来优化：

引入中间表，让另外一个进程定时把查询结果插入中间表。但这会牺牲一定的实时性。
避免重复结果的获取，减少结果集。这往往出现在一对多表之间，连接会导致“一”这边出现多条重复结果。可以考虑把一个查询分拆成多个查询。
使用存储过程或者functions。当然，这失去的是业务逻辑的透明性和灵活性。

Rails的finder

接下来，探讨一下如何正确使用Rails的finder。Rails的finder是很容易误用或者不合理使用的地方，往往有很多性能问题因此而起。

在使用finder时，要搞清楚几个问题：

是否需要结果集中的所有数据？
是否需要预先加载？

表的扫描是邪恶的，很吃性能。一定要减少获取的结果集，用:select指定需要的字段。配合以创建正确的数据库索引，并在索引上挂载其它需要的字段，避免表的扫描。

正确使用预先加载可以避免n+1查询：

Company.all(:include => :products, :conditions => “company.kind = ‘toy’”)

产生的sql查询是：

SELECT * FROM companies WHERE kind = ‘toy’

SELECT * FROM products WHERE products.company_id IN (12, 423, 431…)

但错误使用预先加载是个很危险的事情，它可能不会影响结果的正确性，但会引起很严重的性能问题：

Company.all(:include => :products, :conditions => “products.id IS NOT NULL AND products.weight > 10″)

其实写这个查询的人的目的是为了找出拥有products，并且products的weight大于10的company。但这个语句导致的sql查询是性能低下的：

SELECT companies.id AS t0_r0, …., products.id as t1_r0, … FROM companies
LEFT OUTER JOIN products ON products.company_id = companies.id
WHERE products.id IS NOT NULL AND products.weight > 10

这个sql查询有两个问题：

结果集中的products信息是不需要的
LEFT OUTER JOIN的性能劣于INNER JOIN

我们可以使用如下的语句来避免这两个问题：

Company.all(:joins=> “INNER JOIN products ON products.company_id = companies.id“, :conditions => “products.weight > 10“)

它生成的sql是：

SELECT companies.* FROM companies
INNER JOIN products ON products.company_id = companies.id
WHERE products.weight > 10

这个查询的效率会高很多。所以，正确使用Rails的finder是至关重要的。

页面

View的helper方法生成html元素，比如：

link_to “My Company”, company_path(@company)

# => My Company

过度使用helper方法会引起性能问题。比如上面这个方法，每次都会调用link_to和company_path — 从routes中解析path。

但注意，只有在过度使用的时候，才需要考虑是否可以减少helper方法的使用来提升性能。同时，也可以用一些工具替代ERB来提升性能，比如erubis：它通过预处理避免每次调用的重复开销。

多线程

版本2.2之后，Rails终于是线程安全的了，意味着我们可以开启多线程模式，这绝对是一个巨大的进步。

非线程安全的Rails，无法有效利用共享资源。在以前的版本中，假如我们的应用部署在mongrel上，那么对于n个并发请求，就需要n份rails，n份application，n个数据库链接等等。几乎所有的东西都无法共享。

多线程模式，对于Rails on JRuby带来的改变尤其巨大，因为jruby的线程是native thread（相对于ruby的green thread）。比如我们的系统只开启了一个应用实例来处理所有的请求（当然，当瓶颈出现在一些共享资源上时，可以考虑增加实例）。

还是用数字来说话吧：Rails on JRuby的内存使用是原先非线程安全时的1/n (n是并发请求的数量)，是Rails on Ruby的线程安全模式的1/m（m是cpu的数量）。

那么，开启多线程模式要注意什么？如果你的应用中有类变量的使用，请注意它们是否会在并发下出现问题。

服务器

服务器的配置优化对性能的影响很大。我们的系统以war包的形式部署在tomcat上，主要的配置优化在于对JVM的内存分配上。可以从这几个方面看：

xms — 初始内存大小是否合适？如果你的系统在一开始的时候就需要较大的内存分配，就可以设置一个合理的xms值。
xmx — 最大内存大小是否合适？如果太小，会导致OutOfMomery，会导致持续的GC；反之，则会导致一次GC时间过长，在这段时间内，系统的性能将会受到影响（当然，这跟GC的算法有关）。

性能优化的几个原则

更近

数据库，应用服务器，web服务器以及客户端，这是信息传输的一条链（当然，有些系统的链会更长，更复杂）。那么，减少响应时间的一个原则就是：让数据离客户端更近。

一个最能体现更近原则的优化就是客户端缓存–客户端是距离用户最近的地方。

更加细节的一些例子，比如sql server的nonclustered index现在可以把非键的数据挂载在索引的叶子节点上，这样就不需要再去表上扫描获取这些数据。这也是更近原则的一个体现。

更快

更加快速的响应，需要更加快速的计算。前文中提到的加速页面元素的生成，就属于更快原则。

这方面的实践包括有算法优化，数据库索引，使用更加高效的方法，使用正则表达式匹配等等。

举个Rails中的例子：使用Model.find_by_*方法是很低效的，因为它需要调用method_missing来动态生成方法。而Model.find_by_sql方法的效率高很多。

更少

传输过多的数据，进行过多的操作，可能都会影响性能。

减少数据的传输量有很多例子：压缩静态文件，以减少服务器和客户端之间的传输量；避免在action中滥用实例变量，以减少实例变量在action和view之间的传输；正确合理使用finder，以减少从数据库中获取的数据量等等。

减少操作次数的例子有：合理运用预先加载，减少查询次数；减少transaction的不必要重复创建等等

其它还有：缩小transaction的粒度；缩小并行运算锁的粒度等等。

平衡

在追求更近、更快、更少的时候，要注意平衡。

比如给JVM分配一个合理大小的内存，而不是过大或者过小；不要滥用数据库索引，要考虑是否会影响插入数据的速度；平衡一个运算在空间和时间上的消耗；保持性能在长时间内的平稳等等。

性能优化是一个不断实践、不断调优的过程。比如前文中提到的服务器端缓存，最后并没有被采用，因为我们发现相比而言缓存命中的开销反而更大。

小结

在经过一系列的优化之后，我们的系统很好地满足了客户对性能的要求。下面是几点总结：

大多数性能问题都出在IO上，IO应是关注的重点。
性能优化是一个实践的过程，空讲理论是没有意义的。
出现性能问题，先不要怪罪于平台、语言、框架，大多数性能问题都产生于错误或者不合理的实现。
性能优化过程并不一定需要贯穿整个项目的始终，但一定要时刻保持对性能问题的关注：从刚开始的架构设计，到项目开发中的代码编写、重构等等，性能都应该是关注的一个方面。

————————————————————————————————————–

此文是三个月之前的旧文了，刚发表于2010年1月刊的《程序员》杂志。

读书时间：《软件开发沉思录》

Hu Zhenbo — Sat, 14 Nov 2009 07:55:01 +0000

《软件开发沉思录》，参与了翻译，出版也很久了。但上个礼拜才拾起来，今天才把整本书读完。

13个来自不同职位、不同角色的ThoughtWorks员工成就了这样一本书–可以说，非常精彩。

看完这本书，第一个感觉就是公司知识和文化的传承做得充分到位。因为读很多章节，都会联想到自己在曾经或者现在项目中遇到的问题和解决方案，它们是何其的相似。第十二章-一键发布，我们在曾经的项目里面就完美地实现了。第十四章-实用主义的性能测试，我甚至很想厚着脸皮说：我们实际上早就已经超越了。

第四章-语言的盛景，让我们看到一个百花齐放的时代，这不，Google刚刚发布了它自己的语言Go。同时，随着并发的需求越来越强烈，也让我下定在今年学习一门函数式语言的决心。

公司老板在第二章里面就开宗明义的说到：敏捷过程的价值，就在于减少从“提出业务需求”直到“软件上线来满足业务需求”这两个端点之间所需的时间与成本。但这不妨碍也不冲突一个软件开发人员拥有一些艺术上的追求。在整本书中，我最钟爱的就是第六章–对象健身操。这个章节的内容并不算新，它们都可以在前人的一些书籍中找到，比如《重构》、《设计模式》等。但作者巧妙得总结出一套简单的实践和易记但深刻的经验来支持程序员写出优质的代码。如果说《重构》、《设计模式》等是基石，那么对象健身操就是一套在基石之上的简单的工具集合。

总的来说，这本书，值回票价！

不要在习惯中死去

Hu Zhenbo — Sat, 07 Nov 2009 05:11:21 +0000

忍受是可怕的,因为它会让你慢慢习惯,直至死去却不自知.

当进入一个新团队的时候,我发现有太多的事情不能忍受.

我不能忍受机器环境的不一致: 团队已经为此付出太多无谓的时间.测试在这台机器上跑过了,却在另外一台机器上失败了.

我不能忍受团队的低效: 有太多可以自动化的命令,团队却还在坚持使用手动操作.

我不能忍受没有code diff环节的工作: 因为我突然感到心虚了,因为我对团队中其他人所做的事情毫无所知.Code diff是一项比站立会议有意义多的行为.

我不能忍受回顾会议没有action list: 大家提出了各种担忧,但没有一项得以执行.

我不能忍受设计中的坏味道: 当我提出进行重构的时候,团队却以没有时间来推脱.我相信,设计中过多的坏味道就是当初的”没有时间”所导致的.要等到无可挽回的时候再来补救么?

我不能忍受以所谓的隔离为由让所有的测试都成为mock测试: 因为这已经成为一个公认的弊病,但团队还是听之任知.

我不能忍受团队的保守: 对于新建议缺乏开放的态度.

我更不能忍受团队的短视: 屡屡以工期为由放弃了可以带来长远好处的实践.

两个礼拜之前,当我跟团队提出这些建议的时候.他们的第一反应让我惊讶,因为他们觉得”我们做得挺好的,没有改进的必要”.当我再试图慢慢渗透时,他们终于承认了这些实践的必要性,但他们还是以”没有时间或者我们都知道就可以了”的目的推脱.

两个礼拜之后,当我对其中一些曾经的坚持慢慢妥协之后.有种感觉突然上来了:”就是这样的“.

我知道,我的坏味道已经出来了.我们团队仍旧没有实行code diff的实践;我也为项目贡献了越来越多的mock测试……

忍受到习惯了.这时候,离死期也不远了.

当第一辆车出现破窗户却对它置之不理的时候,越来越多的破窗户就会出现了.

大道理谁都懂,但没有行动等于什么都没有.

胡凯的敏捷之形和熊节的知易行难已经在述说着相似的故事,发生在不同地方的版本.

这同时又让我反思,在曾经我也已经很习惯的团队里面,是不是也有这些我们未曾发觉,或曾经发觉但最后已经习惯的坏味道? 我们曾经是否以开放的态度接受了别人的建议,还是以自我感觉”挺好的”而不加考虑? 绝对有!

团队及时彻底的反思,以及开放的态度至关重要.这是避免让坏味道成为习惯的根本.那如何做到反思彻底,态度开放? 先让下一次回顾会议成为一次真正的回顾会议!

Vim

Hu Zhenbo — Thu, 29 Oct 2009 12:47:18 +0000

It’s very important for you to manage a text editor if you are an programmer, no matter if it’s Vim or Emacs. It cannot cost you longer than one week, but you can benefit from it for a life!

Lonely Planet Office

Hu Zhenbo — Tue, 27 Oct 2009 12:39:21 +0000

Lonely Planet office座落在墨尔本西南市郊,办公室的房子颇有点798红墙工厂的风格.

隔着Maribyrnong river跟市区遥遥相望. 江边上那些集装箱很多都来自中国.

办公室里面很fancy啊,很有一个大家庭的感觉.

走进他们的办公室,书库,琳琅满目ing~~ Ellen很慷慨地让我自己随便拿,不过我只是很收敛地拿了两本.

Ellen带着我在办公室上上下下转了一圈,见了很多人.有些是已经共事很久,但从来没见面的朋友.见到之后很有种惺惺相惜的感觉. Ellen还特地带我去见了负责亚洲事务的女士,在她的桌上发现这本熟悉的书.

《ThoughtWorks文集》中译本序

Hu Zhenbo — Mon, 26 Oct 2009 14:33:15 +0000

这本《 ThoughtWorks文集》中译本面世之际，也正值“敏捷中国2009大会”召开在即。两者可谓相得益彰。

从 2004年进入中国，ThoughtWorks见证和参与了中国敏捷社区的发展历程：从五年前的筚路蓝缕，到如今的欣欣向荣。更令人欣慰的是，在原则、价值观等“大问题”上，敏捷的实践者们已经基本达成共识，社区的话题更加趋于关注实践──这意味着敏捷社区正在步入成熟，将用他们的知识和技能为各自效力的企业创造更大的价值。

我们在这个时候把《ThoughtWorks文集》翻译出版，是希望为社区的发展再尽绵薄之力。作为敏捷方法的积极推动者，ThoughtWorks从多年、多个行业的实践中积累了丰富的经验。本书收录的13篇文章涵盖了编程技术、项目管理、持续集成、测试等方面内容，将带领读者了解ThoughtWorks在软件生命周期各个环节所推荐的工作方式。

比较难得的是，这本《文集》不仅由 ThoughtWorks员工撰写，也由ThoughtWorks员工翻译。译者们或是与文章作者素有私交，或是在文章所论述的领域有所专擅，这也使得翻译的质量更有保障。感谢这些译者在工作之余的辛勤翻译，才使这本《文集》如期付梓。他们是：韩锴，胡振波，金明，李剑，乔梁，熊节，徐昊，张晓庆，郑晔。

一本薄薄的《文集》当然不可能解决所有问题，我们更希望它能够收到抛砖引玉的效果。希望ThoughtWorks的经验心得能对国内的敏捷实践者们有所启发，帮助他们做出更多创新，创造更大价值。最后，希望你阅读愉快。

郭晓
总经理，ThoughtWorks中国公司

澳洲游记 – 墨尔本之city

Hu Zhenbo — Sat, 24 Oct 2009 09:17:30 +0000

两个礼拜之前,从浦东机场飞往墨尔本.上了飞机之后感到无比的窒息,狭小的座位,十几个小时的飞行,漫漫长夜如何度过…

右边坐着一位光头留学生,跟他使劲地打听这边的生活.后来就迷迷糊糊得睡着了.过了一会儿,光头把我叫醒.原来吃早餐了.一看表,四点多(北京时间).吃完早餐,又打了会儿盹.感觉飞机已经在下降.光头望着窗外,叹了一口气:又到了这个万恶的地方.

想比于浦东机场,墨尔本的机场完全就不起眼.据说有个叫Ozzi老兄来机场接我.刚开始看到这个名字,我一直以为是个澳洲土著.没想到人家还是个正经白人.

星期天早上,我想应该不会堵车吧.车子从机场到住所,也就不过20分钟距离.一路畅通.其实应该说,路上根本就没什么车.用英国兄弟Mike的话讲,这个城市好empty.

在车上Ozzi拿着地图跟我比划:住所在哪里,公司在哪里,中国城在哪里.看着地图中四四方方的一小块,脑中和北京地图比较了一下.怯怯地问道:明天早上我怎么去公司,你来接我么? Ozzi回道: You can’t be lost. 后来我才知道,那四四方方的一小块,是两平方公里的CBD,也就是光头跟我说的所谓city.站在住所的阳台上往外看,一公里之外高楼就突然消失了,远处就是树林和隐约所见的房子.

这两个礼拜,一直困在city,没有出走半步.因为要在这边呆很长时间,所以也就没有那么急迫的动力出去玩.不过今天第一次出去跑步,就像发现新大陆一样,原来在我住所旁边就是Victoria Harbor. 海风微拂,春和景明. 港口上停满了私人游艇. 不知道为什么,周末竟然这么少人出海.

在city里面闲逛,没有太多异乡的感觉.因为身边经常会出现中国人的面孔,听到中国人用汉语谈话.在超市买东西,抬头一看,发现都是中国人的身影.到了中国城,这种感觉就更甚了.

同事多次邀请我去pub玩,刚开始我都谢绝了.因为实在不怎么喜欢pub,最重要是不喜欢和老外在pub玩.他们讲什么笑话,我基本上只能看着他们笑我也跟着笑.不过有一次我终于还是跟着他们去了,在pub里面喝了一种叫做zombie的东西.刚开始听不懂这个单词,于是他们就跟我解释这个东西在中国应该是被禁止的.我在想我靠不会让我喝什么带有毒品之类的东西吧.然后他们又向我解释这个东西就是dead people stand up.我终于明白是僵尸.不过还好只是个名称而已,做法很奇怪,用的杯子很奇怪,加了各种原料.味道却还不错.

从pub出来也就是晚上十点,但路上已经人影稀疏,出奇的安静.墨尔本多次被评为世界上最适宜人居住的城市.之前一直没怎么感觉,现在终于明白原来人越少的地方就是越适宜人居住的地方.

光头一直跟我说这是个万恶的地方,但我发现这里的人民生活挺安康悠闲的.社会已经发展到一个稳定的状态,资源丰富,而且能让多数人共享.不同职业间没有太大收入的区别,所以大多数人可以根据自己的兴趣选择职业.这里的物价相对于收入水平而言其实很低.家庭年收入的四倍就能在CBD买一个公寓.当然光头的压力比较大,因为拿着人民币在这里花.

虽然呆的时间不久,但隐隐有种感觉.就是对于生活的理解悄然发生了一些变化.下班就是下班,周末就是周末,像我这样周末还在写博客的人是很少的.而中国人,特别是城市人,永远都生活在奔波中.无论是富人还是穷人.对于他们来说,没有下班,没有休息.

到这边之后还没拍过照片,以后补上~~

Rails之美

Hu Zhenbo — Wed, 07 Oct 2009 08:51:27 +0000

本文发表于《程序员》杂志2009年10月刊。可能由于编辑的工作繁忙，发表的不是此最终版本。杂志发表版本中有些不恰当表述，对此造成的困扰，深表歉意。

Rails之美，我总结的有这样几点：简洁、透明、自由、开放、轻灵、丰富和优美。可能你已经感觉到，这些词汇大多展现的是感性的一面。没错，Rails开发的每一天都是那么“畅快”，畅快背后其实就是这些生动的感触。笔者希望从这些简单的感触出发，结合实际的例子，来展示Rails真实的美。

Rails之美

简洁

可能很多人在推荐别人使用Rails的时候，都会列举一个理由：简洁。的确，简洁是促使很多人开始学习和使用Rails的原因。那到底什么是简洁？简洁可能代表少，简洁可能代表没有重复，简洁当然也代表复杂的对立面。

Rails是基于ruby语言的。动态语言带来的好处之一是代码量的急剧减少。有一个鲜活的例子，有一次跟客户进行pair，把曾经用Java实现的一个900多行的类，缩减到了100行。客户很是惊讶。当然，纯粹量的减少可能并不代表什么，但至少带来了清晰和易读这两个对代码来说非常重要的特性。

因为动态语言的良好支持，Rails框架使重复的配置工作减少到了极致。比如在Java世界的大量OR Mapping配置文件，在Rails里面不再需要。虽然现在Java世界的配置量也在不断地精简，但还是占据了一定的工作量。重复工作的减少，亦即工作效率的提升。

作为Web开发领域的DSL，Rails提供的各种机制在各个层面极大地简化了开发的工作量和难度。比如ActionView提供的FormHelper，简化了页面上form的生成；比如ActiveRecord提供的Association，简化了模型之间关联的维护。

举个association的例子，来看一下Rails的简洁之处。下面这两个模型是一对多的关系：一个lightbox有很多images。

class Lightbox < ActiveRecord::Base
end

class Image < ActiveRecord::Base
end

要删除一个lightbox，以及它的所有images，需要这样写：

@images = Image.find_by_lightbox_id(@lightbox.id)
@images.each do |image|
image.destroy
end

@lightbox.destroy

接下来，让我们给它们声明正确的关联关系：

class Lightbox < ActiveRecord::Base
  has_many :images, :dependent => :destroy
end

class Image < ActiveRecord::Base
  belongs_to :lightbox
end

则删除操作就变得简单了，且在语义和逻辑上更加明确和清晰：

@lightbox.destroy

DSL的一个目的是使某个领域的开发变得更加具体、简单和清晰。Rails框架是从一个现实项目中提炼出来的，这同时也证明了一句话：好的框架都不是凭空想象出来的。

Rails还有很多其它方面可以体现它的简单。简单，就是美。

透明

项目开发过程中，让我觉得很痛快的一件事情是：基本上不需要借助任何外部的文档。

因为Rails本身是透明的，这首先是动态语言提供的好处。当需要了解任何一个方法的功能或者实现时，只需要跳到那个方法查看源代码即可。

同时，对大多数方法，Rails都提供了详尽的文档以及具体的示例。

开放的源代码，以及详尽的注释，让开发人员得以在一个“透明的环境”上进行开发。开发中可以彻底地了解所用工具的习性，这不可谓不是一件痛快的事情。

自由

对一个问题，Rails往往都提供了多种解决方案。我们可以根据问题的场景，自由地选择合适的方案。

比如对于页面中form的生成，我们可以选择使用form_tag方法。但当这个form跟对象关联的时候，更好的选择是使用form_for方法。结合text_field等helper方法，使页面上的元素跟对象的属性更加紧密地结合。

下面再举一个association的例子，来看看Rails如何表现自由的精神。声明多对多关系时，一般是这样的：

class Teacher
  has_and_belongs_to_many :students
end

class Student
  has_and_belongs_to_many :teachers
end

但有时我们需要利用中间表，并让它映射到一个模型。那么，可以这样来声明模型之间多对多的关联：

class Teacher
  has_many :relations
  has_many :students, :through => :relations
end

class Relation
  belongs_to :teacher
  belongs_to :student
end

class Student
  has_many :relations
  has_many :teachers, :through => :relations
end

选择的多样化带来的是自由。但根据需要和场合选择正确的方案，更加重要。

开放

Rails所体现的一点极其重要的精神是：开放。因为Rails从来不限制你去做任何事情。

有个项目是建立在一个遗留数据库上，并且大多数数据库表结构和遗留数据因为有些原因不能更改。但问题是表结构并不满足Rails的约定，下面列举一些问题和解决办法来窥探一下Rails的开放精神所在。

问题1：单数表名

根据Rails的约定，表名都是复数形式的。比如一个User模型，对应的表名是users。而遗留数据库上的表名是单数形式：user。

解决方案

在environment.rb文件的配置初始化里，关闭默认的复数表名配置：

config.active_record.pluralize_table_names = false

问题2：type字段不代表单表继承

根据Rails的约定，type字段是单表继承的保留字段。当从数据库读取数据并实例化成对象时，它会根据type字段的内容来寻找相应的子类型。但这里type字段并不代表单表继承。

解决方案

在模型里面声明另一个字段代表单表继承，比如：

set_inheritance_column :clazz

问题3：type字段的值不满足单表继承的约定

又出现另一个问题，type字段用来表示单表继承，但是它的值并不满足单表继承的约定。根据Rails的约定，type的值应该是类名。比如ShoppingCart继承自ImageCollection，那么type的值应该是”ShoppingCart”。但在遗留数据库里，使用的是”shopping_cart”。

解决方案

这里涉及到两个问题，一是在存储一个对象时要设置正确的type值，二是实例化成对象时，需要根据type值找到正确的子类型。通过查看源代码，发现计算type值和子类型的分别是ActiveRecord上的sti_name和computer_type方法。大家都应该想到了解决方法，就是覆盖这两个方法。对于ShoppingCart类，解决方案可以这样：

def sti_name
super.underscore.upcase
end

def compute_type(type_name)
super(type_name.downcase.camelize)
end

通过上面的例子，我们已经了解了Rails的开放。Rails有很多约定，但不代表强制。而且Rails的开放不仅限于此，比如你可以打开任何一个类，往里面添加方法（当然，这是Ruby给予的权力）。举个例子，比如我们可以通过打开NilClass，来实现Null Object模式（在有些情况下这种做法比较极端）:

NilClass.class_eval do
def your_method
…
end
end

有些语言在天性上对程序员防备多于信任，他们总觉得赋予程序员过多的权力，会容易带来破坏。但其实防止破坏靠的应该是程序员的修炼和自我约束。语言，应该以一种更加开放的态度赋予程序员更多的权利和自由。

轻灵

很多人都觉得Rails是一个庞然大物。但其实Rails并不庞大，DHH在迷思系列里面也解释过。而且，Rails可以轻松剔除任一可选组件。比如要去除ActionController的benchmark组件，只要注释掉include ActionController::Benchmarking，并删除相应的文件即可。

在这背后，其实有一个神奇的方法，叫做alias_method_chain。这个方法非常有用，它的设计理念很好地支持了Rails轻灵的特性，因为它让Rails的各个可选组件都只是很“轻巧”地挂载在上面。继续用Benchmarking这个例子来了解一下它。

Benchmarking的功能是度量action的性能，并把结果输出到日志。这其实是对perform_action方法的增强。从Benchmarking源代码中可以看到如下的代码：

alias_method_chain :perform_action, :benchmark

以及perform_action_with_benchmark方法的实现。

其实，alias_method_chain跟下面的实现是等价的：

alias_method :perform_action_without_benchmark, :perform_action # 为原来的方法建立别名
alias_method :perform_action, :perform_action_with_benchmark # 重定向原来的方法名到功能增强之后的方法

这种方式其实就是AOP的工作方式：ActionController::Base声明了perform_action方法，但它对benchmarking一无所知，只要把Benchmarking模块包含进去，就获得了benchmark的功能。Rails通过这种方式实现了低耦合，我们可以轻松地选择去除非必要的所有可选组件。Rails并非庞大，它是轻灵的，但我们需要了解它。

丰富

发展到今天，Ruby和Rails社区已经非常的活跃和强大。千万开源爱好者在不停地贡献着各种各样的Rails插件和Ruby库。

比如认证系统插件：restful_authentication，分页插件：will_paginate等等，这些插件的出现帮助我们节省了很多工作。并且，这些插件的实现都非常的优美，并不断地在优化和演进。

强大的社区支持，丰富的插件，让Rails开发变得更加容易。

优美

Rails的优美体现在很多地方，比如它本身就是一个REST风格的WEB架构。

但REST就代表着优美么？这不足以让人信服，还是举个例子吧。

假定有一个InvoicesController，现在需要生成一个invoice的pdf。我们可能会想到给controller添加一个叫做download_pdf的action：

def download_pdf
invoice = Invoice.find(params[:id])
send_data(generate_pdf(invoice), :filename =>

“#{invoice.no}.pdf”, :type => “application/pdf”)
end

但从另一个角度看，其实pdf只是invoice这个资源的一种表现形式。而展现一个资源，更适合让show action来做。用REST风格实现invoide的pdf下载：

def show
@invoice = Invoice.find(params[:id])
respond_to do |format|
format.html
format.pdf { render :pdf => generate_pdf(@invoice) }
end
end

用正确的方式做正确的事情，就是优美的体现。

反思

介绍了这么多Rails开发的优点，肯定有人不禁要提问：Rails开发难道就没有欠缺的地方么？

笔者也一样，在开发过程中不停地反思。比如为Rails创造最大声誉的“快速开发”，就值得谨慎看待。用Rails搭建的系统在代码量上确实少了很多，但纯粹用代码量来衡量开发效率是不准确的。有几点思考：

1. 当今程序员不再是纯文本编辑时代，强大的IDE极大地提高了程序员的开发效率。但作为一种动态语言，Ruby目前还很难享受到这种好处。
2. 对于任何语言，要写出简洁优美高效的代码，都需要精雕细琢。
3. 随着语言的进步，开发效率真正的瓶颈越来越多地体现在业务逻辑上，而不是代码的编写上，特别是对于复杂系统而言。

从上文列举的那些例子中我们可以看到，Rails很美，但只有在正确使用它时才会很美。初学者可能会因为经验的缺乏落入一个又一个陷阱。不可否认，Rails的性能问题一直是大家担心的。但系统的性能问题真的是Rails本身引起的么？看似优美的代码，背后是否做着一些“丑陋”的事情？希望能在下篇讲述性能优化故事的文章中跟大家再次分享和探讨这些问题。

无关敏捷，关乎责任

Hu Zhenbo — Wed, 09 Sep 2009 14:57:17 +0000

JJG在《The Elements of User Experience》特别强调，要让每一个人参与到网站设计中：高层管理人员，市场人员，销售人员，等等。不过这里，我想他忽略了一个很重要的群体，就是开发团队。

《The Elements of User Experience》把用户体验分为五个要素： Strategy, Scope, Structure, Skeleton, Surface。

其中最根本的是strategy，因为它是用户的需求和网站的目标。

在我们的开发过程中，拿到一个story并不意味着开发的开始，而往往很多时候我们会花很多时间论证这个story的价值所在。开发团队经常会向客户提很多问题，探究这个story的起源和目的；开发团队经常和客户一起讨论甚至争论一个story的功能或者设计，因为随着开发的深入，对项目的了解，我们有义务告诉客户我们所想，帮助客户找到真正所需。

讨论的结果可能证明开发团队是错的，也可能证明客户是错的。但双方都在讨论中对story的价值越加清晰。

因为通过争论，客户会发现

其实这才是我们真正想要的：经过向公司相关人员咨询，发现这果然是更好的方案。
原来可以通过这种更简单的方式得到我们想要的，得到用户所需要的。
应该丢弃这个功能，这样做是错的，这样的设计不仅对我们未来的业务发展没有好处，而且还可能成为一个束缚。
……

开发团队：

的确客户是对的，我们在实现的东西是有价值的。
又一次不仅帮助了客户找到了真正的价值，也避免了让自己花很多时间做一个用户不会喜欢的功能。
……

印象特别深刻的是在项目结束之后，客户的BA诚挚地对我们说：谢谢团队的每一个人，谢谢你们不停地问问题。

后面的那句话，我想，是他们意外得到的。所以在感谢的时候特别地提了一下。

开发团队保证正确实现客户所要的，就够了么？不，开发团队要保证正确实现客户真正想要的。

这里无关敏捷，这里关乎责任。

The Elements of User Experience

发布之后

Hu Zhenbo — Sun, 06 Sep 2009 12:49:20 +0000

发布之后，系统才开始在真实的数据、环境上运行，才开始经受真实用户的考验。发布，不意味着项目的结束，却是挑战的到来。如何在发布之后，快速修复影响到系统使用的bug；如何在发布之后，快速改进在真实环境中无法承受的性能问题；如何在发布之后，快速调整用户体验较差的界面设计或者功能实现。开发团队或者维护团队，如果不能快速响应这些突然袭来的变化，就会给客户带来损失。

同时，从发布之后出现的问题，可以反思开发过程中某些方面的不足。以下会列出我们在发布之后遇到的一系列问题，以及对这些问题的思考。

难以重现的问题

当发现bug的时候，立即想到的就是在测试环境或者UAT上重现问题，以便快速定位问题的根源。

场景

系统发布一个小时之后，客户一封邮件过来，告诉我们有一个重要功能在产品环境上不工作：一个公司无法为她的包月套餐付费。于是，我们立即在测试环境上试图重现问题，但失败了；UAT上也如是。这是一个重要的功能，经过详尽的测试，却在产品环境上突然出现问题，令人匪夷所思。于是，只好到产品环境上测试，果然重现了bug。首先排除了环境的区别，那么肯定就是数据的区别。在仔细观察数据的时候，敏感地注意到一个特征：被测公司的所有员工都没有接受网站的条款。马上在测试环境中建立同样特征的测试数据，果然重现了bug，并找到了问题的根源。

反思

有些bug会很难重现，而之所以难，根本原因在于忽略了出现bug的测试场景（包括数据、环境等因素）。导致这个bug出现的根源在于测试不够全面。如果在测试中尽量覆盖边际情况，就可以避免多数类似问题的出现。

产品环境中仅有的问题

产品环境和测试环境的差异在哪里？

场景1

这不是一个功能性bug：有一个页面在产品环境中出现了不应该有的滚动条，却十分影响页面的美观。对照测试环境和产品环境之后，发现是因为在产品环境中一个链接的url过长导致信息框出现了滚动条。

场景2

页面上有个回退链接，会回退到之前访问的页面。有些时候却回退到了网站的首页，在测试环境中无论如何也不能重现这个bug。在产品环境下，发现出现问题的页面都是从https跳转过来。查看代码，果然没有考虑这种情况。

场景3

在用某些关键词搜索的时候，会出现500错误。而在测试环境中却无法重现。非常幸运的是客户发来了产品环境的log，经过分析，发现问题在于产品环境中集成的第三方工具提供的有些数据会导致程序错误。

反思

这些都是典型的由于测试环境和产品环境数据或者环境不一致引发的问题。如果能在测试环境中尽量保持数据的拟真性、环境的真实性，则可以尽量避免这些问题在发布之后才被发现。但从另一方面看，出现这些问题的根本原因在于代码不够完善。场景一中前端代码的包容性不够好；场景二中引起问题的代码有一些比如hard code的bad smell，却没有被及时修复；而场景三的代码是有漏洞的，它没有很优雅地处理数据获取失败时的情况。

无法获知起因的问题

有些用户遇到了问题，但我们无法或者没有时间去一一获取这些用户的信息。

场景

新系统上线之后，所有老用户都得重新接受新的网站条款。但有些用户无法点击接受条款的按钮，严重阻碍了这些用户的回访。

反思

这个问题可能只出现在千分之一的用户里面，试图去获取所有这些用户的客户端环境（浏览器版本）很困难，而客户又要求我们立即解决问题。所以，试图去重现问题已经不可能了。不如凭着经验审查一下原有的代码是否有瑕疵，前端代码是否浏览器敏感。然后给出一个更通用、更完美的方案。这类问题是无法避免的，除非花费大量时间对所有客户端环境都进行测试。但这类问题是可以解决的，比如上面那个bug我们就通过采用兼容性更好的代码解决了。

真实用户体验的问题

真实用户才是真正的测试人员。

场景1

一个页面有分页功能。用户来到了第n页，进行了一个操作之后，重定向到了第一页。而用户显然希望能继续回到第n页。

场景2

几个按钮应该排成一行，但当用户输入一个很长的名字之后，出现了换行。

反思

这类问题不算是bug，但却影响了用户的体验。测试人员虽然会站在用户的角度去测试功能，但最好的测试人员其实就是真实用户。如果有条件能在发布之前，让一些真实用户参与测试，是发现这类问题的最好方法。

遗留的疑难问题

既然是遗留的问题，肯定是难以解决的问题。

场景

系统中有几个暂时不影响发布系统使用的bug，它们被一直拖到了发布之后，因为之前“难以解决”。

反思

虽然这些bug最终都被修复，但这是一种不正确的方式。疑难问题不应该留到发布之后：在发布之后能解决的问题，那么在发布之前也一样可以解决；如果在发布之前确实无法解决，那么就应该选择其它方案。如果在发布之后花了很长时间也解决不了这些bug，就进退两难了。同时，维护团队一定要保证部分核心开发成员的继续留任。如果在交付产品之后，开发团队立即全部撤离，而把系统的维护交给一群对业务和实现完全不熟悉的人，是一种很不负责任的态度。

不会有问题的问题

这个功能不是已经经过验收了么？

场景

第一眼看到客户报的有些bug时，脑中飘过的第一个想法是：这个功能肯定经过详尽的测试，而且肯定经过了客户的验收，怎么可能有问题呢？但在测试环境中确实重现了bug。

反思

之所以在看到这些bug的时候比较难以置信，是因为我们以为这些功能已经被测试过，或者我们知道这些功能曾经被测试过。但事实是，有些功能可能根本就没有被测过；而有些功能曾经被测过，但没有被自动化测试覆盖。同时，我发现后一类问题往往都是在last mile中被引入：在发布之前，为了解决性能问题，我们需要对设计或者实现进行一些大规模的改动；而到后期，测试人员因为功能性需求的结束而退出了团队。当时非常担心大规模的改动会引起一些问题，在发布之后验证了这种担心。这类问题其实是可以尽量避免的：首先，更早开始性能测试和性能优化，以避免在 last mile进行大量改动；其次，last mile可能会出现赶工的情况，有大量功能的改动或者设计的变更，这时候是测试人员最不应该离开团队的时候。

不是问题的问题

客户坚持说，这里有问题。

场景1

客户说：在使用firefox浏览器的回退按钮时，能看到不实时的信息。

场景2

客户说：有一个bug… 过了一会儿，客户又说：bug好像没了。不过，总之问题出现过，你得去修复。

反思

这些不是问题的问题，浪费了维护团队的大量时间。发布之后，维护团队需要及时地修复很多bug，应该尽量地排除不必要的干扰。在一个维护团队中，也需要维护一个流程。我们的维护团队，由两个开发人员和一个测试人员构成。测试人员负责接纳并验证所有的bug，开发人员负责修复bug，再经测试人员测试，最后经由客户验收。通过坚持这个流程，让团队的每个成员，都关心自己最应该关心的问题，而不应该被其它事情干扰。在发布之后，需要更加快速的反馈，而严格地执行流程，能明显地提高团队的效率。

总结

系统在发布之后经历了一段时间的考验，bug不多，并且基本没有出现影响系统使用的bug；同时，维护团队保持了高效的反馈，及时地修复了大部分bug。高质量的代码和快速地反馈得到了客户的认可。

现在回头看这些在发布之后出现的问题，我相信，没有一个系统能确保全部避免。不过从我的反思中可以看到，这类问题大多是开发过程中的“不完美”而遗留下来的隐患，如果能做得更好，我们就可以尽早发现这些问题，以避免这些问题在发布之后才出现。

新博客，新种子

Hu Zhenbo — Sat, 29 Aug 2009 17:27:58 +0000

鉴于blogspot彻底被GFW，下定决心买了托管服务，搭建真正由自己控制的博客。

WebHostingPad，它号称不限空间不限流量。买了之后你会发现空间和流量都有限制，这叫上了贼船下不来了。不过10G空间和每月100G的流量对我来说已经太多了。价格很便宜，推荐购买三年的，每个月1.9美金。使用webhostingtop这个coupon code，可以优惠25美刀，最后只需要付46美刀。

发现WebHostingPad支持Rails，惊喜一下。以后可以在这里很方便的搭建一些实验站点了。

用wordpress作为博客的搭建工具，基本上是一键安装（cPanel这个控制工具很多托管服务商都在用么？）。选了一个博客模板，花了一些时间去掉广告，调整了一下布局，并fix了它的一些bug。但在IE6上显示不正常。强势地制止你使用IE6：http://www.ie6nomore.com/。每个人都应该主动放弃使用IE6，这个世界为IE6浪费的时间和金钱已经远远大于它在现在带来的价值了。

搬到了新博客之后，虽然保持了原有域名，但因为RSS地址不再一致，导致过去订阅的同学不能再看到更新。试图在.htaccess里通过rewrite使老的rss地址重定向到新的rss地址，但无耻地失败了。不想再花时间整这个。以后奔向feedburner去了：http://feeds.feedburner.com/andyhu1007 ，生活从此实现小康~~

感谢webhostingpad救助穷人，感谢wordpress救助懒人，感谢feedburner救助普罗大众，感谢我自己：一个勤劳多金的男人。

”框计算“的“框算计”

Hu Zhenbo — Thu, 20 Aug 2009 17:05:00 +0000

百度在2009百度技术创新技术大会上提出了一个叫做“框计算”的全新概念。

提出两点疑问：

第一个疑问：专注做购物的淘宝都没能让用户一键找到自己想要的商品，凭什么是你百度？专注做游戏的盛大都没有把所有玩家的需求覆盖，凭什么是你百度？

第二个疑问：搜索引擎的精神是开放和自由，给用户最优结果的同时，让用户保有选择的权利。百度如果变成一个路霸或者黑店，谁还愿过你这条路，谁还敢进你这家店？

百度的“框计算”不要最后反而成了“框算计”，算的不是别人，是自己。别让起点，成了终点。

我们都知道我们想要的是什么

Hu Zhenbo — Sun, 02 Aug 2009 06:14:00 +0000

人的内心中总有两股力量在打架。

“我想坐下来认真地看会儿书，但经不起朋友的呼唤就跟着他们腐败去了。”

”我想抛弃无规律的生活，但夜晚的寂寞让我忍不住在酒吧里挥霍自己的青春和身体。“

”我想拒绝朋友的要求，但碍于面子又不得不违心地答应。“

”我想放弃这份不属于我的爱情，但又害怕自己不能适应没有他/她的日子。“

这样的生活状态并不是我们想要的，这使我们经常生活在一种烦躁和空虚中。

你做的都是你”意识“中的事，而”我想“的却存在于你的潜意识中。”意识“和”潜意识“之间的关联出现了问题，这就是心理疾病的根源。

那这些想法为什么会进入”潜意识“，要受到压制呢？它们为什么要受到”意识“的抛弃？

”是因为我们的‘意识’不愿意面对这种情形，不愿承受处理消极情感而带来的痛苦，因而宁可视而不见。“

是的，它背后的根源是人类的恐惧和懒惰的天性。

”人生本来就是苦难重重的“，而不是安逸舒适的。这是《少有人走的路》中我最欣赏的一句话。

我们应该面对那些不舒服和痛苦，逃避的结果只能是更多的不舒服和痛苦。

人的心理成熟过程就是一个痛苦的过程。

很多人都说：我不知道我自己想要什么。其实这句话的真正含义是：我没有勇气和足够的努力去面对和争取我想要的。

—– 《少有人走的路》读后感

南京！南京！

Hu Zhenbo — Tue, 28 Jul 2009 14:06:00 +0000

足迹

火车站夫子庙鼓楼

明孝陵中山陵灵谷寺音乐台

南京长江大桥总统府大屠杀纪念馆夫子庙夜景

瑞金路玄武湖火车站

小吃

回味 — 鸭血粉丝汤

大牌档 — 糖芋苗

我的家私房菜馆 — 炭烧肉

瑞金路 — 南京第一糖蜜藕，樱桃盐水鸭

88，南京

爱人

站在修葺之中的外滩，面对璀璨的陆家嘴，亲吻一下身边的爱人。

简单运动

Hu Zhenbo — Sun, 12 Jul 2009 08:12:00 +0000

跑步一个小时每夜在那个寂寞的小操场享受独处的自由

水中两个小时感受水面上的畅快和水底的压力上帝给自然界最美好的赐予

生活，就是在运动中越来越简单，越来越简单…

AgileChina 2009: Pragmatic Agile

Hu Zhenbo — Thu, 09 Jul 2009 16:31:00 +0000

AgileChina 2009大会官方网站

由在敏捷领域最具有影响力的技术社区InfoQ中文站、敏捷方法论的领导厂商 ThoughtWorks共同主办的敏捷中国技术大会（Agile China 2009），将于9月11日~12日（周五、周六）在北京举行。届时将有超过500人来自电信、金融、互联网、教育等行业在内的高级软件开发人员、项目管理人员等参加。本次大会将特别邀请敏捷宣言缔造者、敏捷编程（XP）方法学创始人Kent Beck，敏捷开发权威人士、敏捷宣言的创始人之一，Dave Thomas，敏捷宣言签署人之一Steve Freeman等国际敏捷领域专家，以及在团队中成功应用敏捷的阿尔卡特、赛门铁克、诺基亚-西门子、华为、腾讯等公司的项目负责人参与此次大会并分享他们的心得。
敏捷中国技术大会（Agile China 2009）是国内敏捷技术领域最高水平的大会，本次大会将由InfoQ中文站负责大会策划、营销和项目实施。InfoQ中文站在今年4月已成功举办了 QCon全球企业开发大会，邀请了国内外30多名讲师，超过550位架构师、技术总监、项目经理和高级工程师参加了本次大会，大会及其运营团队获得了空前的好评，并誉为国内”技术含量最高”的大会。而今年的敏捷中国技术大会，也将一改往年的风格，参会者以高端开发者和技术管理者为主，融合管理和工程实践，推广全面敏捷之路。

会务咨询： 010 – 89880682 agilechina@cn.infoq.com

赞助咨询： 010 – 89880682 sponsor@cn.infoq.com

大石头巷，我不会忘了你

Hu Zhenbo — Wed, 08 Jul 2009 15:58:00 +0000

声音，空气，一草一木，一房一瓦

在踏入你的领地之后，就注定我要爱上你，爱上曾经在这里发生的一切

孙子采花

Hu Zhenbo — Sat, 13 Jun 2009 05:16:00 +0000

庞子要下山，鬼谷子让他进山采花，为他卜卦。

正值花谢时节，庞子进到山里，花儿几近全没。好不容易采到一朵，但那花儿蔫儿模样。庞子弃之再寻，结果再也寻不着。于是回头，捡起原来被舍弃的那朵花。但那花儿因为被弃之路旁已久，已无任何生气。

孙子要下山，鬼谷同样让他进山采花。

孙子出门，见师姐蝉儿身边一水桶中正有一朵花，模样甚好。于是捡之鬼谷卜卦。

读《战国纵横：四子归山》

Hu Zhenbo — Sun, 31 May 2009 15:53:00 +0000

读一本书，如果能得出几点体会，足矣。

1. 商鞅怂恿魏惠王南面称王，招来众诸侯讨伐。秦国趁机收复河西。

2. 魏秦夺天子之女，周王后假病使周握有借口，魏秦终未得意。

3. 魏国败在魏惠王爱听谗言，秦国赢在“借刀杀人”，此刀即为魏大夫陈轸。

4. 商君蒙难，此为天愿。看历朝历代的开国功臣，何不落入如此下场。

5. 鬼谷子收四子。四子虽各为结拜兄弟，但注定将来各为其主。鬼谷子用心良苦。

路很长

Hu Zhenbo — Sat, 25 Apr 2009 18:48:00 +0000

这次Open Party来了很多牛人，如果纯粹从牛人出席数来讲，应该是质量最高的一次了。

不过只听了豆瓣技术总监洪强宁的《豆瓣网技术架构的发展历程》，感到前面的路很长。于是，躲回座位上开始写代码。

嗯，如果对这次活动的内容有兴趣，还是去看他们写的吧：四月北京Openparty小记，Beijing Open Party 活动归来，意外遇到一系列牛人。

一路有感之无名暴走

Hu Zhenbo — Sat, 04 Apr 2009 13:59:00 +0000

今天去第二次暴走，选择远离城市。

心情比上次好，但发现反而不能够那么感性地去看待外界。我还是功利的。

定好的目标被舍弃，选择漫无目的地走。

工厂，回民区，门头沟，一座无名山。我们走过的是别人遗弃的，从未在意过的。

山上一间小石屋，很奇特。能不能来这里生活半个月呢？

很累，回来的车上睡得很香。

就这么一直睡下去，多好。

一路有感之暖春暴走

Hu Zhenbo — Sun, 22 Mar 2009 02:59:00 +0000

天气很好，不冷不热，太阳欲露还羞。

北京的一些角落很美，值得在这几年慢慢走遍。

一条小胡同，就是一个小世界。人与人之间彼此相识，陌生人走过都能引起其他人的注目。而一走出小胡同，外面都是陌生人，人的眼睛是冰凉的。

朋友，还是感动。只要你真诚对别人，你就能听到对方感动的声音。我为什么一年没见你？

教堂 — 安宁，平和，分享，互助，宽容，爱。我是否应该寻找一个这样的港湾？虽然谁都不可能一辈子躲在教堂里。

你爱上的不是她，你只是害怕失去她。爱上生活，才可能爱别人。无论何时，别迷失自己。

胡同，水，建筑 — 破旧的、残缺的、拥挤的、高贵的、现代的，人，教堂。不要让任何人夺去你发现美的时间和眼睛。

一路上的风景比什么都重要，继续走下去。

出发

Hu Zhenbo — Fri, 13 Mar 2009 15:16:00 +0000

虽然工作了这么多年，但还没有在一个正式的项目从头就开始参与的经历。

工作以后的第一个实验项目是在Trilogy University的手机B2C网站，算是从开始就参与，但当时懵懵懂懂，没有太多的感受。后来陆陆续续在Trilogy做了几个项目，都是从半路杀进去。到了TW，做了两个项目，也都是在项目的中途加入。

虽然这也有好处，比如提升了在已有代码基础上如何快速上手，改进既有架构设计等能力。但没有从头开始参与过一个项目，总有种人生不完整的感觉。再优秀的框架，也是别人先搭建好的。从头开始做项目所能经历的事情，比如工具的准备，环境的搭建，架构的设计，需求的摸索，客户的初期沟通等等，都是陌生的。

把一件东西从无到有搭建起来，这不免让我期待这种机会。

这不，它来了。

这次项目的客户是一个旅游网站，本来有机会去澳洲做inception，但因为种种原因没有成行。倒不可惜，因为在项目正式开始之前，我们就忙碌着做准备工作了。说实话，我更庆幸澳洲没有成行，准备工作不失一些很有价值的东西。虽然不见得带来技术能力提升，但至少经历过了。

Web认证方法探视，Git学习，机器安装和环境准备，用Ldap实现Web认证，JRuby，Restlet….

这个过程像是在黑暗中前行，有点担忧，但随着跟客户的沟通、以及准备工作的积极进行，目标正一点点变得清晰。原先拿到proposal时的一头雾水已经消失，心里也越来越踏实。这个过程也有一丝丝的兴奋和成就感，应用什么技术、使用什么框架、搭建怎样的环境，都成了我们可以决定的事情。

下个礼拜项目就要正式开始了，经过几周的准备工作，团队正蓄势待发。出发吧，唱着亡命之徒。

曾经我们的选择

Hu Zhenbo — Sat, 07 Mar 2009 06:00:00 +0000

记得自己曾经也很喜欢说：我不适合、我不喜欢现在干的这一行。但是当别人问我到底喜欢干什么的时候，我常常哑语。

毫不夸张地说，当年之所以选择了计算机专业，纯粹是随大流的心态。不知道现在的高中生在选择自己的大学专业时是抱着怎样的态度。回想当年，我们那些同学选择专业的原则无非如下。

1. 根据分数选专业。这是首要的原则：在分数的基础上，以不浪费一分分数的原则，尽可能上好专业。而什么是好专业？好专业就是大家觉得有前途的专业。那什么是有前途的专业？有前途就是有钱途的专业。而很明显，因为大众的趋之若鹜，那些有钱途的专业往往分数较高。当年的计算机、信息工程、电子信息、金融、外贸、生物科技等专业都是相当的热门。成绩好的同学几乎无一例外地在这些专业上分布。而真正因为自己的兴趣而选择专业的，少之又少。

2. 根据性别选专业。分数之后，开始考虑的就是自己的性别。什么性别适合什么专业，比如男生适合需要动脑的专业，女生适合语言类专业等等。高中同学选择计算机专业的大部分是男生，而选择语言类的大部分是女生，当然有些专业对性别区分不明显，比如医学（除非是护理）。进入大学之后，就更明显地印证了这个原则。理工科专业一般男女生比例都在7：1以上，而语言类专业刚好相反。

3. 根据家庭背景选专业。家庭背景不同，也会影响到你选择什么样的专业。我一高中女同学，家庭条件很好，选择了工商管理专业，不为别的，就是为了毕业后能替父亲打理企业。而大多数家庭条件一般的都基本上选择技术类专业，图个安安稳稳过日子。

当然还有更多的因素影响了我们选择什么样的专业。但是可以明显看到，在这个选择过程中起了更多作用的是社会的意愿，父母的意愿，而很少有我们自己意愿的参与。

我以为的原因有如下几种。

1. 教育体制的弊端。多年以来，我们只是被训练成了解题高手。哪有时间来培养爱好兴趣？哪有谁来关心你喜欢什么，适合什么？所以在选择专业的时候，我们大多只是拿社会上的所谓成功人士做参照系：外贸暴发户，IT新贵、企业家等等。而没法拿自己的爱好做参照系，因为我们“没有其它爱好，只知道解题”。

2. 家庭的受限。在我们这一代，特别如我家乡那种小地方，真正有学问、有文化的父母是很少的。他们基本上没有意识，也没有能力培养、指引下一代。他们更多的教导只是：要挣更多的钱。这也是为什么钱途对我们影响如此之大的原因。

3. 社会环境的影响。在整个社会都开始对金钱顶礼膜拜的时候，我们还有什么更好的选择么？

很多同学，在进入大学之后，由于突然失去了一个目标，突然少了人约束。就像脱缰的野马一样，开始肆无忌惮地堕落下去。这跟自己的约束力有关，但更跟教育体制有关。谁能忍受得住被受限自由、思想、爱好十几年呢？大家都说，这不是我喜欢的专业，但同时我们又都羡慕那些在自己的专业上取得一定成绩的人。有些人说：要是能再一次选择专业就好了。我相信再一次选择专业未必能让他喜欢，背后更多的原因是逃避的心态。

在没有经历过坚持、专注、付出之前，我们都没有能力判断，甚至没有资格说自己到底喜不喜欢自己所在的行业。

最后想说：我越来越喜欢自己的行业，享受所在的工作。

技术写作

Hu Zhenbo — Fri, 20 Feb 2009 15:46:00 +0000

最近写了几篇技术文章。

我写技术文章的主要原因是：对此门技术感兴趣，或者需要在最近了解和掌握此门技术。

我写技术文章的主要目的是：

1. 通过写作来对此门技术加深更多的了解。通过写文章来学习技术是一个非常好的途径，因为当你要将此门技术讲解给别人听的时候，你需要对它有个更深的了解。高中老师一直劝告我们要以老师而不是学生的心态去学习，就是同一个道理。

2. 希望借此途径与共同的爱好者分享以及讨论。

3. 帮助自己记忆。我的一个毛病是容易忘记，所以需要记录下来以备后用。我已经屡次通过实践证明在自己写的文章上能更快地寻回记忆。

需要做哪些准备：当然是了解和熟悉此门技术，不管你用什么途径–阅读或者练习等等。

怎样写技术文章：除非有些非常枯燥抽象的概念，我希望把技术文章写得通俗易懂一些，并通过举一些现实的例子来解释它，使它更易被读者接受和吸收。反观之，如果不能简单明了地说清楚一个问题，说明我自己也还没有很好地掌握。

写技术文章还是挺耗时间的，一般一篇看似较短的文章，比如这篇，也花了我几个小时。不过，当完成此篇文章的时候，确实有一种满足感。有满足感，就够了。

2009愿望：不折腾

Hu Zhenbo — Fri, 23 Jan 2009 10:17:00 +0000

在春节即将到来之际，给2009年许一个愿望：不折腾。

不折腾，一心一意，专心致志。无论是事业，感情，金钱，都希望能有所收获。

真正的收成年到了~~

出租车司机

Hu Zhenbo — Thu, 22 Jan 2009 16:34:00 +0000

这几天在杭州打了几次的士，碰上几个特会牢骚的司机。

一个是个荒谬无知的胖中年男子，估计是在今年股市里面亏空不少。他毫不负责地把所有原因推到了我们党身上，无端指责这是党的又一次“洗劫”行为。他说：“共*产*党就是让你能吃饱，但不能有钱。你吃不饱要闹事，有钱了要民主。吃得饱但没钱让你只能天天埋头苦干而无心其他”。我要说，这种指责纯粹是站不住脚的。

另一个也是中年男子，但显然聪明理智很多。可能是刚刚发生了一起抢劫出租车司机的案子，他车上还放着警局发的警示文件。他拿着那张纸让我看，我没看。他还是继续说：“这个人太傻，几百块钱搞得自己小命没的了。要是我，到香烟店里买几条中华，拿起就跑。一下子几千块，不是很容易？” 说完嘎嘎嘎得笑。我关切地询问他们收入如何。他一脸不屑得说道：“我们就是又苦又累又没钱的人。”当然，他的话语里充满了淫词秽语，为了和谐网络，我这里全部略去。

他们从我坐上车开始一直唠叨唠叨到我下车，即使我一言不发。他们需要的就是发泄，也不管我爱不爱听。这些唠叨的出租车司机都是杭州本地人，操一口“杭普话”，有时候我还听不大懂，特意打断让他们重说一遍。这些出租车司机，有着好好的工作，不错的收入，就是这么爱牢骚。他们确实是个不好管的阶层，看看今年爆发的几次出租车罢工事件，已经说明他们是多么容易冲动的一群人。而特别在杭城这个有钱人遍地皆是的地方，他们很容易产生心理的不平衡。不往自己身上找毛病，还指责我们党，我们政府，多么不应该。看看外地司机，他们显然更能忍耐，一般也不滋事。

出租车司机的矛头大多指向杭州市政府，我真的忍不住要为政府抱下不平：杭州市政府绝对是个体恤民情的政府，遥想当年，政府为了我们杭州大众的面子，霸王硬上了奔驰的士，给你们司机增加了多少就业的机会，给人民带来了多少光彩。而如今，在这个房价节节败退的时节，唯有杭州市政府为了保住我们普通老百姓的资产价值，硬挺咱们杭州的房价。为了这个目的，甚至不惜突破法律条框鼓舞民众对不法房地产商进行合理打击。这都是为了谁？是为了我们老百姓啊，你们这些人，一点都不懂！

做一个好Pair

Hu Zhenbo — Wed, 24 Dec 2008 09:00:00 +0000

在pair的状态下工作了快一年时间，对于pair的好处不想多说。但对于应该如何做一个好的pair倒是感触良多。在结对的环境里面，做一个好的pair已经不仅仅是应该的事情，而是必须的事情了。如果不能做一个好的pair，团队建设、工作效率等都无从谈起。

展现你的缺点

Pair的工作状态下，切实感受到的一点是团队的紧密、互相之间的了解。这是跟以前“单干”时期最大的不同点。对于团队成员的了解，不再仅限于别人的嘴上功夫。

Pair之间最重要的是建立互相之间的信任。达成信任关系之后，放松随意的合作关系反而是我更喜欢的。这可能跟我本身待人处事比较随意有关，但我相信别人的感受也差不多–人都不喜欢在一个压抑的环境下工作。

刚开始跟陌生的pair干活的时候，肯定是有稍许的拘束。就跟两个人刚开始约会时处于相互试探的阶段一样。但往往，这段时间是建立相互认识、相互信任的最佳时期。因为对于别人的印象，在最初定型之后很难改变。

结对编程强调频繁的switch，跟每个pair都建立良好的关系是必须的。从职业的角度来讲，对pair也不应该有什么喜好。但这无碍我对某些pair的喜欢。至今为止，我最喜欢的两个pair，他们都有高超的技术水平。但这不是最重要的，重要的是他们从不以技压人而表现出丝毫的自以为是、不耐烦的情绪。反而我常常在他们身上看到的是耐心和虚心。对于任何问题，无论多么幼稚，他们也能认真仔细地解释；对于任何他们犯的错误，他们也从不拒绝承认和害怕接受。

阿兰说：我们以为别人没有自己身上有的弱点或兴趣，只肯展现自己的力量——结果对话变得索然无味，因为让人产生共鸣的，往往正是我们对弱点的暴露。

同样，只肯展示自己的优点，而不愿暴露自己弱点的pair不是一个好pair，他们会让对方感觉压抑和拘束。反之来看，我们要做一个好pair，就是要不怕出丑，不怕暴露缺点。

说出你的故事

建立相互之间的信任关系之后，就要开始考虑如何提升pair的幸福感了。

在pair时，最怕遇到的是沉闷的人。Pair，需要的是交流，交流！

可能我们都会说，我们是善于交流的人，但事实上呢？

刚开始pair时，我就明显感觉到跟不同的人pair带给你的感受是完全不同的。有些pair让你感觉难于交流，累，你得不停地问，不停地琢磨他们在想什么，甚至过段时间之后，你会完全lost了。而有些pair，他们总能让你知道他们在想什么，他们下一步的目标是什么。显而易见，后者是我们更喜欢的。知道pair在想什么，在做什么是交流的前提。

刚开始这点让我有些不解，因为跟那些交流比较困难的pair，看起来也不缺乏正常的交流。甚至，跟他们会有意地多些主动的交流。慢慢地，我才注意到那些与之交流更加轻松的人有一个共同点：他们喜欢“自言自语”。

每当他们有任何想法时，他们都喜欢把想法表达出来，无论是看着你做正面的交流，还是面对着电脑屏幕边干边说。让对方知道自己在做什么，是所有进一步交流的前提！

一个简单的行为，其实却需要精力的付出。在写代码、思考之余，还要保持一天不停地“说话”，这应该不是件简单的事情，但却是在pair下必须得做的事情。

总之，让我们都开始自言自语吧，如果你在结对。

理解他的不屑

有时候，pair经常问的一个问题是：你为什么要这样做？稍带着怀疑和不屑。

记得这是以前一个同事经常说的话，差点导致了一场同事间肉搏战的爆发。那个“受欺负”的同事跟我说：当然是因为我觉得这么做是对的才这么做，什么叫做‘你为什么要这么做’？

诚然，我们都希望能受到尊重和理解。即使我们做错了，也不愿意看到过分的指责。更不要说那些不明就里、劈头盖脸的“指责”。

我经常也会思考什么人之间适合pair：什么水平，什么脾气，什么性格？确实，那些合作愉快的人之间能更好地相互协调，相互配合。但跟任何一件事情一样，这不是由你的意志、喜好控制的。反而，在工作中我们需要去面对各种各样的pair：陌生的、熟悉的、高水平的、相当的、脾气暴躁的，等等。

那我们需要做什么？我们需要做的是改变自己，让自己学会接受这些不屑，理解这些不屑。至少，在他的不屑背后，是对工作的执着，这是我们共同的目标。

暂且完结。最后，我想说，我还不是一个好pair，但我会努力学着去做一个好pair！

乘时间机器，看敏捷旅程

Hu Zhenbo — Fri, 05 Dec 2008 16:54:00 +0000

BOSCO系统是一个在线品牌管理系统，此项目的客户是一家跨国酒店集团，旗下拥有多个世界著名的酒店品牌。BOSCO系统将服务标准化、标准符合度审查、改进流程管理等酒店品牌管理的工作内容整合到一个信息系统中，来提高相关人员的工作效率。目前BOSCO系统已经被全球十个酒店品牌、超过1000家酒店使用，用户超过8000人。

BOSCO系统的开发基于Ruby On Rails，在项目的开发过程中应用了敏捷开发方法。在开发此系统的8个月中，经历了15个迭代和3次发布。通过这种与客户紧密合作的工作方式我们按时交付了系统，并得到了客户的高度认可。笔者作为开发团队的一员，从开发者的角度对基于Ruby On Rails的敏捷开发实践总结出一些心得体会，其中有成功的经验，也有失败的教训，愿与敏捷开发爱好者分享。

在我们的系统中，有一个有趣的类，叫做TimeMachine，用于修改UAT服务器的系统时间。但现在，让它带我们穿梭时空吧。

TimeMachine.go_to(”2008-04-15″)

半路接手关键字：Knowledge Transfer，结对编程

2008年4月，BOSCO系统漂洋过海来到中国。此时，它已经在美国经过了3个月的开发，且完成了第一次发布。现在要开始它的移植过程（从美国团队的大脑移植到中国团队的大脑）。给我们的资源并不多，只有3个项目原有工作人员：一个BA(业务分析师)，两个Dev(开发人员)。但时间却相当有限：一个月。

虽然BOSCO系统的开发时间并不长，但Rails强大的表现力使系统已经足够庞大到让我们担忧Knowledge Transfer能否在约定的时间内完成。而且中国的开发团队中，真正有Rails开发经验的只有一人。如何在这么短的时间内，掌握这么庞大的系统，成了摆在眼前的挑战。

我想很多遇到过此种情况的开发人员都不会对以下几种经历感到陌生：

阅读大量关于系统原理和项目架构的文档，但它们并不能直观、准确地反应项目情况。
参加各种标榜着“Knowledge Transfer”且耗时长久的会议，但收益甚少。
独自面对系统时不知从何下手，不断地寻求原有开发人员的帮助。
由于不熟悉系统造成在开发过程中不断犯错，贡献了很多“垃圾”代码，并影响了系统开发进度。

其实对于开发人员而言，掌握一个项目最重要的是提升对项目本身的“熟悉度”。此熟悉度代表对陌生的技术知识，代码的编写风格，开发的习惯，程序的架构，环境的搭建等等的掌握和了解。而结对编程是快速掌握这些知识技能的秘诀，还是拿事实来说话吧。

两个礼拜之后，作为先行和两个美国Dev结对的同事已经能够带新人了，而且开发速度不亚于两个美国 Dev。短短两个礼拜，中国团队对项目的整体架构，不说了然于心，但也是熟门熟路了；对于一些story，也能得心应手开始实现了。这是我们自己也预想不到的速度。

之所以能在如此短的时间内掌握项目，就是拜“结对编程”所带来的好处所赐。有人会说，结对编程到底有什么魔法？其实没有魔法，它只是简单地实践了很多人都懂得的道理：学习一件东西最快速的手段就是动手去做。而结对编程，不仅能让你有立即动手去做的机会，而且边上还有个让你观察学习、给你指导的老师。这是我对结对编程的初次体验，让我非常兴奋。还记得一个朋友给我电话告诉我“项目中的新人不能快速掌握知识的问题”时，我告诉他：不要犹豫了，结对编程吧。

结对编程在ThoughtWorks是一种常态，它作为敏捷开发中一项备受推崇的实践也已经被业界所熟知。但真正开始实施的公司并不多，这是一种奇怪的现象，但同时也是可以理解的现实。首先是因为未有机会体验结对编程美妙的开发团队或许还有所疑虑，其次是来自老板、客户等非开发人员的压力。 Knowledge Transfer作为每个团队都可能会经历的事情，不失为开始尝试结对编程的好时机。我相信，一当你开始尝试，你就不愿意停止。

TimeMachine.go_to(”2008-05-15″)

加速前进关键字：最佳实践

随着Knowledge Transfer期满、美国同事离去，客户一度很担心中国团队能否掌控项目，能否保持开发速度。但在快速接手项目之后，项目开发随即进入了加速通道。在完全接手项目的第一个迭代之后，中国团队已经赶上了美国同事的开发速度。在这个过程中，除了因为团队的快速学习能力之外，还有我们保持的一些最佳实践让我们赢得了胜利。下面，让我简单介绍其中一些。

一致的开发机器：我们有6个开发人员，也就是3对pair。Pair的3台机器都是漂亮精致的Mac Mini。当然这不是重点，重点在于，3台机器都有一致的开发环境：一致的程序目录，一致的安装软件，一致的快捷命令等等。完全一模一样的配置使pair 在进行切换时，不会对另外一台机器感到丝毫的陌生，这有助于开发人员迅速进入开发状态。

快捷化常用命令：在开发时，我们每天都要进行无数次相同的一些操作：进入rails开发根目录，启动web server，签入代码等等。比如当你要进入rails开发目录，你就得打入命令：cd /Users/rails/workspace/bosco/rails_root。这是一个简单的命令，但同时也是一个繁琐的命令，特别是当我们每天要进行多次这样的操作时，就会浪费大量的时间。这时，如果你为它加一个alias，把这个枯燥的操作用一个简单的命令”rr”代替，它会帮你节省多少时间呢？效率的提升有时就在于一些简单的事情。

不做简单重复的劳动：每天的工作总会有一些事情需要简单重复的劳动。比如当你要验证一项功能时，你需要手工打开网页，然后按着流程一步一步操作，来看实现是否正确等。而每当此时，我们的选择是：绝不做简单重复的劳动，而是实现一个自动化的脚本来帮助我们进行这些操作。自动化不同的任务，可以选择不同的工具，比如selenium，ruby，shell等等。后来我在《The Productive Programmer》中读到Neal Ford大师如是说：“手工执行简单重复的任务会让你变傻，会消耗你的注意力，而注意力是最重要的生产力之源。找出一种聪明的方法来自动化这些任务，这会让你变得聪明，因为你能从中学到一些东西。”

每天早上的code diff：在早晨的站立会议结束后，我们并没有马上着手清扫story。所有开发人员会挤在一台机器前，查看前一天的code diff。大家会看到所有成员在前一天的工作中修改的代码，相关的开发人员会对自己的代码作出解释。当有人对一段修改有疑问时，我们就会对此段代码进行讨论。或者是实现上的一些逻辑漏洞，或者是一些不规范的代码编写，或者是一些可能的性能改进，我们总能对一些代码提出疑问，并提出改进意见。Code diff过程是对站立会议以及结对编程的补充，是对代码质量的进一步检验，有助于团队对代码的了解，也促进了代码质量的提升。短短十分钟，何乐而不为？

每周的技术session：每周的技术session是我们一直保持的良好传统，团队从中受益匪浅。项目中总会遇到一些难题，或许是一种陌生的技术，或许是一个难解的问题。而此时，总会有人站出来说：“让我来讲讲这个吧”。或许这项技术对于主持者也是完全陌生的，但不要紧，接下来一周紧张的学习已经足够（这也会促使他更加快速地学习）。一周之后，主持者就为我们带来了一道“丰盛的大餐”。在session中，团队成员都会踊跃发言，并乐于抛出任何疑问让大家讨论。讨论是最能产生火花的，来自每个人不同的思考会让你对问题了解得更加深刻。讨论帮助我们解开了一些困扰已久的疑问，并加深了对一些技术的理解，比如：CSS，Memory Cache, REST, Ajax，Ruby的对象模型等等。通过技术的讨论和学习，团队成员的整体开发能力得到了提升，这极大地促进了项目的开发速度。

团队需要勇于尝试一些实践来促进团队的开发效率和提升团队的整体能力。上面所提及的有些实践都是我们在平时的工作中摸索、体会和总结出来的。比如每周的技术session，就是在成功地开展了一次之后，被保留和坚持下来了。

如何发现一些值得尝试的实践？这看似很难，其实很简单。在项目中遇到的问题，工作中偶然发现的一些事情，别人的经验，或者是你自己的一些想法，都可能是对一项实践的启发。你唯一要做的，就是勇于尝试。“从来没有人这么做过”，或者“别人都不这么做”不是你不能这么做的理由。

TimeMachine.go_to(”2008-08-01″)

挑战难题

当项目开发进入第5个月，我们遇到了一些真正的困难，它们分别是“历史”story和系统性能优化问题。

当项目遇到困难时，正是审视敏捷实践的最好机会。TDD，简单设计，持续集成，重构等等，让我们看看这些实践在项目开发中显现的力量吧。

笑看历史关键字：简单设计，TDD（测试驱动设计）

历史story：作为全球质量管理员我要查看一个酒店的标准审查历史记录从而跟踪并比较酒店在各个时期的标准符合度。

简单分解一下这个Story，它要求提供的功能是：

系统在一些比如标准变化，酒店审核等事件发生时能保存当时的数据
系统应该提供一个界面，让用户通过选择特定的日期查看历史信息。

跟通常一样，我们经过estimation（当时估的是5个points，并不太大），以及tasking（简单的设计）之后，并开始实现这个story。

刚开始，这个story如预期一样顺利地开发下去了。一天，两天，到了第三天，我们突然发现在实现一些功能时有点举步维艰。但通过一些“邪恶”的手段，我们还是解决了那些问题，虽然觉得那样的实现并不是最佳实现。到了第四天，在实现另一些功能时，我们陷入了绝境：实现的过于复杂让代码改动极其困难，通过了这边的测试，那边的测试就失败了，如此反复。还差两天迭代就要结束了，这个story却深陷泥沼，团队陷入担忧之中。这时，正如团队一成员所说，忍无可忍，让我们重新跳出来看一下原来的设计吧。

基于实现中遇到的困难，我们讨论了原先的设计，发现了其中的一些缺陷，并迅速找到了一个更好的设计。新设计雏形初具，再次动手吧。改动代码，很多原先的测试应声失败了。好事情，失败的测试告诉我们哪里出了问题，过去修正那些失败的测试吧。红，绿，红，绿，按照这样的节奏，出乎所有人意料的事情发生了：一个下午，仅仅是一个下午，我们把历史story完成了！

因为这个设计并不在技术层面，而在业务层面，所以在这里我并不想多讲story的详情。但发生这样的问题，是否会让你怀疑敏捷实践“简单设计”呢？如果你有此怀疑，我的想法就正好跟你相反，因为通过这个story让我更加相信“简单设计”的好处。

首先，即使现在回头看，我们还是认为就算当初花几倍的时间去做设计，也难免犯同样的错误。其次，检验设计优劣的最佳工具就是代码本身，及早地应用设计于代码，让代码来告诉你设计正确与否。这正是在这个story陷入泥沼时我们的反应：实现不能继续，来看看设计的问题吧。再次，之后我们的设计之所以如此成功地符合了业务的需求，是因为前一次失败的经历让我们对代码有了更进一步的了解，对问题有了更清晰的洞察。谜团是在行进中解开的，并不是一开始就能知晓。最后，我想我们唯一应该改进的，就是在发现开发出现困难时，能更早地跳出来，从设计角度分析一下问题。

新的设计实现能在一个下午完成，是因为高测试覆盖率为正确的重构实施提供了安全保障。测试总能迅速地提醒我们哪些地方出了错，以保证重构的正确。其次，良好的代码结构，也是代码能如此快速地修改完成的原因。这些都是TDD开发带来的好处，TDD开发不仅能提供高测试覆盖率，也能带来良好的代码设计。这就是越来越多的人把TDD称之为测试驱动设计（Test-Driven Design）的原因。

TDD给设计带来的一些好处：

TDD迫使你在编写代码之前，考虑更多对象之间的交互。
TDD迫使你把对象的创建封装在一个更好的层次上。
TDD会让你写出更加小而内聚的方法，从而使方法的重用以及纠错变得更加方便、快速。

百倍加速关键字：性能，重构，YAGNI

随着项目进入后期，功能的开发已经基本完成。此时，我们面临的是系统的性能问题：发布一个标准竟然要5个小时，这是不能忍受的。由于发布标准需要在一个事务内完成，而且它需要修改大量数据。所以在这5个小时内，数据库的很多表都被锁定，系统几乎处于瘫痪状态。于是，顶着巨大的压力，我们开始了性能优化之旅。

先通过添加日志找出最耗时的操作，然后仔细地跟踪和分析这块代码。我们随即发现了一个需时十分钟的操作，这个方法的时间复杂度是n²。但这段代码犯了一个低级错误，它可以被优化成一个n复杂度的方法。立即修改，修改后由于消除了大量重复操作，它的耗时竟然不超过一秒。“秒杀十分钟”就这样诞生了。随着我们进一步的跟踪和分析，多处设计上的问题暴露出来了。几天的改进之后， 5个小时的操作缩减到了1个小时。

但显然，一个小时的操作还是不能为客户所接受的。于是，继续优化。马上，我们就发现标准发布操作对很多标准都进行了重新算分，但实际上只需对有改动的标准算分即可。而没有改动的标准，可以把它的得分结果存于数据库，下次用到时从数据库读取即可。通过这个“缓存”，我们再次大大得提升了速度。运行之，整个操作竟然只需5分钟！5个小时的操作，到现在的5分钟，百倍加速也！

这个性能优化问题是个典型的案例，它给了我们很多启示。首先，在遇到性能问题时，先别忙着埋怨平台的速度，还是先看看设计里面存在的问题吧。其次，也是我们可以改进的一点是：在TDD“红-绿-重构”的标准开发节奏中，如果我们多花一点时间在“绿”之后进行重构，就可以避免犯一些低级错误。

或许有人会说，如果你在刚开始就做更多的设计就能避免到最后出现这样的性能问题。但我想说，非也，你忘了：你将不需要它（YAGNI）。预想开发是个迷人的陷阱，或许可以在刚开始就花费十倍的时间去避免这个性能问题的产生。但问题时，在刚开始你怎么知道哪些是必要的设计，而哪些是浪费呢？敏捷团队注重的是给客户创造真正有价值的业务，而不是花费大量时间去制造一个“华而不实”的系统。

“只在确实需要时才提供功能”，这是我们遵循的准则。

最后，性能改进之所以如此顺利，得益于我们遵循的一些敏捷实践。比如TDD带来的高测试覆盖率，保证了重构的正确性。在BOSCO项目的开发中，不乏这样的大型重构，我们从不害怕修改代码，因为有坚实的测试代码为重构撑起了安全网。而反之，重构促进了代码结构的优化，提升了系统性能。

从这两个问题我们可以看到：

敏捷实践促进了系统设计的灵活，代码结构的优化，系统质量的提升。
各项敏捷实践之间其实是相辅相成，相互促进的。

BOSCO脚印

说了这么多，让我们来看看BOSCO系统的真实代码状态吧。

+————+——-+——-+———+———+—–+——-+

+————+——-+——-+———+———+—–+——-+

| Controllers| 1923 | 1602 | 35 | 232 | 6 | 4 |

| Helpers | 1451 | 1210 | 8 | 206 | 25 | 3 |

| Models | 4332 | 3551 | 63 | 566 | 8 | 4 |

| Libraries | 2810 | 2337 | 37 | 237 | 6 | 7 |

+————+——-+——-+———+———+—–+——-+

| Total | 10516 | 8700 | 143 | 1241 | 8 | 4.5 |

+————+——-+——-+———+———+—–+——-+

Code LOC: 8700 Test LOC: 12962 Code to Test Ratio: 1:1.5

（注：由于rake stats对rspec的统计失准，故略去。对于测试代码的总量统计，可见Test LOC。同时，rake stats只统计ruby代码，而不包含html，javascript等其它代码。）

另外，从四月到九月的5个月中，共提交代码2400次。

我们可以从以上数据看到：

代码设计的优良：平均每个类不超过十个方法，每个方法不超过五行代码。如果除去特殊的Helpers模块，平均每个类不超过7个方法。
高测试覆盖率：测试代码与功能代码的比例是1.5:1，行覆盖率达到90%以上。
开发人员的熟练度：每对pair每天6次的提交速度足以证明开发团队对于系统的熟悉度。

另外，考虑到Ruby On Rails作为特别擅长开发Web应用的框架所具备的强大表现力，我们相信此系统的复杂度不亚于很多规模在十多万行代码的系统。

TimeMachine.go_to(”2008-09-17″)

时间定格在BOSCO项目第三次发布的那一天。除了需要一段时间的bug修复和数据准备之外，发布并没有给工作带来太多不同。我们从未因为发布的到来而惊慌，也从未在发布时忙得不可开交。正如团队一成员所说，每次我们都是在等待发布，安静地等待着发布的到来。因为合理的安排和控制，让一切尽在掌握中。

发布成功，欢呼之余，让我们回头看看项目中的哪些实践保障了发布的顺利完成吧。

客户协作关键字：PM、BA，还有Dev

曾经有一个同事突发感想说：“在ThoughtWorks做程序员是幸福的”。这不禁让我有很多感触，是的，在ThoughtWorks做程序开发是一件幸福的事情。当你有任何关于业务逻辑上的疑问时，坐在身旁、招之即来的BA总能给你准确地解答；当你坐着投入地进行开发时，可能你从未想过，之所以有这么良好的环境，是因为PM帮你阻挡了一切不该有的干扰。

PM和BA在背后付出的需求分析、客户交流等工作，让开发人员能把大多数时间和精力花在编码上。

BA在每天的站立会议之后，会有一个跟客户之间的BA站立会议。在这个会议上，他们会讨论各个业务的细节，力保每个业务细节的正确性。正是业务的正确性，让每天的开发工作能顺利进行。

PM每天会用很多时间跟客户交流项目进度，确保客户了解项目状态。并在每天工作结束之后总结一封报告邮件，这封邮件包含了对一天工作的总结，各个story的进度情况等。通过这封邮件，客户能及时地了解进度情况。

那Dev能在客户协作方面贡献什么呢？有人觉得，开发人员的任务就是从BA那里拿到story，并严格按照需求开发，而无需做与客户协作沟通等工作。其实这并不准确，Dev完全可以在客户协作方面发挥自己的作用，因为对于整个系统架构的了解，Dev有时候比BA，甚至比客户自己还了解他们真正需要的是什么。当我们拿到需求时，我们可以从开发者，以及整体系统架构设计者的角度考虑一下需求的可行性、必要性。有时我们会直觉有些需求并不是客户真正想要的，或者我们可以通过另外更简单的方式给客户提供同样的功能。经过一些分析，以及跟BA的讨论之后，BA通常会接受我们的观点并与客户进一步讨论。在这个过程中，Dev起到了帮助客户认清真正需求的作用。这是一个双赢的结局，开发人员不需要为一些无必要的功能而增加不必要的工作，影响架构的稳定性；同时，客户可以不必为一些价值不高，甚至没有价值的功能而付出昂贵的代价。

所以，客户协作并不只是PM和BA的工作，Dev作为系统的开发者，应该从他们的角度帮助客户找到对客户真正有价值的业务。

同时，信任，是客户协作的基础。团队与客户之间只有真正信任了，才能更好地合作。我们和客户之间的相处，就如朋友，在平时的工作中甚至会经常拿对方开开玩笑。

团队合作关键字：Retrospective，Feedback，持续改进

大家都说，这是我们呆过最开心的一个团队，因为从不缺少欢声笑语。而我觉得，这更是一个正直的团队。无论谁有优异的表现，我们从不吝啬赞扬；无论谁犯错时，我们也会毫不犹豫地指出。

每两周一次的retrospective提供了一个寻找团队问题的好机会，在每次的回顾反省中，我们都会找出一些项目中的问题，并在接下来的工作中给予改进。这样团队才能保持持续的进步。

有人会问，为什么在我们的团队中就不能保持这样良好的气氛，无法保持正直的态度呢？究其深层次的原因，首先需要公司的制度让团队的成员处于平等的地位，不应该有谁是在“管理”谁。PM，BA，Dev之所以需要不同的职位，只是因为工作类别不同而已。PM负责管理客户期望，BA负责需求分析，而Dev 负责的是项目实现。

其次，团队作为一个整体，不应为任何问题追究到个人，而应把它归为团队集体的责任。

平等的地位和责任集体所有制，会让每个成员更具主人翁精神，也会让团队更加紧密地凝聚在一起。

团队成员的相互信任和紧密合作是项目成功的根基。

TimeMachine.go_to(“Future”)

敏捷方法并没有高深的理论，有的只是一些简单的实践。正是这些简单的实践，提升了开发人员的效率，促进了项目质量的提升，保证了项目最后的成功。

在未来的路上，让我们一起寻找更好的敏捷实践吧。

– 发表于《程序员》杂志2008年11月刊。

我们为什么没有文档？

Hu Zhenbo — Fri, 21 Nov 2008 13:54:00 +0000

当我这么问自己的时候，我的第一反应是：在什么时候我们需要过文档呢？

如果想初步了解系统架构，就让熟悉此系统的同事花上半个小时解释一下。

如果想理解熟悉系统架构，就动手去做，跟着pair边干边学吧。动手去做永远是掌握未知事物的最快手段。

如果你说代码需要注释，代码需要注释除了特殊情况之外唯一的原因是代码看不懂。看不懂的代码能是好代码么？

我们何时需要过一大堆无趣枯燥、咬文嚼字、生涩难懂的文档呢？没有。

当你还心存质疑之时，我想反问的是：你真的喜欢大量的文档么？

花大量时间去编写、更新、维护的文档，你有多少机会需要阅读呢？

代码即设计，你却为它制作一份形式不同且极不直观的多余拷贝，难道不是一种巨大的浪费么？

交流、动手、以及优美的代码，让文档不再需要。这就是我们没有文档的原因。

做一个“不偷懒”的程序员

Hu Zhenbo — Wed, 12 Nov 2008 13:43:00 +0000

曾记得有一次我在调试一段程序（我说的调试是通过添加log来跟踪），一个诡异的现象出现了：在调用aMethod()方法前变量iAmVariable的值为1，这个变量作为aMethod()的参数，调用aMethod()方法后，它的值变成了2。但我是在这个方法的最开始（既没有对参数做任何修改前）输出的log。这条log是这样的：“value: 2”。百思不得其解之时，找来了同事帮忙。同事看了一会儿，往我的log里面添加了一连串的字符。现在，输出log的语句变成这样了：LOG.info(“In aMethod, the value of iAmVariable is: ” + iAmVariable); 再运行，log里面的值确实是我希望的。我也终于恍然大悟，因为添加了太多的log，并且多数log输出的字样相似，刚才那句我以为在aMethod()内输出的log其实是另外一处的log。

我想很多人都碰到过类似“诡异”的情况，起初看似诡异，过后“恍然大悟”。而这种“诡异”多数是由于程序员为了一时偷懒做一些不规范的操作引起的。

都说“懒惰”是程序员的三大美德之一，但我越来越意识到“不偷懒”和规范操作对于程序员的重要性。下面说说几种往往偷懒不得的地方吧。

1. 首先就是上面例子中提及的，在程序员利用log或者如javascript中的alert来调试程序时，添加有意义并且正确的log。调试程序时log或者alert语句所输出的可见的信息对于程序员正确跟踪是极其重要的，否则就会常犯如我那样的错误。或许你会说，我仅添加一条log或者只有一句alert，肯定知道出现的就是它，有何关系？没错，但事实是一当你进行调试，你就会添加第二条，第三条log，log一多，混淆的可能性就增加了。所以，在添加第一条log时，就不要偷懒。

2. 添加“有意义”的测试数据。在我们的测试程序中，经常见到如“I’m a very very very very long name”或者carWithOutWheel等数据或者变量名称。前者可能是用于测试页面在显示一个很长的名字时是否会出现错乱，后者代表一个Car类的变量，且此汽车没有轮子。一目了然。测试程序是最准确，并且可编译运行的文档。在编写测试程序时，为变量，数值赋予一些有意义的名称或可读并与测试场景相关的数据无论是对于阅读还是以后再次进行修改的人，都带来了极大的方便。

3. 测试先行，小步快走，按部就班。写程序时，我们有时会发现自己写着写着写糊涂了，这种情况对于不按部就班遵循步骤的程序员是经常发生的情况。写程序一定要遵循测试先行，小步快走的原则。关于这个原则的好处，不再多说。并且在做一个story时，要有计划地逐步完成。可以事先在卡片上写下todo list，严格按照list一步一步往下走。最忌的是第一步还没做完，发现有个地方可以顺手把第二步的东西做了，就顺手一把吧。但一顺手，发现第二步远没有想的那么简单。继续做下去，你又把第一步的忘了。顺手一多，就完全乱了套。

4. 第一次就要使用快捷键。使用编辑器的快捷键对于生产效率的提高是明显的，但其实很多程序员对于编辑器的大多数快捷键并不熟悉。原因就在于，他们没有在第一次操作时就去查找相应的快捷键。比如，删除一行这个操作，在很多编辑器下使用的快捷键是“ctr y”。很多程序员认为不用快捷键，删除起来好像也不太费时间。而且，查找，记住快捷键是个挺“麻烦”的事情。于是，你永远都不知道“ctr y”这个快捷键能为你省去选择一行，删除一行，回退一行这三步费时费力的操作。一天中，我们不知道要进行多少次删除操作，使用快捷键累积起来为我们节省的时间无可计算。

上面提及的例子中，很多都是由于程序员的一时偷懒，造成了“诡异事件”，混乱状态，以及低下的生产效率。让我们都做一个“不偷懒”的程序员吧。好程序员从规范操作开始！

翻译这事儿

Hu Zhenbo — Thu, 30 Oct 2008 15:14:00 +0000

在团队的合作之下，终于完成了《The Productive Programmer》的翻译，值得庆祝一下。从开始到完成，经历了几个月的时间。对于我个人来讲，也投入了多个周末以及晚上的时间，甚至几次通宵达旦，这是个挺辛苦的过程。翻译完成，如释重负。

谈谈翻译这事儿。

首先当然得具备一定的英文能力，只有真正理解了作者的意图，才能进行正确的翻译。这是前提。

其次，也是没有翻译经验的人很大的一个误解，其实翻译更加需要的不是英文，而是优秀的中文能力。平白直叙，不追求质量的翻译当然很简单。但既要准确地翻译出作者的意图，又要生动地用中文表达出来，这不是件容易的事儿。我对翻译的每一章都经过了至少三个流程：1. 翻译成中文，2. 翻译完成一段之后再重新阅读整段文字，看是否通顺，并进行修改。3. 翻译完成一章之后，再次通读，使整章文字保持节奏的统一。但实际中，经过的流程更加繁多。10页的章节，往往得花费几个晚上的时间搞定，就很能说明问题了。翻译完成整本书之后，还需要再次通读全书，以统一所有名词，并再次确认所有章节是否保持统一的“调子”。

最后，也是翻译中最关键的一点，我想，是责任心。我在想，是什么让我不厌其烦反复地在推敲一段文字，一个句子，甚至是一个名词或者动词的使用？是责任心。只要有责任心，我们就能翻译出高质量的书。

翻译是个耗时耗力耗脑的过程，可以说有点“痛苦”。但真的非常庆幸能有这么一段经历，不仅锻炼了我的耐力，也让我的中文能力有了很大的提高。谢谢一起合作的所有同事们，特别是熊节。我想，熊节之所以能翻译出这么多好书，最重要的是他的负责任心态！

再次强烈推荐这本书，在我的博客中有很多《The Productive Programmer》优秀章节的摘抄，这确实是一本让我惊叹的好书。翻译，需要比阅读花费不低于数量级的时间，这也让我有机会反复琢磨书中的要领，学到不少非常有价值的东西。

Leary’s Rose

Hu Zhenbo — Sun, 19 Oct 2008 16:43:00 +0000

Leary’s Rose is a model to map the relationship between people.

For example:

people’s_instinctive_reaction => { :competitive => :withdraw, :aggressive => :defiant },

what_should_be => { :competitive => :leading, :aggressive => :helping}.

Frustrated = Growing Up

Hu Zhenbo — Sun, 19 Oct 2008 16:02:00 +0000

You feel frustrated after you spent 1 whole day solving a problem but still no clue yet.

You feel frustrated after you spent months to practice your skills but seems no change happened at all.

So, you give up….

But someone continues. When they look back after several years, the frustrated period is just the period of growth. Love being frustrated!

Assumptions Kill You

Hu Zhenbo — Sun, 19 Oct 2008 15:45:00 +0000

You want to open the window in the office when the hot air makes you uncomfortable, but at last you give up because you assumes others don’t like it.

You feel nervous when you give the presentation, because you assumes the audiences have no interest on your talk.

You miss a relationship with love, because you assumes she doesn’t have any feeling about you.

These assumptions kill you! Be assertive, you life will be completely different.

Strawood Footprint

Hu Zhenbo — Fri, 12 Sep 2008 15:50:00 +0000

Project：starwood

Time period：April – 12th Sep

Team members：

SVN info:
revision: 4161 (start from nearly 1800 on April for Chinese team)

Rake stats:

+———————-+——-+——-+———+———+—–+——-+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+———————-+——-+——-+———+———+—–+——-+
| Total | 25806 | 21376 | 145 | 1243 | 8 | 4.5 |
+———————-+——-+——-+———+———+—–+——-+
Code LOC: 8602 Test LOC: 12774 Code to Test Ratio: 1:1.5

Next station:
E&P

Composed Method and SLAP

Hu Zhenbo — Sat, 06 Sep 2008 07:07:00 +0000

Composed Method mandates that all public methods read like an outline of the steps to perform. The actual steps are implemented as private methods. Composed method is a way of factoring your code to keep it cohesive and make it easier to spot candidates for code reuse. And TDD predisposes composed method.

SLAP insists that all your code within a method live at the same level of abstraction. In other words, you shouldn’t have a method in which part of it deals with low-level database connectivity, another part with high-level business code, and another with web service plumbing.

YAGNI

Hu Zhenbo — Wed, 27 Aug 2008 15:16:00 +0000

YAGNI stands for “You Ain’t Gonna Need It.” It is the battle cry of agile project development to help prevent speculative development.

预想开发是个迷人的陷阱，在编码时时刻提醒自己：它究竟是会让代码变得更好，还是平添复杂度？出自预想的框架，如EJB和JSF，都是过度工程的典范。最好的框架是从可工作的应用程序中抽离出来的，比如ROR，它的累赘是如此之少。

软件开发人员应保持与用户或者Business Analyst之间通畅的交流。大部分时候，用户和业务分析师对于软件功能有自己的想法，我们应该尽量抓住这些功能的核心和本质，然后看看有没有更简单的解决方案。如果没有通畅的沟通渠道，贪婪的用户和沉默的软件开发人员之间就会重蹈“大船瓦沙”的覆辙。记住，软件开发首先是一场沟通的游戏。

——- 《The Productive Programmer》

Secret Of Training

Hu Zhenbo — Mon, 25 Aug 2008 14:53:00 +0000

昨天参加培训时，有一个环节两个同事扮演了一个小游戏：一个同事向另一个欠钱的同事要求还钱。这是一个练习如何果敢地说出自己要求的游戏，虽然一切都是假的，但明显地感觉到“讨钱的人”着实有点紧张。我说：“这对中国人来说是一件为难的事情”。老师说：“不仅仅对中国人，其他地方的人也一样”。想到平时遇到此事时的窘境，我就向老师提出能不能表演一下她在遇到此事时是怎么做的，好让我们学习学习。老师当即说道：“我没法演示给你们怎么去做一件事情，我只能提供一个环境让你们自己去感受。”这时，边上的同事说道：“Secret of training.”

就如上一篇博客讲的，没有经过亲身体验、亲自practice，我们永远无法真正理解一件事情。

总体来说，昨天的老师水平还不错，毕竟有25年training的经验。但感觉跟ThoughtWorks University或者ThoughtWorks Immersion的培训师比较，差得挺远，特别是在调动气氛方面（突然相信这些课程培训开始对外服务之后，肯定会大受欢迎）。这让我想起在TWI的第一天，面对一大群来自全球各地但是互不相识的陌生同事，着实不知如何开始打交道时，trainer的一个游戏就让我们打消了彼此的顾虑，心理防线在笑声中瞬时融化。刚仔细看了一遍好学的小初同学写的：ThoughtWorks University取经记（发表于程序员杂志），让我顿时回忆起那段开心的日子。

Respect

Hu Zhenbo — Sun, 24 Aug 2008 14:17:00 +0000

今天参加了一个培训，training讲解了两部分内容。

第一部分是如何assertive：用中文解释，就是如何才能做到不卑（subassertive）不亢（aggresive），恰到好处地对待人和事，既能勇敢地表达自己的想法，也能让别人感觉到你的尊重。

第二部分是如何给feedback：其实人本身不需要别人告诉你怎么做，任何聪明人只要听到别人的想法就会知道采取怎样的行动；如果你想让别人更好地接受你的意见，就不要自作主张指手画脚，也不需要你告诉别人怎么做，这样只会增加对方的抵触心理。正确的方式是IIU：告诉对方你所看到/听到的（I），告诉对方这么做让你产生的感觉/对你的影响（I），然后听听对方对此事的认识和理解（U）。一般来说，至此以足矣。聪明人知道接下来该怎么做了。

最有意思的是其中的一个practice环节。李总，wpc和我在一个假设的特定situation下给trainer扮演的customer feedback。当阐述到U之后，我们不约而同地等待trainer告诉我们她会采取怎样的行动来弥补她的错失，但trainer扮演的 customer毫无动静。然后，我们都沉不住气了：提出了自己的要求（基于愤怒的要求），当然，最终招致了customer的拒绝。当我们都以为理解了其中意思，甚至在看到别人如何在practice中犯错之后，却再次在practice中接连犯错。说明什么？说明我们刚开始就是带着责备的态度和愤怒的心情去“审问”对方，虽然刚开始都follow了正确的方式，但是当我们都没有等待到customer主动的认错时，我们愤怒了。练习到feedback 环节时，我们忘了如何assertive，忘记了respect。

自信来自于respect，对别人的尊重为你自己赢得了尊重；正确地give feedback，也先学会respect别人吧，尊重别人才会赢得别人的理解。

期待下一次关于listening和empathy（换位思考）的training。

多语言编程

Hu Zhenbo — Thu, 21 Aug 2008 13:27:00 +0000

Java语言创建者当初由于“让Java能够向后兼容如c这样的语言”等原因，给Java语言带来了很多包袱（如数组从0开始，以及令人费解的初始化顺序等）。幸运的是，他们同时也创建了Java平台。如今Java越来越多得被作为平台来使用，这种趋势将会在未来几年中成为主流。

相较于通用语言，Groovy、Ruby这样的动态语言迅速地提升了程序员的生产力；无状态的函数式语言（如Haskell, OCaml, Erlang, SML）让编写线程安全的程序更加容易；DSL让日益困难的问题域得到解决。拥抱多语言编程吧！几年之后，软件开发将大不相同。

——-《The Productive Programmer》

被激怒的猴子

Hu Zhenbo — Sat, 16 Aug 2008 16:19:00 +0000

“我们一直都是这么做的”或者“大家都说它应该是这样的”，都不足以成为一件事之所以该这么做的理由。固守标准跟没有标准一样糟糕，有时候标准反而限制了一些有价值的变通。

很多人在听到“异类”思想的时候，就会像“被激怒的猴子”一样。其实我们应该保持质疑权威、质疑圣牛、质疑自己偏好的习惯。

——– 《The Productive Programmer》

Anti Patterns Catalog

Hu Zhenbo — Wed, 13 Aug 2008 16:31:00 +0000

“Catalog” is a technical term in the PatternCommunity: a list of patterns is called a catalog. This catalog lists AntiPatterns.

Dietzler定律和DSL

Hu Zhenbo — Wed, 13 Aug 2008 16:25:00 +0000

Dietzler定律说的是：80% 的客户需求可以很快完成；下一个10% 需要花很大的努力才能完成；而最后的10% 却几乎是不可能完成的，因为你不能把所有的工具和框架都“招致麾下”。

强大的语言加上特定领域元层次提供了目前最好的解决方案。

生产率来自DS L跟问题域的紧密相连；能力来自于表层之下的强大语言。

基于强大语言并且易于表达的DSL将会成为一个新的标准。

——《The Productive Programmer》

自动化一切该自动化的东西

Hu Zhenbo — Wed, 06 Aug 2008 05:15:00 +0000

计算机生而该为你完成那些简单重复的劳动，自动化一切应该被自动化的东西吧。

1. 作为高级计算机用户，应该比普通计算机用户更懂得利用计算机的效能。Windows带来的图形界面却恰巧是一个程序员生产率的束缚。

2. 重复操作简单的任务，让一个人无法把精力集中于更应该被关注的东西，也会让一个人变得更笨。

3. 实现自动化的过程，恰是一个学习新知识，开拓新思维的过程。

——– 《The Productive Programmer》

TDD

Hu Zhenbo — Wed, 06 Aug 2008 05:03:00 +0000

TDD给设计带来太多好处，以至于可以把它称为测试驱动设计。

1. TDD迫使你在编写代码之前，考虑更多对象之间的交互。

2. TDD迫使你把对象的创建封装在一个更好的层次上。

3. TDD会让你写出更加小而内聚的方法，从而使方法的重用以及纠错变得更加方便、快速。

4. 同样，TDD所带来的高测试覆盖率，能保证你的重构更加可靠。

——– 《The Productive Programmer》

孤独的味道

Hu Zhenbo — Tue, 22 Jul 2008 15:25:00 +0000

孤独的味道有很多种。

有一种孤独是被抛弃的孤独。小时候经常感受到这样的孤独。放学回家，却发现家里空无一人。一个人坐在家门口的凳子上，看着天色变黑，路上行人渐少，邻近的灯光也一盏盏熄灭。

有一种孤独是被冷落的孤独。这种孤独，可能是发生在喧闹的派对上，可能是发生在朋友的聚会上，人很多，声音很噪杂。但可能那里的热闹不属于你。

而另一种孤独，是阿兰・德波顿经常感受到的孤独。这种孤独经常发生在一个陌生的城市或者国度，一个火车站旁的饭馆，远行的旅客稀稀落落地坐在饭馆里，或埋头进食，或点烟自醉，或用手托着脑袋观察着玻璃窗外走过的每一个行人。每个人都知道，他们互不相识。他们或都是第一次来到这个城市，他们也可能来自全世界不同的地方。

但这种孤独绝不仅仅属于他。

记得来到北京的第一天，在这个几乎没有亲人，没有朋友，甚至从没想过会有交集的城市，第一次感受到了一种从未有过的孤独。旅店里穿着奇怪服装的服务员，用带着浓重京味的普通话跟我交谈，让我意识到了我真的来到了北方；公交站上排队的一对学生情侣，未脱的稚气和那种北京人才有的脸谱和表情，让我想起了《十七岁的单车》里骑着车狂奔的少年；破旧的地铁二号线上，人潮拥挤，一辆列车疾驰而过后吹扬头发的风，那真的是春天的地铁；在夜色下驻足天安门广场，路上匆匆人行而过，远望毛主席高高挂着的头像，那是少年时我爱北京天安门的记忆。

一切都是新鲜，一切都是陌生，一切都不属于我，一切也都属于我。因为在那刻，我可以尽情观察，尽情感受。

这样的孤独，其实是种美。

我屡屡冲动要去再次感受这种孤独。

拜佛记

Hu Zhenbo — Sat, 12 Jul 2008 13:47:00 +0000

今天去有着“京都第一寺”之称的潭柘寺拜佛，因为听说这个寺是北京最灵的寺。一下车我就发现，门口赫然写着“皇家第一寺”，顿觉它的神圣。没走几步，又发现旅游车上写着“天下第一寺”，我的心就快开始激动起来了…

进入大门，见边上一商店门口放着一个大大的弥勒佛像，笑呵呵地捧着一块牌子，牌子上写着“照相两元”。看到此副场景，我想说我们的市场经济已经成功了，连佛祖都这么有经济头脑，谁还敢说我们没有彻底市场化？

其实我对佛祖一向来怀着恭敬之情，但不是很喜欢去寺庙拜佛，因为如今的寺庙都要收门票，而且每个殿里都放着用来“化缘”的钱箱子。我虽然不在乎那点钱，但是在交门票的那一刻，寺庙在我心中的神圣已经减半。现在的寺庙，充斥着铜臭味，大多数跪倒在佛祖面前的人，老太太，中年肥男肥女，无不在说，让我发财吧。本来想求根签，但我刚拿起签筒，一个中年男子奔过来，关切地问我：“求签么？”我知道他的意思是：求签就交钱吧。我无奈地放下签筒，那还求个屁，你也是人，我也是人，我干嘛要付钱向你求。

不过潭柘寺倒是大体上保持着古朴的风味，而且殿堂繁多，有着各色佛祖等待着朝拜。走走停停，停停走走，到最后，一大捆60余根香竟然用完了。我感觉我从来没有这么虔诚过，在每一个佛祖面前，我都忏悔了一遍，希望他们能原谅我这些年做的一些错事。如今的一些事情，让我懂得了“出来混，迟早都要还”这句话的道理。

前往西观音洞的路上，看到正在建造的一个观音像，被塑料布和麻神捆着。这不由自主地让我想起了“泥菩萨”这个有趣的名词。西观音洞潮湿阴暗，我跪下来拜了拜坐在那个幽暗的洞里的观音姐姐。但我一直在想，为什么要把慈祥善良的观音姐姐供在这么一个洞里呢？出去透透气吧，外面阳光这么好，真是亏待您了。

Who have made a difference?

Hu Zhenbo — Fri, 27 Jun 2008 13:31:00 +0000

Forrester analyst Carey Schwaber published a blog post this week titled “Which Vendors Have Made A Difference In App Dev?”

Sun, by making Java a platform as well as a language and by making it bigger than Sun itself by opening it up with the Java Community Process.

Junit (not a vendor, but as powerful a force), because manual unit testing doesn’t make economic sense and if it doesn’t work at the code level it isn’t going to work on at the system level.

ThoughtWorks, by pioneering Agile practices on complex enterprise projects and proving that Agile isn’t just for simple Web development.

iRise, by waking the market up to the limitations of textual requirements and providing an accessible and effective alternative.

Agile China 之精益之旅

Hu Zhenbo — Tue, 24 Jun 2008 10:03:00 +0000

听了精益工厂之旅的演讲，个人有几点有趣的思考：

1. 环境越干净，不好的东西越容易被发现。

2. 人往往涉及面越多，权限越大，犯错的机会就越大。

3. 人没有机器高效，准确，但人的优点在于能发挥主观能动性。

其实人类社会也是如此：

干净整洁的社会环境：让一切不应有的地下交易都被放到阳光下，社会的黑暗才会越来越少。

完善的社会制度：用制度来限定人的权限，减少潜在的破坏，错误和浪费。

自由：在遵循社会制度的前提下，每个人都应享有最大的自由。自由催生人的主观能动性，推动社会的进步。

什么是精益？这篇文章我觉得很好。

春游@北京

Hu Zhenbo — Mon, 23 Jun 2008 06:15:00 +0000

这几天趁着表妹来，好好地放了自己一个春日假期。

玩了很多地方，记录一下印象深刻的几个地方。

北大：大学就应该有深厚的文化底蕴，这是用再多的金钱也无法堆积出来的。浙大紫金港很大很美，很现代，但那永远只是钢筋水泥的堆积物。即使是玉泉校区，也只是旧却缺乏回味。

长城：第一次亲眼看到长城，只能用震撼两字来形容。

主席：瞻仰主席遗体的时候，突然感觉脑袋被一种很神秘的力量控制了。

Agile China 之腾讯

Hu Zhenbo — Sun, 22 Jun 2008 14:45:00 +0000

腾讯的研发部经理作了精彩的演讲，虽然前段部分广告内容太多。但有几点新鲜的东西：

1. 现在石油价格不断攀升，能源问题引起了各个国家不断的政治风波。原来以为能源问题跟网络公司似乎没太大关系，但其实随着腾讯的服务器数量即将达到10万之巨，电力开支已经快要超越人力成本，成为腾讯最大的成本开支。

2. 灰度发布：所谓灰度发布，就是新产品逐步放量发布的过程。其主要思想就是把影响集中到一个点，然后再发散到一个面，出现意外情况后很容易就回退。刚开始可能仅仅放量给100个用户，你可能就是那个最先使用到腾讯新产品的人哦。

3. 原来国内最大的互联网公司，也已经敏捷了。

福特的第一辆汽车

Hu Zhenbo — Mon, 09 Jun 2008 04:32:00 +0000

“1903年6月16日，福特汽车公司在底特律的一间由货车车间改造而成的窄小工厂中宣告成立。”

“1903年7月23日，福特汽车公司在底特律售出第一辆汽车。这辆双缸内燃机汽车是由公司副经理亨利-福特设计的。”

“福特生产的T型车，前后总共生产1500万辆，这个纪录一直到几十年后才被大众的甲壳虫超过。业界给他的评价是‘给世界装上轮子’，一个是因为他使得汽车开始普及，另外一个是他独创的流水线生产影响了整个社会的生产方式。”

“XXXX年，T软件公司由几个大学肄业的励志青年在某地创立。”

“同年，由他带领的几个人一起研发的软件卖得几百万美金，赚得第一桶金之后，开始走上辉煌之路。”

“公司规模迅速扩大，销售额超过了1亿美金。资本家的资本积累速度前所未有。业界给他的评价是‘给轮子装上大脑’。”

当人生演绎到第三部曲时，他突发奇想，软件为什么就不可以流水线生产。把它打碎，外包给不同的公司，就像生产汽车零部件一样，最后组装在一起不就是个完整的软件了么？而每个外包公司就像流水线上的一个工序。太好了，这样我不就可以：

1. 提高生产效率，降低生产成本。
2. 简化生产管理工作。
3. 随时无限扩大产能。

天才从此诞生！天才之下一批摇旗呐喊的“忠诚”支持者。

福特可以通过流水线制造汽车，却不可能通过流水线创造汽车。而软件的研发，永远都是福特的第一辆汽车。

从思维角度看编程过程

Hu Zhenbo — Sun, 08 Jun 2008 14:53:00 +0000

当我们来到一个陌生的城市，就像我当初刚去杭州上学。到了周末，并想着跑出去玩一趟。但对城市又不了解，于是只好找地图，或者打电话问114应该坐什么车到哪里哪里。对于这个城市的一个新人来说，能找到地儿，已算不错。但坐车的机会多了，你并会了解其实从之江到武林广场根本不只302这辆破车，还有 Y5，K28路等可以走。K28是空调车，速度挺快，车挺新，但走的道挺绕，耗时久。Y5也是空调车，速度快，道又近，而且走的是旅游路线，一路上风景极好。

当我们对这个城市越来越了解，越来越熟悉的时候。再次出门，我们心中对坐什么车自然已有概念。并会根据每次出门的不同情况，作不同取舍。

比如：

* 但如果时间紧急，那就得坐Y5。虽然Y5要三块，而302只要一块。

* 平常情况，我们就选择坐K28路。价格公道，质量上乘。

* 302虽然便宜，而且车站就在门口，但往往路上会经常堵车，而且走的道很偏。而Y5路上不堵车，而且道上可换乘的其他公交车多。所以，值得花上10分钟，去Y5的车站坐车。

* 虽然Y5坐着方便舒适，而且快捷，但偏偏它容量小，坐不了几个人。所以，当全班同学出动时，只能去乘又脏又慢的302。

其实，每次思考，你心中都已经装着整个城市。你的大脑就是张地图，而且是张标志着每条路路况，每路车价格的地图。

我们编程的时候，用的也是这个思考过程。

当我们还是个新手，我们还停留在学会使用工具的阶段时，我们不停地翻看工具书，或者找有经验的人问询。只要把程序的功能完成，就算是不错，很少会考虑性能，负载等问题。

而当我们有了越来越多的经验，对程序的运行过程已经心中有数之时，每实现一个模块，一个方法，甚至每写一句程序，我们都会自然而然的考虑很多事情。

比如：

* 我们会在两种实现之间权衡，一种速度快，但耗费空间；一种节省空间，但速度慢。（当然，现在空间已经不是问题。）

* 做过多的over design 和优化，在没有客户/用户需求之前，都可能是没有必要的。

* 我们可以在很短的时间内，用最快的手段，实现一个方法，虽然代码丑陋了点。而往往一段好的程序，都需要考虑它很多特性，比如：它要通俗易懂，它要干净，它的耦合性要低，内聚性要高，扩展性要好，等等等等。

* 我们可以选择像Ruby这种优美，简单，开发效率高的语言。但是如果对性能要求极高，我们不得不选择速度更快，性能更好的语言，如C++，虽然开发效率会降低很多。

其实，每次思考，你心中都已经装着整个程序。你的大脑就是内存，而且是知晓很多外界因素的内存。

人类在考虑很多事情的时候，思维模式都是相似的。所以，各种事情，都可以找出其相似性。

从思维角度看有些编程技巧

Hu Zhenbo — Sat, 31 May 2008 14:32:00 +0000

当我们想做一件事情的时候，比如我们要从住处出发到某个餐馆去跟女友约会。

如果是个大老粗，不管三七二十一，出发吧。结果，到了之后，发现钱没带够，花忘了买，连最重要的礼物也忘家里了。没办法，还得折回去拿。结果是，自己累不说，还浪费了时间，浪费了金钱，而且女朋友也不开心。

如果是个思维缜密的人，他会先想：我去餐馆的目的是什么，哦，最重要的事情，是带给女朋友从国外买回来的礼物，所以千万别落了。当然，吃饭不能让女朋友付钱，所以得带上足够的钱。还有，如果送上一朵玫瑰，在烛光下，会更浪漫一点。用这两分钟时间先进行思考的结果是，什么都没落下，女朋友也很开心，最后，终于赢得美人归。

其实是编程中某些新鲜的做法，引起我上面的思考。在实现一个方法的时候，我们有时候可以先写结果（即我们想要的），然后一步步推导回去，在这个过程中，我们会很顺其自然的知道：我们要得到这个结果，需要什么？然后去把我们需要的东西拿出来即可。非常简单，不会做任何多余的事情。

而如果按照正常的写法，我们难免会像上面那个大老粗一样，要丢三拉四。

其实，原因就在于，前一种做法，你把你想要的和过程中所需要的都写下来了。而后一种做法，你把你想要的和所需要的，都还保留在大脑里。既然保留在大脑里，就难免出错，难免丢三落四。而且，保留在大脑里，就会增加大脑的负荷。既然如此，为何不把它从大脑中移出，即保证正确，又可以利用你的大脑去思考真正要思考的。

这个过程，其实和要先写伪代码的注释，是一个道理。

两种不同的代码版本管理方法

Hu Zhenbo — Sat, 24 May 2008 06:52:00 +0000

A方法：

在每个release中，每个人都建立自己的branch，各自的代码修改都在自己的branch中。等到release前两天，才能把代码merge到trunk里。

前提：

1. release要足够短。如果你的release是两三个月甚至更长时间才进行一次，那merge代码时产生的问题会让你焦头烂额。

2. 充分的测试代码，保证代码质量。

3. merge前，merge中（代码merge了，但还没有commit）以及merge后都要进行完整测试，以保证merge不会对trunk代码的质量产生影响。

4. 如果merge时发现conflict，需要重新进行3的后两个步骤。

优点：

1. 适用于需要经常性release的项目。

2. trunk的代码总“可用” — 即已经经过上次release时足够的项目质量检验。

缺点：

1. merge时，往往会有较多的conflicts。

2. 为了不产生太多的conflicts，需要的协调工作较多。

3. 无法预知merge之后的代码会产生的问题。

B方法：

代码的修改基于最新的trunk代码，而且每个人都可以随时把代码commit到trunk里。

前提：

1. 要有一个经过足够质量检测的branch版本，用作production上的版本。

2. 要有足够的测试代码保证代码的质量。

3. 要有持续集成工具随时监测trunk上代码的质量，如果上次build失败，则不许再commit代码，直到build被修复。

4. story要尽量小。

优点：

1. 符合持续集成的理念。

2. trunk的代码始终是最新的，而且是“可用的”。

3. 因为commit频繁，所以产生conflict的机会较小。

缺点：

需要维护额外的release branch版本，当需要打补丁的时候，要在两处保持同步。

两种管理代码的方式，各有优劣，但B方法更符合敏捷理念，而且，本质上其实是一种对A方法的替代。

Pair Programming:1+1>2

Hu Zhenbo — Sat, 17 May 2008 08:08:00 +0000

进入ThoughtWorks之后，开发工作一直是在pair（结对编程）下进行。对于我这样从未有过pair经验的人，突然转变到pair下工作，其中的感触特多。（以后要养成好习惯，要在最有感触的时候把事情记录下来，嘿嘿。）

写这篇文章之前，google了一下业界对于pair的看法。不小心就搜到了公司同事钱安川在两年之前写的文章：结对编程。通读全篇之后，发现其中对于结对编程的一些误解，在我没有经历过pair之前也同样有。希望通过此篇文章帮助更多的开发人员认识到，pair其实很美好，即使你有很多担忧以及顾虑，也不妨一试。

个人认为，pair最大的几点好处在于。

1. Knowledge Transfer/Share

进公司之后做的项目是一个ROR的项目。Ruby和Rails对于我来说都是陌生的，压力颇大但激情更大。幸运的是，团队里面有经验丰富的老外同事和gigix，郑晔等人。以下事实说明通过pair传递知识的速度非常的快。

a. 项目移到北京office的时候，已经在美国完成了一个release，北京office的成员对于项目一无所知。刚开始由gigix和郑晔跟两个美国同事pair，两个礼拜下来，他们两位基本上对项目有了很好的了解。反映在他们已经可以跟我这样的新手pair来共同完成一些story了。

b. 我加入到pair行列之后，跟这些有经验的同事们一起pair，通过观察和讨论，迅速地掌握了很多Ruby和Rails的知识，也对项目的业务流程，框架等有了快速的了解。注意，时间仅仅是一个多礼拜！回想在原来公司的时候，如果进入一个已经在运行的项目，一个礼拜才刚看了些文档吧。

c. 在pair的过程中，不仅仅是知识和经验的传递，有时候更多的是，思维方式和工作方法的学习。这几天经过和同事们pair，通过观察和参与，学习到了很多不一样的思考问题和解决问题的方式。

2. 提高工作效率

很多没有经历过pair的人都会说，让两个人一起做一件事情，不是浪费资源么？其实在我没有经历过pair之前，也有同样的想法。但在真正经历过pair 之后，我彻底改变了这种想法。并且，曾有一次在跟一个在安永工作的同学聊起他们的工作的时候，我竟然不由自主地推荐她使用pair的工作方式。她听了之后，竟然也表现了相当的认同。我会在后面提及原因。（他们可不是IT公司）

首先不管pair是否真的会浪费人力，时间和财力。我个人最大的感受，就是在pair的时候，我的思维集中度是工作以来最高的。一个人工作的时候，总会时不时发一会儿呆或者想想其他事情，或者上网看看新闻。但pair之后，你就没有这样的机会了。而且，会因为不想让partner失望，你会表现得更加出色和努力。

关于pair和individual之间工作产出的区别，我并没有做过统计和比较。但是，犹他州立大学（University of Utah）在1999年做的一项试验，其中的数据已经有了很好的证明。

3. 锻炼与他人一起工作的能力

pair并没有对什么人可以或者不可以一起pair有规定，而是鼓励任何人之间都要去pair，无论是水平相当或者是经验悬殊的。鼓励pair，其实也是鼓励沟通，鼓励去除障碍。即使有些人不善沟通，在经历pair之后，我相信，他们也会变得乐于交流。

pair的工作方式，其实本身就是一种很好的培养团队精神的方法：合作，交流，沟通，分享，互助，等等。

4. 碰撞出火花

pair需要讨论。一个人独立思考，往往会陷入误区。而如果两个人一起讨论，往往会碰撞出一些火花。

讨论，是个很奇妙的东西。即使真的不能碰撞出火花，也是一个让自己重新思考的机会。讨论中的思考和个人独自的思考，产生的效果是完全不一样的。讨论中的思考，往往会帮助自己认识到独自思考时的很多误区。我在想，这可能是因为讨论中需要更加开放的心态，以及观察事物角度的改变，让一个人有了新想法。

5. 代码质量保证

pair是个很好很方便，也很节省时间的代码质量检验的过程。之前公司用的是code review的方法，与之相比，pair中的质量检验具有：实时，交流以及及时修正等好处。

同时，pair比code review更节省时间，更有效率。

————————————————————————————-

之前谈到推荐安永的朋友使用pair工作方式，也是因为质量原因。在安永这种审计公司，是不容许出错的。所以，对于很多数据报表，要反复审查有没有出错（而且他们经常是自己审查自己，很容易进入误区）。而对于复杂的数据报表，刚开始不出错是不可能的。所以，一旦出错，就需要花费很多的时间去修正。

而如果用了pair的方法，首先可以帮助他们减少反复审查的次数。两个人做一件事情，永远都会有一个人充当监督员的工作。相当于边做边审查，而且，由他人来审查，因为不同的思考角度，会让审查更有效。其次，如果一旦出错，监督员基本上都会发现，特别是一些明显的错误。在这时，就可以及时修正。

————————————————————————————–

最后要说的是，钱安川的结对编程这篇文章更系统以及更全面，希望了解结对编程的人，可以去看他的文章。但我作为一个新手的感想，或许可以对很多希望尝试结对编程，但还有顾虑的人，一些鼓励。

小事情，大意义

Hu Zhenbo — Wed, 14 May 2008 11:47:00 +0000

这几天客户来了，客户是一个国际酒店集团，他旗下几个品牌的酒店估计很多人都见过听过或者住过。

前两天客户带我们到金融街的一个他们旗下品牌的五星级酒店参观，有幸第一次见到一个晚上要上万的客房是什么样子，吃了我平生以来最贵的牛排，也是人均消费最贵的一次晚餐。

饭后，跟李总还有gigix坐车回家。李总关切的问：“今天感觉怎么样？”我很直白的说：“花了很多时间，但感觉没什么用。”（其实我的意思是，除了见识了奢华，享受了晚餐，这次行程没有让我感觉对项目有多少帮助，匆忙而过，难道一次参观就能知道什么是PIP了么？）

李总说：“不过大熊说的很对，这次行程让我们知道了项目的价值。”

一语点醒梦中人，是的，项目的价值！没来参观前，我们心中只有产品，只有story；参观之后，我们终于真切感受到我们项目服务的对象，服务的价值，每个story背后产生的意义。同时，也为能给这么大型奢华的酒店服务感到一丝丝的骄傲。

价值感，让项目动力倍增。

回到未来

Hu Zhenbo — Fri, 11 Apr 2008 16:38:00 +0000

当别人问我，或者自己问自己，你到底想成为一个怎样的人？一直不知道该怎么回答，因为一直不是很清楚自己到底想成为怎么样的人。有时候以为知道，但其实并不知道。今天，倒是学到了一个方法。

首先，认识现在的你。列出你现在的状态，尽量仔细，包括各方面的特性，知识，技能，信心，性格。

然后，看看未来的你。你希望在一定时间之后，具备怎样的技能，去掉什么缺点，或者达到什么目标。

其次，列出阻碍你前进的障碍，比如，缺乏信心，缺乏坚持，缺乏知识，还是缺乏一个好的环境，等等。

最后，列出在你前进的路上，你可以利用的资源，比如，身边的朋友，导师，优秀的书刊。。

把四张卡片放在前后左右，前面是未来，后面是现在，左右分别放好障碍和资源。

然后，闭起眼睛，走向未来。时间飞逝，那已经是n年后，你具备了你想要的技能，你终于成为了你想成为的人。感受那一刻，你是否开心。你是否想欢呼，想庆祝。（如果你真的开心，那说明你真的想成为那样的人。如果你发现自己并不十分开心，很可能说明那个目标其实不是你想要的。）

然后，走向资源。看看这些一路陪伴你，帮助你走向成功的伙伴，朋友，良好的工作环境，让你学到技能和知识的优秀书刊。你是否感激他们，感激他们一路陪伴，庆幸自己一路坚持，利用好了这些资源。

然后，走向障碍。看看这些曾经阻碍你前进的障碍，是否觉得他们其实很渺小，你完全可以战胜他们？

最后，回到现实，让自己回到现在。回想一下刚才走过的路，感受到的经历。一切都会在以后发生，只要你努力，只要你坚持，你想要的未来就在不远的前方。

好，呵呵，真的回到现在来吧。这是在TWI最后一天做的一项训练。很喜欢TWI各种activities，各种role play。每一次，都好像身临其境。

TWI终于结束了，两个礼拜的培训，这是从来没有过的经历，收获很大，除了学到了很多咨询技能，agile知识外，最重要的是学会了参与，学会了怎么做presentation，怎样无障碍地交流，以及一个能很透彻地重新审视自己的环境。

感谢所有的朋友，所有的老师！

印度印象之城市建设篇

Hu Zhenbo — Mon, 31 Mar 2008 20:39:00 +0000

这次是第四次来印度了，工作之前从来没有想到过我会跟这个国家这么有缘，但事情就是这么奇妙。（莫非是肤色的原因？）

这次先说说对印度城市的印象，可以用三句话比较形象地总结印度城市的特征。（相较于中国的城市而言）

1. 印度城市是现代化大楼和贫民房的混杂体。

无论是在Bangalore还是Pune，你都可以见到很多很现代化的大楼，虽然都没有中国的大楼盖得高，但建设的现代化程度不比中国的楼房差。这些大楼大多数是一些跨国公司的办公楼，如Accenture, IBM, M$等。

但和中国整齐划一的形象不同，印度的城市是个现代化大楼和贫民房的混杂体。很可能，在一幢现代化大楼的旁边，就是一片贫民房。

2. 中国的城市是建筑之间有绿化，而印度的城市似森林之中有楼房。

印度城市似在原始森林里开辟出来的。城市中的花草树木杂乱无章，偶尔还可见一片倔强和粗野的树林。马路上随时可见牛、野狗、乌鸦等动物，好像行走于森林之中。

3. 道路狭窄，交通拥挤并且疯狂。

印度城市的道路狭窄，但挤满了各种类型的车：卡车，轿车，摩托车，三轮车，自行车等等，而且马路边遍布着各种小摊小贩。（可见经济还是很活跃的。）

更可怕的是，印度司机的思维模式跟中国司机完全相反。在中国，除非你是酒后驾车，在看到前面有行人过马路，都会下意识地放低速度。但在印度不同，印度司机，特别是三轮的士的柴可夫，当看到前面100米处有行人欲过马路，会立即加快速度，欲抢在行人之前通过。如果行人也没有退让，在即将“交汇”之时，柴可夫会勇敢地在百码高速下一甩车把，绕过行人，绝尘而去。据说印度的行人也较“麻木”，所以交通事故常有发生。

如果引用中国官方说法，用“脏乱差”三个字总结概括印度城市印象，一点不为过。

我真想说：把印度交给共产党领导吧，不出两年，孟买就会像上海一样，富丽堂皇的高楼林立。把印度城市交给中国城管来治理吧，保准小摊小贩在一个月内绝迹。（开玩笑:)）

为什么中国和印度作为当今世界上发展最快的两个国家，他们的城市之间却有如此大的不同？那得看背后的故事。。

无论是中国的城市还是印度的城市，都有贫困人口。中国的贫困人口由于“影响市容市貌”，由于影响官员的政绩，被赶出城市。而印度的贫困人口，照样可以生活在自己的家中，政府要造机场，修马路，但没有权利强行要求人民搬离自己的住处，没有权利剥夺百姓的耕地，他们可以搬，但得付给他们满意的价钱才行。

巨额的补偿是制约政府进行城市建设的障碍之一，但还有另外一些原因。

这次我在孟买机场着陆，看到孟买机场似被拦腰折断，一个巨大的凹口跟机场被一堵围墙隔着。一边是拥挤的跑道，一边是密密麻麻的单层破旧小楼。那里住着一些从农村来到城市的移民，刚开始他们没地方住，于是越过机场的围墙，在里面扎营落户。政府试图把他们赶出机场，但迫于选票掌握在大多数这样的贫民手中，不好采取激烈措施，赶了又来，来了又赶，最后只好作罢。后来，这些移民在机场上面盖了自己的房子，政府干脆把一块区域划给他们，并给他们通电通水，让他们正常生活。孟买机场一直没法扩张，这是一个很大的原因。

印度的基础设施建设确实要落后于中国至少10年。但基础设施落后的背后，是印度的民主进程远远走在了中国的前面，可能这个差距根本不能用十年来衡量吧。对未来的发展而言，孰优孰劣，估计现在还很难定论。中国的基础建设在我党的“英明领导和统筹安排”下，以惊人的速度快速前进着赶英超美。为了城市的整体规划，为了整齐美观，旧房危房一率拆除。在集体利益高于一切的方针指导下，无权无势无钱的老百姓可以随时被任意处置。

而印度人民，虽然很多人由于贫困，还生活在旧房危房和一个脏乱差的环境之下，但他们总算是住有所居，而且拥有捍卫自己住房的权利。他们人人可以享受免费的义务教育和廉价的高等教育以及免费的医疗服务，贫民的健康在政府的支持下均有保障，他们的命运也正通过教育而在改变。

之前看过一篇文章，说，很多住在孟买机场的农村移民，他们的下一代都上了大学。。。

抛弃挫折感

Hu Zhenbo — Thu, 20 Mar 2008 13:40:00 +0000

每个人都会经历挫折，挫折会使人沮丧。

如果沉浸于强烈的挫折感之中，不能自拔，挫折感的积累会使人越来越觉得自己一无是处，最终丧失信心。

如果把每次挫折当作一次机会，从中学习，改进自己，改正错误，你就会越来越优秀。

要认真对待每次挫折，但是，要坚决抛弃挫折感！

1st day @ TW

Hu Zhenbo — Mon, 17 Mar 2008 13:33:00 +0000

第一天到ThoughtWorks上班，果然没让我看错，TW真是个好公司。同时，也告别了无所事事的状态，重新回到每天繁忙开心充实的生活。

以前拒了TW，后来，终于还是抵不住她的诱惑，当然还包括北京和奥运的诱惑，决定重返TW。感谢TW给我再一次机会。

上次拒了之后，写了篇文章，推荐TW。碍于还在Trilogy，所以不方便发布。现在成了ThoughtWorkers的一员，终于可以骄傲得推广一下TW了。

TW是个好公司，是个很好的公司。虽然她目前在中国的发展有限，但是我相信她的前景是无限的。

1. 首先TW是个对程序员真正重视的公司。在我走进TW office的时候，我发现这个公司连个manager的单独办公室都没有。公司员工之间，没有明显等级的区分。无论你是一个普通程序员，还是郭晓，甚至是Martin Fowler，在公司里，就是跟大家一起坐在普通的圆桌上。

一个平等，开放的工作环境，真的很重要。就像TW说的：to be a home for the best and most passionate knowledge workers in the world。

2. TW在敏捷领域的影响力，在中国正日益加大。点击进入第二节敏捷中国开发者大会。我十分认同敏捷的思想，软件开发就是应该以人为中心，建立一个便捷沟通的机制，才能对变化做出快速的反应。

其实我现在对敏捷感触不深，等以后有了更进一步的了解，再写吧。

3. TW是个有理想的公司。她和麦肯锡一样，把自己作为一个领域内的专家或者研究机构看待，而不仅仅是一个以盈利为目的公司。

4. TW是个有社会责任感的公司。郭晓面试我的时候，问我一个simple question, 在我现在的公司有几个女生。我笑笑说，两个，比例非常至少。郭晓告诉我，TW现在有一个要求，招聘的时候，男女的比例一定要是1：1。我心中疑惑，说：软件开发领域本来就是男多女少，计算机系的男女生比例本来就相差很大，而且女生不适合干这个没有正常作息的工作。郭晓说：很简单，如果我们今年要招16个人，招完8个男生之后，就不再招男生了；而且，我们正致力于让软件公司的工作和其他工作一样正常化。不用多说了，现在有很多公司吼着自己是一个有社会责任感的公司，或者标榜自己是企业公民。好吧，像TW一样，拿出实际行动来吧。

我想大家都有疑惑，TW在有些方面是不是太过于理想化了。嗯，先不管她是不是过于理想化，至少，理想化的公司往往可能取得更大的成就。就好像万科坚持不行贿，是因为他坚信未来会有一个规范法制的市场环境，而在那时，万科已经走到了众人的前列。同样，TW终有一天，不，是一直会走在众人前列的。

中国股市的沙氏骗局

Hu Zhenbo — Mon, 17 Mar 2008 12:16:00 +0000

老沙博客在去年四月开博以来，到现在估计已经远远超过徐静蕾的博客流量。在股民疯狂的时代，老沙每日的吹捧受到了众人的拥戴。

股市日涨之时，老沙叫好，股民叫好。股市跌时，老沙继续high，股民继续跟随。到如今股市已经陷入膏肓之时，老沙仍在挣扎，股民难道还在跟随？

早在去年9月，有识之士已经警告中国股民，中国股市陷入了自欺欺人的庞氏骗局。没有人会听，果然，数月之后，”有一部分股市投资人被挂在天上，而且是高高地挂在那，像月全食一样满脸蜡黄。”

“这是某些人为‘奥运股市只涨不跌’的无厘头盲目、‘别人挣钱凭什么我不能挣钱’的嫉妒攀比、‘也许还能再涨一点’的贪婪成性以及‘我不会那么倒霉正好成为最后一棒’侥幸心理注定要付出的代价。”

到如今，我相信很多人已经后悔当初选择老沙，选择欺骗自己了。

其实，这只是最简单的人的善良想法了。

其实，“有识之士”因为忌于得罪某些利益集团的人，只是给了股民一个善意提醒，而远远没有把他了解的背后的阴谋说出来。

其实，有可能，老沙只是某个利益集团的一颗棋子。

其实，背后的那个利益集团是你永远也无法打败的拥有制定规则的权利，然后又擅自破坏规则的***。

不要不相信，看看现在谁得利，谁已经早已离开股市；谁制造了当初的“奥运股市”，谁在如今又一次次打压中国股市，你就会明白。

留下的，只是又一次上当受骗，又一次被瓜分财产的可怜老百姓。

快走吧！

美丽杭州

Hu Zhenbo — Tue, 18 Sep 2007 09:15:00 +0000

上周六，老天几次欲雨还休，终于也没落下一滴雨！

踏足青山绿野，老和山，北高峰，十里啷当，云栖竹径…

杭州实在太美了~~~~~~~~~

阿甘

Hu Zhenbo — Fri, 14 Sep 2007 15:04:00 +0000

《阿甘正传》是我迄今为止认为最好看的好莱坞电影，阿甘也是我至今为止最喜欢的电影人物。

你可以像看一部轻松愉悦的喜剧一样，轻快流畅地看完。但留下的却是深深的思考，感动和回味。

阿甘可以说是一部讽刺片：

讽刺现实中复杂的思想，复杂的人群，复杂的世界。

在他眼里，一切都是那么的简单，却不明白身边的人为什么那么“奇怪”。

一件件当时的著名历史事件，在阿甘的眼中发生，在阿甘的身旁掠过。肯尼迪遇刺，越南战争，与中国的乒乓外交，水门事件等等。

政治权谋，战争外交，由于有阿甘的参与，变得戏剧化。在观众眼中，成人世界的斗争变得不再那么沉重，更像是一场游戏。

阿甘在智力上不够聪明，在智慧上却在很多人之上。

始终记得阿甘在四次穿越美国，成为美国名人的时候，有人问他为什么跑步，阿甘说：“I just feel like running..”

阿甘简单的一生，创造了大部分人无法拥有的一个个传奇。

只是我一直不明白，他那么深爱，同样也爱着他的Jenny，却一次次离他而去。。平添了一份遗憾。

Zimo的《墨迹》

Hu Zhenbo — Fri, 14 Sep 2007 07:51:00 +0000

从华尔街到媒体

从摩根到凤凰

从纽约到西藏

一个怎么看都是瘦弱的女子，却拥有如此强大的力量，难得的坚持。

《麦田守望者》

Hu Zhenbo — Sat, 08 Sep 2007 07:50:00 +0000

中译本保留了内容，但把味道给丢掉了。就好像看中央六套的中译外语片，一群黄头发蓝眼睛的人说着特别做作甚至神经质的汉语，总感觉不能融入那个氛围。所以，我还是推荐读英文版。

可能很多人都经历过像主人公霍尔顿一样的孤独迷惘期，那个时期应该叫做青春期吧。特别不知道自己要什么，想干什么，叛逆，抗拒。对性懵懵懂懂，十分好奇。爱慕虚荣，滥交女友，召妓。对成人世界的虚伪非常鄙视，向往一片纯洁之地….

但内心却非常渴望爱，需要爱，妹妹的一个小举动也能让他感动得哭泣…

小说的点睛之笔应该是：The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.

代价

Hu Zhenbo — Fri, 31 Aug 2007 12:57:00 +0000

不管多大的代价，都会是最小的代价。

事业、感情、生活中，理智果断地做出选择，看似要付出非常大的代价，其实回头看，那都会是最小的代价。而犹豫不决，不够果敢的人，往往要为含糊和敷衍付出更大的代价。

为什么是他

Hu Zhenbo — Thu, 05 Apr 2007 17:40:00 +0000

这集apprentice，讲的是两队比赛卖雪糕的故事。从第一集中对“柏”这个男人眼神太过于暧昧一直看不惯，觉得太做作，但这集他的表现确实非常好，是一个十足的推销员，让我改变了对他的看法。

大家公认他的表现是这次比赛中队里面最好的，而且他还由于上次带队获胜，拿着免死金牌。

但怎么也想不到，这集中淘汰的会是他。

“柏”在borad room里面随口一句话放弃了自己的免死金牌，可能是因为他认为自己的表现优异，不可能被淘汰，所以做出了这个看似影响不大的决定。

然而这个决定却让“柏”出局了，出局的原因也就在于他做了这个看似不经意其实却是致命的决定。想想也是，他的这个错误，是放弃了自己的生存机会，远比卖雪糕输给别人来的大！

王石

Hu Zhenbo — Fri, 19 Jan 2007 14:03:00 +0000

王石，中国最大的房地产公司–万科，掌门人。

一口气把《道路与梦想》读完，感觉这个男人跟《亮剑》里面的李云龙一样，极具野性之美。

知道他是从几年之前央视举行的一次人类攀登珠峰50年的活动上，52岁的老王作为中国最成功的企业家之一，参加了攀登珠峰的活动，并且顺利登顶。感叹不已，人家已经是年过半百的人了。后来才得知，年龄最大的登上珠峰的人有七十几岁。生命无止境。。。

曾有人问王石，如果他去登山，回不来了怎么办，王石的回答是：“我希望自己不要平庸安逸的死去，死也要死得精彩。”

在这样一个企业家的领导下，万科成了中国最大的房地产企业，中国绝无仅有“决不行贿”的企业。

对于我们心中共同的疑问，我想，如果你了解了王石是怎么样一个人，你就会释然了。

名利：王石对名利有很好的取舍之道。作为万科董事长的王石，拥有的万科股份只有万分之一点六。曾经股权改革之时，王石自愿放弃他应得的所有股权。王石说：名利之间，只能选择一样，如果两样都取，便会招来杀身之祸。于是他选择了名。20年来，多少在经济改革之路上栽倒的人或许正反衬了王石当初选择的明智。

执著：万科以“不行贿”的规范自律，并能坚持到底。即使遭遇阻碍，即使遭遇诱惑，亦不放弃。

在登珠峰的路上，出现罕见的红日景观，众人数次呼唤正在营中休息的王石出来欣赏这难得一遇的美景时，王石说：“老王说不出去，就不出去。”

梦想：坚持“不行贿”，是因为他坚信未来会有一个规范法制的市场环境。而在那时，万科已经走到了众人的前列。

坚持“不看路边的风景”，是因为他明白，他的唯一目标是登上珠峰顶！

在这本书中，还可以看到王石在商场上博弈的高超手段，以及在登山之时，面临生死危急的冷静。想要了解他，就去他的博客吧：

王石的博客

曾国藩

Hu Zhenbo — Sat, 06 Jan 2007 07:53:00 +0000

曾国藩介绍（这里对曾国藩生平做了简短的介绍）曾国藩崇尚忠孝礼仪道德，一生清廉俭朴，戒贪寡欲。这是他的做人处世原则，他的成功很大程度上决定于他一生对此准则的坚持。即使在巨大的诱惑和恐惧之前，亦不放弃。诚如当初作为湘军统帅之时，攻下太平天国，坐拥几十万大军，推翻昏暗满清易如反掌，其弟亦劝其自立山头，曾国藩在诱惑面前反复思量，最后仍决定效忠朝廷。

曾国藩作为吏部侍郎之时，母亲病丧，回家守孝。他的人生际遇从此刻开始，太平军作乱，八旗，绿营军腐败软弱，不经一摧。曾国藩由此创立湘勇，直至后来的湘军，消灭太平天国。这是他此生最大的功绩。

曾国藩善于发现人才，重用人才，爱惜人才。左宗棠，李鸿章这些清朝名臣均是其提拔推荐。一生之所以如此成功，很大程度上决定于其有一个为他献谋划策的智囊团。曾国藩会相面，据说其相面基本上八九不离十，非常准确。很多人才都是在其生活中无意有意发现，经过提拔，重用，后来大都位居高位。

曾国藩曾因战绩不佳，并受到同僚排挤，告病隐退。传一仙道助他看破迷津，并送给他一本书，即对曾产生重大影响的《道德经》。

人说人的成功百分之九十是运气，曾国藩也不例外。举几个事例，刚开始攻打太平军之时，经历几次败仗，曾国藩因绝望跳水自杀，被人救上来之后，却忽闻捷报传来。后来曾国藩被石达开围困南昌，几陷绝境，此时却柳暗花明，太平军全部撤退。原来是南京内乱，石达开调军救主。要不说有这样天意的事情，曾国藩和清朝的历史就得改写了。

历史对曾国藩处理天津教案一事似乎是批多赞少，我倒觉得曾国藩在处理此事上用了较小的代价换来了和平。而且所说他卖国之事，归根结底是腐败的清政府，而不是曾国藩。

曾国藩晚年被调回任两江总督，处理了清朝四大奇案之一的刺马案。

曾国藩卒于1872年，人生短短才61年。他一生为国鞠躬尽瘁，辛劳而死。

曾国藩清心寡欲，廉洁一生，死时只留下几千两白银的遗产。俗话说，一年清知府，十万雪花银。曾国藩官居一品，一人之下，万人之上，如此清廉，实在是可敬。

《The One Minute $ales Person》

Hu Zhenbo — Thu, 22 Jun 2006 15:49:00 +0000

推荐大家看这本书，这本书不仅仅是销售员看的。就像它的副标题写的一样，it’s a book about The Quickest Way to Sell People on Yourself, Your Services, Products, or Ideas — at Works and in Life. 其实我们在生活中，无时无刻不是在充当一个销售员的角色，工作中，我们Sell Idea, 人生中，我们Sell人生理念，Sell自己。谁能成为一个很好的Sale Person, 谁就成为一个成功的人。

此书正是教我们在人生中，在生活工作中，怎样去影响他人，怎样Sale自己认为非常好的Idea，怎样成为一个生活中的成功者。

要成为一个很好的Seller，首先要成为一个Attractive Person，是Sell Person, 而不是Sell Man，我们首先要具备良好的人格特质，并且学会尊重每一个你Sell的对象，look at each customer as a PERSON，他们才是我们的衣食父母。Behind every sale is a PERSON，要想完成一次成功的sale,首先要让别人认同你，尊敬你。

Sale不是Purpose，sale应该只是一个Goal，就像马云所说，阿里巴巴的目的不是赚钱，赚钱只是在目标完成时带来的一个结果，阿里巴巴的目的在于帮助所有的会员赚钱（有着这样的宏伟目标，焉能不赚钱？而如目光短浅者，盯着眼前的利益，却永远不能做大。）。就像在sale idea时，让别人接受你的idea不应该是你sale时的目的，帮助他们从你的idea中受益，让你的idea为项目，为事业做出贡献，才是你的目标。

So,what should we do before the sale? Remind yourself that your purpose is to help other people feel good about what they bought and about themselves for buying.
1. Mentally walk in other People’s shoes in order to help me see things from their points of view.
2. Mentally see the advantage of my service, product, or idea and how these advantage can help other people get what they want.

3. Mentally see the happy ending for the other people. They feel the way they want to feel: good about what they bought and about themselves for buying.

不要让sale成为你的负担，站在他人的立场去思考问题，用对方的语言讲话，让sale成为一件开心和轻松的事情。

接下来，看一下如何在sale过程中把握好方法和心态，让sale成功?

在Sale的过程，最重要的是建立信任关系，建立信任关系的最好办法，就是站在对方的角度，抱着为他人解决问题的想法，以此为目标去打动对方。谈话过程中，要学会倾听，这是一个很好的展示尊重的机会，花一分钟时间去总结一下你所听到的，既是个确认的过程，也是个展示尊重的过程。并不是每次sale都要成功，只有在你的idea或者product适合对方的时候，我们才尽力让对方接受。牢记我们的目标，是帮助他人，而不是sale。一次“放弃”的sale 或许成为以后多次成功sale的源头。

最后，要学会Ask them to buy。要自信，要相信自己的idea。

sale完成并不意味着sale的结束，在对方买了你的产品之后，同样出于目标的关心和回馈非常重要。他们会帮助你拉到更多客户。

上面讲述了sale之前，sale过程中和sale结束后所应该做，应该想的，以帮助我们取得sale的成功。下面，作者也提到了如何让自己成为一个自信的人，怎样让自己得到自身内心的认同和喜爱。

Sale you to yourself， become what you think abou。要有遵从你的内心和直觉的勇气，它们可能已经知道你其实想成为什么样的人。

要成为一个优秀的sale person, 首先要让自己学会自信，成功地sale you to yourself。

要有一个目标，无论是短期的，还是长期的，把他们写在一张纸条上，每天提醒自己。这会帮助我们不断取得进步，不断变得优秀。

要相信自己，喜欢自己，学会开朗和乐观，在正确做完一件事情的时候，不如嘉奖一下自己。

失败不可以打败我们，但不可以不警示我们。但警示过后，it’s over, just over…. laugh at your mistake and get on with enjoying both your work and yourself!!!!!

《Designing with Web Standards》学习笔记

Hu Zhenbo — Fri, 26 May 2006 03:37:00 +0000

终于看完了《Designing with Web Standards》这本被尊称为web领域最鸟的书之一。我想之所以鸟，并不是因为它所描述的技术有多么高深，而是它对推动web标准化所作出的贡献。对它的中文名《网站重构》并不是很认同，因为它并没有突出标准化这两个本书的核心词，或许翻译者的意思应该是“以标准化重构网站”吧。

总结了一些心得和体会，共享之。

Web标准化

标准化的必要性
在没有标准的年代，绝大多数网站都出现了费用上升，效益下降的状况。随着新版本浏览器的出现，网站遭遇淘汰，需要构建新的适应新一代浏览器要求的网站。并且，网站要有多个版本，来满足不同浏览器的要求，来满足仍旧在使用旧版本浏览器的用户。

这些都是因为没有规则，没有教条所产生的问题。为了降低网站制作的费用，为了能让一个网站版本就可以在所有的浏览器上正确运行，为了让网站不再为出现的一个又一个新版本的浏览器而花费巨资重建网站，Web标准应运而生。

这些看起来可爱，却有着丑陋代码；看起来时髦，却用着古老方法的网站，正在向web标准过渡。

Web标准是真正向后兼容的，又能在很大程度上做到向前兼容，一劳永逸的别无选择。
Web标准通过把网页分成三个独立组成部分来解决这些问题：Structure, Presentation and Behavior。来实现这个分类的内容有，结构化的语言（如XHTML和XML），解释性语言（如CSS），对象模型（如W3C DOM）和脚本语言（如ECMAScript）。(当然，你也可以创建一个完全基于flash的网站)

如果把一个网站比喻成一部电影，那么结构就是它的编剧，决定了这部电影的各基本架构；表现就是艺术导演，决定了一个网站的分布、外表；脚本语言提供特效处理；而对象模型则就是整部电影的导演了。

或许在不久的将来，网页的结构会完全基于XML，但现在我们强迫自己先去使用XHTML，一种W3C推荐的，过渡期的置标语言。置标语言包含的格式化的文本数据，用于创建网页的结构：标题、副标题、段落、数字列表、定义列表等。我们要尽量将结构从表现和行为中分离，比如表格（table）只用于做它原始的目的：表现一个表格数据，类似电子表格、地址簿等；强调结构，在标记中没有表现的处理或者尽量少用表现处理。总之，根据元素的含义来使用元素，而不是因为它们看起来像什么。

表现语言（CSS1,CSS2）用来格式化网页、控制字体、布局、颜色等等。表现应该决定于CSS，而不是标记，其实CSS发明者并没有为任何元素假设显示方式，但浏览器作了大量的假设。我们在制作网站的时候，就应该在观念里不要把标记跟显示联系在一起。标记就是标记，只是代表一个结构。

标准的对象模型DOM使你可以创建出运行在多平台和浏览器上的交互行为和效果，不再需要为各不同浏览器创建不同版本。

附：各标准组织介绍
W3C：World Wide Web Consortium, http://www.w3.org。一个研究Web规范和指导方针，致力于推动web发展，保证各种web技术能很好协同工作的组织。
Web标准组织：www.webstandards.org
ECMA：将ECMAScript定义为“标准JavaScript”。

XML
XML是自HTML以来最成功的web标准。XML是一种可以包含一切的数据格式，已经被广发应用并且适用于复杂需求。在当今数据驱动的时代，私有格式的数据将被淘汰。XML拉平了技术门槛，并且任何人都可以参与。

在介绍XML之前，先来介绍一下HTML，以区分它们的不同。HTML是构架web页面的一种基本语言，它由一些固定数量的标记和看起来有些矛盾的规则组成。在HTML中，你可以随意使用或者不使用某些标记，组合或者不组合其它标记。但这个松散的随意性，恰恰使构建一个web页面变得很容易。

但在今天，经过长期成长的网站，需要频繁的通过发布工具重新组装页面，经常需要将内容从数据库发布至web页面或者无线设备。但HTML缺乏这种统一的规则，从而阻碍了数据的转化。我们很容易把文本转化成HTML，但是很难把标记在HTML文件中的数据转换成我们需要的其他文件格式。利用XML，我们就可以做到对标记进行编码，使得任何支持XML的环境都能理解我们的XML文档。

XML是一种能创造其它语言的语言。XSLT，RDF，RSS等等这些应用都基于XML，能被XML解析器理解，并且每个应用可以很容易和其他应用进行数据交换。XML不仅可以保存数据，还可以保存数据的数据（元数据）。

设计与构造
这个部分详细地介绍了建设标准化网站的各种方法，XHTML、CSS、基于DOM的脚本语言，以及在使用这些方法时为了向前兼容所采取的一些折中方法。

XHTML
XHTML是一个用XML语法对HTML重新阐释的语言，XHTML是一种基于XML的置标语言，并且看起来和HTML有些相像。

用XML来重新阐述HTML的一个重要原因是，XHTML是一致的，而HTML则不具备这个特性。在HTML中，有些标签从来没有结束标签，而有些必须要有。

但这些都不是最主要的原因，最主要的原因是：用基于XML的语言开发页面，站点就会很好地和其他基于XML的语言、应用程序和协议进行交互。在没有实现使XML数据服务于大多数Web浏览器之前，XHTML 是种很好的桥接技术。在目前，XHTML1.0是过渡的最好选择，而过渡到更高版本则需要更多的工作，也没有这个必要。

XHTML有更多更苛刻的不同于HTML的要求。这里就不再赘述。

附：W3C校验服务
CSS校验服务：http://jigsaw.w3.org/css-validator
标记语言校验服务：http://www.htmlhelp.com/tools/validator

DIV流
DIV是什么，W3C对它的解释是“一个增加结构的通用机制”。用division来解释div最恰当不过，div是一个块，它可以是一组链接，可以是一块文档，也可以是页面底部的法律声明块。
在初期接触所谓标准化编码的时候，经常会出现这个错误的概念：结构化就是Div流，就是用div来替代table。其实不是div代替table，而是用结构化的方式来代替表格式布局。
其实标准化就是：该用什么的时候用什么。我们要提倡从table到div的转变，但也要防止出现Divitis，该用什么的时候才用什么，用什么取决于结构的含义，就好比标题用h，段落用p，表格用table，而不是用“div class= ‘headline’”来替代“h1”。

CSS
W3C把CSS定义为“一种对web文档添加样式的简单机制”。
学会正确使用即可以。其中注意CSS的盒模型并不符合我们的通常理解。盒模型的四个区域包括：内容，边框距，边界和边距。其中CSS的width并不是整个盒的width，而是内容的width。或许在CSS3里会有一个“盒尺寸设置属性”。
某些版本的IE中有很多bug，比如IE5.X以及旧版本错误地理解了盒模型。我们总可以通过一些巧妙的办法，使表现设计在这些浏览器上也正常显示。

DOM
什么是DOM？DOM是一种与浏览器无关的，平台、语言中性的接口，能够允许“程序和脚本动态地访问和更新文档的内容、结构和样式”。
DOM驱动的交互会替服务器减轻一部分它所要进行的繁重的处理。在客户端，你就可以轻松地进行很多操作，比如排序等等。
有了DOM，我们就可以利用基于DOM的脚本语言，比如JavaScript创建丰富的交互功能。

标准化学习过程
www.zeldman.com, www.alistpart.com 等等这些完全标准或者标准过渡型网站，都是我们学习的榜样。对它们代码的阅读，有利于建立什么是标准的概念，并学习到在标准化的规范下建立优等网站的技巧。

SES

Hu Zhenbo — Thu, 30 Mar 2006 15:47:00 +0000

写写上次去南京参加SES大会的一些趣事和心得。

印象最深的当然是马云，marketing确实很强，一上台就扛起了民族主义的大旗。掌声不断，笑声也不断。Google的周韶云在造势方面跟他比起来就差远了，受媒体的关注程度当然也不同，从会后记者的对比就可以看出来。有些人说，马云太浮，但我觉得其实像阿里巴巴这样的电子商务网站，需要马云这样一个marketing超牛的人。市场的竞争无非就是渠道和代理的竞争，马云誓称要为渠道商创造一百个亿的收益，收拢人心的举动众人皆知。如今很多B2B的网站进军中国，阿里巴巴的竞争压力与日俱增，如何在服务上真的让用户满意，才是关键。

Google在中国同样受到高层次人群的欢迎，主要用于搜索生活和技术知识，google的用户也相对成熟，客户忠诚度明显比百度高出不少。

其实目前很多中国的网站，都应该改变思路，不应该以一些花俏的如music download, mm pic等东西来吸引用户了，而应该真正站在用户方面着想，为用户创造真正有价值的服务。虽然百度在娱乐方面的优势保持了其在用户数量上的领先，但谁都知道，未来的天平将倾向哪方。

共享，参与，对话，互动是Web 2.0的特征。随着Web 2.0概念的兴起，越来越多的Web 2.0网站涌现。

即使是搜索引擎也开始出现Web 2.0的特征。从search info –> search Action + search Behavior –> Social Search。

结合自己做Intenet的体会，10年之前一个点子创造一个公司，而如今，要想生存，必须做深，做好！

* 离别时期,非常拾柒 * CS0117 forever *

Hu Zhenbo — Thu, 23 Jun 2005 16:31:00 +0000

岁月已逝,友谊永存.

Andy

读书时间《咨询的奥秘 – 成功提出和获得建议的指南》

澳洲东海岸-梦幻之旅

Rails系统性能优化之路

读书时间：《软件开发沉思录》

不要在习惯中死去

Vim

Lonely Planet Office

《ThoughtWorks文集》中译本序

澳洲游记 – 墨尔本之city

Rails之美

无关敏捷，关乎责任

The Elements of User Experience

发布之后

新博客，新种子

”框计算“的“框算计”

我们都知道我们想要的是什么

南京！南京！

简单运动

AgileChina 2009: Pragmatic Agile

大石头巷，我不会忘了你

孙子采花

读《战国纵横：四子归山》

路很长

最近杂碎

一路有感之无名暴走

一路有感之暖春暴走

出发

曾经我们的选择

技术写作

2009愿望：不折腾

出租车司机

做一个好Pair

乘时间机器，看敏捷旅程

我们为什么没有文档？

做一个“不偷懒”的程序员

翻译这事儿

Leary’s Rose

Frustrated = Growing Up

Assumptions Kill You

Strawood Footprint

Composed Method and SLAP

YAGNI

Secret Of Training

Respect

多语言编程

被激怒的猴子

Anti Patterns Catalog

Dietzler定律和DSL

自动化一切该自动化的东西

TDD

孤独的味道

拜佛记

Who have made a difference?

Agile China 之 精益之旅

春游@北京

Agile China 之 腾讯

福特的第一辆汽车

从思维角度看编程过程

从思维角度看有些编程技巧

两种不同的代码版本管理方法

B方法：

Pair Programming:1+1>2

小事情，大意义

回到未来

印度印象之城市建设篇

抛弃挫折感

1st day @ TW

中国股市的沙氏骗局

美丽杭州

阿甘

Zimo的《墨迹》

《麦田守望者》

代价

为什么是他

王石

曾国藩

《The One Minute $ales Person》

《Designing with Web Standards》学习笔记

SES

Agile China 之精益之旅

Agile China 之腾讯