透明思考

知易行难，魔鬼都在细节中

一看这本《卓有成效的程序员》，就一票人说，前半部分写得好呀，思想很深邃呀，很值得去思考呀。后面嘛，无非是些小技巧啦，只要思想掌握到了，小技巧无关紧要的啦。

还有《重构》也是，前几章思想很深邃呀，至于重构列表嘛，少少有点琐碎啦，只要思想掌握到了，具体的重构怎么做嘛无关紧要的啦。

还有我讲怎么做standup，怎么做retrospective，嗯嗯，思想很深邃呀。结构化交流，专注，目的驱动，很值得思考呀。至于具体这个会议的形式嘛，只要思想掌握到了，形式自己可以调整嘛，无关紧要的啦。

扯淡。

结果就是，思想好像掌握到了，实践怎么都实践不起来。咦？我不是秉承着xx思想来做的吗？怎么效果就没有呢？嗯…看来这个xx思想是有点问题啦…要么就是我们这里情况太特殊所以xx思想也不适用啦…所以xx思想实在太理想化啦…

敏捷，精益，整个讲的就是“怎么做事”。做事不照着正确的方式做，光抓着个“思想”在那边YY武林秘籍大还丹…练辟邪剑谱还要挥刀自宫的好吗？

所以涅…（1）真想学点什么，就好好的学，别人说怎么做就认真怎么做，不要抓着个自以为是的“思想”就开始自己YY；（2）真要自己YY也无妨啦，不过可以麻烦不要扯上别人的“思想”么？NealFord和MartinFowler教咱怎么做事，可没教咱怎么YY。

实施改进的五种策略

从Kent Beck和肖鹏那里抄袭来的：

1. 跳跃（Leap）：当我们知道改进的目标，知道改进的手段，并且这个措施不会对团队造成大的冲击、或者改进过程越长只会越痛苦，那么就一步到位，直接跳到正确的结果，不再回到从前不佳的做法。
2. 并行（Parallel）：如果我们知道目标和手段，但实施改进会造成较大冲击，并且小范围的改进也可以带来收益，那么可以先做小范围改进，与从前的做法同时存在一段时间，然后逐步推广到全局。
3. 阶石（Stepping Stone）：如果我们知道远景的目标，但对于到达该目标的路径尚不清晰，可以朝着正确的方向先迈出一小步，稳固改进成果，发现问题，再迈出下一步，如此朝向目标逐渐推进。
4. 简化（Simplification）：如果我们看不清远景目标，只知道一个大概方向，可以将正确的方向简化为一个可实施的、初具形态但不完备的目标，从而迈出改进第一步。
5. 暂停（Pause）：如果我们完全看不清远景目标，或实施该方面改进所需的依赖条件尚不满足，应该将此方面的改进暂停，仍然保持现有的做法。暂停不等于失去跟踪，随着其他方面改进的深入，远景目标可能开始清晰，或者依赖条件逐渐具备，就可以考虑重新评估暂停的改进项。

采用适当的实施策略，是为了实现安全的流程重构。过程改进不是砸烂重来，不是破旧立新，不是脏水孩子一起倒。流程重构和代码重构一样，一切的改进必须建立在保持现有系统仍然工作的前提下。

基本的套路：（1）了解现状；（2）制定目标；（3）发现改进项；（4）选择实施策略；（5）跟踪反馈。

就这么简单而已。

Refactoring And Design, In A Real World

Martin Fowler在《重构》里如是说：

如果你选择重构，问题的重点就转变了。你仍然做预先设计，但是不必一定找出正确的解决方案。此刻的你只需要得到一个足够合理的解决方案就够了。你很肯定地知道，在实现这个初始解决方案的时候，你对问题的理解也会逐渐加深，你可能会察觉最佳解决方案和你当初设想的有些不同。只要有重构这项武器在手，就不成问题，因为重构让日后的修改成本不再高昂。

如果做设计的人和写程序的人不是同一帮人，如果写程序的这帮人好不容易学会了写程序然后就会被拉到另一个再也不写程序的位置上，好吧，我们还怎么使用重构这把利器？

对此，我比较悲观。

《ThoughtWorks文集》中译本序

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

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

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

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

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

郭晓总经理，ThoughtWorks中国公司

Lonely Planet Images

Lonely Planet, the experts in independent travel information now present Lonely Planet Images (LPI).LPIis a digital image library with a unique and comprehensive collection of over 300,000 downloadabletravelphotographs taken by some of the best travel photographers in the business.

Lonely Planet Images

Its Chinese collection is relatively small so far. Hmm hmm…

Kent Beck发飙了，AgileChina 2009大有看头

郭晓走过来说，你下周休假了？啥时候回来？我说，大概9月21吧。郭晓说，那你亏了，你要错过Kent Beck的课程了。

当软件需求发生了变化、开发人员对技术的理解更深、或技术平台发生进步的时候，软件的设计也需要相应的发展和变化。掌握及管理这种变化的过程是软件开发人员一种非常重要的技能。好的设计能够实现更容易的测试、更低的成本、更快的开发速度、更少的缺陷，以及更高的客户满意度。本次培训将讨论如何实现一次只设计一小块软件，如何安全有效的进行修改，以及如何理解软件设计的内部结构并将其应用于日常工作。

郭晓说，KentBeck很激动，说这个是他三十五年编程经验的集大成，说他想了多少年软件设计问题突然一下子醍醐灌顶想通了，说他这下子彻底解决软件设计问题了，说他主动要求讲一整天不然讲不透彻。嗯，冲着大师这个劲头，它必然是值得一听的…

于是我说，那一定要录像下来。郭晓说，对，要录像下来，等你回来给你看。我说，等我回来拿出去卖，一份拷贝卖一万 :D

总之，大师这下发飙了，能听现场的同志们有福了。

嗯，本来不想降低品位…不过还是八卦一下…今儿发现一个自称“敏捷中国发起人/持有人”的疑似骗子。掏钱买培训的各位自己掂量吧。

IE6? No More!

Support it

I really believeEVERYwebsite with any sense of responsibility should include this.

Tech Lead的三重人格（完整版）

很多团队都有tech lead这个角色的存在，但同时很多团队对这个角色都缺乏明确的定义。大多数时候，团队只是指派其中经验最丰富、技术最精熟的开发者来担当techlead。但除了“tech”的成分之外，这个角色还有“lead”的成分，这就决定了他不仅需要技术上的能力，还要眼观六路耳听八方，才能带领团队── 至少是开发者们──取得成功。

Tech lead需要关注的事情可谓纷繁芜杂。把这些事情分门别类，我们可以看到，这个角色大致有三方面的职责：技术决策者、流程监督人、干扰过滤器。

InfoQ中文站：Tech Lead的三重人格

ActiveRecord Changed -include Behavior?

Just figured out that ActiveRecord 2.2 generatesSQLfor

Company.find(:all, :include = :people)

SELECT  FROM companySELECT person. FROM person WHERE person.id in (…)

SELECT * FROM company LEFT OUTER JOIN person ON person.company_id = company.id

It seems for the sake of performance…the current statements return smaller data set. However,it couldgenerate a very longSQLstatement if you have lots of ‘people’ in this case, and thus spend longer to parse andexecute.

And…WHEN did this change happen? I’m wondering…

读者盛赞《ThoughtWorks文集》

书中的文章在技术深度、详细程度、新观点/新成果的数量等方面各有千秋，但它们有一个共同的特点：都密切关注实践。这群作者真正做到了思行合一，如此既有思想深度又立竿见影的好书我已多年未见了。

Stefan Tilkov.CEO, innoQ

有这样一家企业，当整个IT行业都对定制软件开发的难度望而却步时，他们敢于挑战这个难题。这本文集让我们得以管窥这家企业内部观点的多样性──这正是他们勇气和力量的源泉。

W. James Fischer. 前CTO/资深合伙人，Accenture

从CruiseControl等大获成功的开源项目，到博客和会议上分享的观点，你都能感受到ThoughtWorks的影响力。身处其外的我们不时会想象，这家公司内部究竟进行着怎样的讨论？这本书就是一个难得的机会，让读者们拉开幕布，参与到讨论之中──你会因此成为一个更出色的软件开发者。

Nathaniel T. Schutta. 作者/讲师/教师

软件开发很大程度上是一种团队活动，团队的领导者将决定最终产品的水准。成功的组织经常不会花时间来记录这些领导者的经验，于是其他人也无法学习这些经验。这本有趣的文集由ThoughtWorks的一组领导者共同编撰，透过这些文章我们能看到ThoughtWorks企业文化之一斑。

Dave Thomas. Bedarra Research Labs

软件开发中最了不起的洞见都出自那些为真实客户解决真实问题的人。然而除了在恒河沙数的博客中淘金之外，几乎没办法找到这些洞见。十年来，ThoughtWorkers解决了大量真实问题，所以当他们决定把自己的经验整理结集，这实在是一件令人欣喜的事。

Gregor Hohpe. 《Enterprise Integration Patterns》作者

这本文集精彩地论述了如何在如今的商业环境下恰当运用编程语言和工具来开发软件。这组作者都是软件世界里身经百战的老兵，他们的经验值得一看。

Terence Parr.ANTLR项目领导，San Francisco大学

ThoughtWorks 素来以其在软件开发上的经验与智慧闻名于世，这本文集出色地汇集了这些经验与智慧，使我们得以从中受益。这本书将被频繁引用，它将出现在每个项目组的书架上。

Jeff Brown. 北美运营总监，G2One