透明思考

（From The Productive Programmer ）

1625年，瑞典国王古斯塔夫二世·阿道夫打算建造有史以来最棒的战舰。他雇了最好的造船工匠，专门种植了一片最刚硬的橡树林，都为了建造大船瓦沙。国王不断提出各种要求，希望把船建得更宏伟壮丽，到处都加上华美的装饰。有那么一天，他甚至决定在船上配备两套甲板炮，这是当时世界上绝无仅有的。他的船会是海上的霸王。而且由于迫在眉睫的外交问题，他还希望大船瓦沙能尽快造好。当然了，工匠们一开始的设计只有一套甲板炮，不过既然国王提出了要求，自然就得再加一套。由于太赶时间，工匠们来不及做“摇晃测试”──让一群水手从船的一边快跑到另一边，船在这种情况下不应该摇晃得太厉害（换句话说，没有头重脚轻）。结果，它的处女航只有几个小时，然后就沉入了海底：在给它加上所有华丽“特性”的同时，国王和工匠也让这条船变得根本无法航行。大船瓦沙在北海的海底长眠了几百年，直到20世纪初才被打捞出来，陈列在博物馆里。

一个有趣的问题：到底是谁导致了瓦沙的沉没？是国王，因为他要求了太多的特性？还是工匠，因为他们只顾着满足国王的要求，没有大声说出自己的担忧？看看你正身处其中的项目吧：你是不是正在建造又一艘瓦沙？

只做当下需要的。一开始这会很难，但最终你会得到一个更好的代码库。如果不引入不必要的复杂度，在修改或是重构时就不用对抗这些复杂度。程序员应该谨记：熵会杀死软件，所以，如无必要，勿增特性。

David Bock在给Neal Ford的 The Productive Programmer 的序里提到这个词：

We spent some time discussing that hyperproductivity and how to bottle it.

另一处提到这个词的是 Paul Virilio的blog

A worker in the textile industry in western France says, “I make the same movement six hundred times an hour. With the old machines, you could have a bit of a break. Now, it’s the computer that controls the assembly line and sets the pace.”

With this level of hyperproductivity, in which a person can no longer keep up with the racing of his digital command tools, we are seeing a new epidemic, following the outbreak of stress. Repetitive Strain Injury, or RSI ─ acute inflammation of the bones and joints ─ is a new professional disease. It can lead to long-term paralysis of the employee’s hands.

但这不是──不仅仅是──身体和压力的问题。这是劳动的异化。这是现代化对人性的侵蚀。

再看一遍 Skip 2 My Lou 的 老视频 。再看一场 Rockets 的比赛。

正确的方式，高效的方式，全无浪费的方式，未必等价于有想象力的方式，美的方式，自己喜爱的方式。这才是资本主义的病根所在。

From IEEE Software

... human-centricity, technical orientation, discipline, pragmatism, empiricism, experimentation, and value orientation.

I like this most:

A disciplined process applies its chosen technical practices CONSISTENTLY, if not BLINDLY. These practices may include coding standards, frequent builds, requirements modeling, architecting, informal design, code inspections, regressive unit testing, and exploratory testing. A disciplined process also consistently applies management practices to coordinate activities, share knowledge, and control product artifacts.

来自华为公司、负责软件质量和流程改进工作的周耀辉在第三届 敏捷中国 技术大会上介绍了 华为实践敏捷的经验

华为是偏重于流程为主的公司，多年之后市场环境不以公司为导向，在市场环境恶劣时候，华为公司发觉以流程为中心的环境很难应对这些要求，这是引入敏捷的原因。从2004年开始研究，在2007年步伐加快了，2007年下半年全面展开研究，今年年初开始全面进入试点阶段。

我曾经多次跟华为内外的朋友说到，华为的大问题有两点。第一是信息闭塞，公司内大部分员工不知道外面的世界（尤其是技术世界）在发生什么因此不知道很多已经被证明的最佳实践，公司外大部分人不知道华为里面是什么样子而导致华为被妖魔化。第二是基层员工极度缺乏决策权，大批只有执行力而没有微观决策权的员工使得持续改进难以成为整个组织的主旋律。

敏捷是改变这两个大问题的契机吗？看起来很像。一些好的现象已经开始出现。例如今天的演讲。一个华为的朋友说，在这种技术社区分享自己的经验，对于华为来说是第一次。

在保持执行力的基础上，给员工获取更多相关信息的渠道，使之具备足够的能力和空间进行微观决策，在全组织范围展开持续改进，并更加开放地与整个社区分享经验与收获。这样的一个华为，会是什么样子？

我说，它会是中国最好、最具吸引力的一家IT企业。

郭晓拍片 也挺上镜的，虽说有些紧张。

“精益思想就好比是做一批桌子，与其上午做好所有的桌子腿，中午做好所有的桌面，晚上组装，做流水线最后组装，不如以最快的速度出一批完整的桌子交付用户先使用” ─ Thoughtworks中国区总经理郭晓谈精益敏捷开发思想论方法

InfoQ: 争论：是否应该避免架构重写？

Joel认为在许多案例中做出需要重写软件的判断带有一定的主观性，其往往是由重用代码时遇到困难造成的。…即使旧的代码集就架构而言真的很糟糕，也应该努力清理代码、重构、修改接口，而不是进行全面的重写。

一种常见的担心是重构需要的成本不比重写来得小。第一，这是真的。基于一些真实的大规模重构得到的经验，重构遗留系统和重写需要的开发工作量基本上正好相等。不过第二，如果选择重构而不重写，可以确保原来的功能不被破坏。其实真实的担心往往并不是成本，而是效果：如果重构做到一半做不下去了再开始重写，那才是最坏的情况。所以真正解决这个问题需要切实可行的重构策略和手段，例如我在 这篇文章 里介绍的方法。

有很多这样的案例：面对着一堆遗留代码，人们说“那就既往不咎从头来过吧”。但事实证明从头设计一个优雅的架构于是软件就可以在将来的五年十年中保持良好的扩展性这样美好的愿望从来就没有实现过。因为，软件技术的发展是很快的，代码质量的腐化是很快的。良好的扩展性只有靠持续不断强力有效的质量保证才能做到。至于起点，重构还是重写，影响并不大──如果不介意重写的大风险的话。

昨天去打球…确实老了，要活动好一阵才能找回感觉。不过热身好以后还是足够欺负一帮本科生小弟弟的。现在打球越来越平和了，把球吊给中锋，看着他坐吃内线就好了。就算自己一球也不投进，传传球，只要自己这队能赢就行。

InfoQ: 老资格、尊重、威信和敏捷团队

两个讨论组的其他大部分成员都同意：一个人多年的经验并不一定能为他带来威信和尊重。威信和尊重来自于他的行动表现。Ajay Danait补充说 ，真正的领导者不会因为没有赋予权威而退缩，他们会通过建立共识来建立自己的威信。

其实没有威信又如何呢，如果这支队伍一直在赢？

而且不会有那么轻松的事。本科生小弟弟们慌乱的时候，我还得投进几个球─很高兴我还有体力连续投进4球。不过说实话，如果这是一种“建立威信”的行动，我宁可不要威信─一边叉腰喘着大气一边这样的想着。

我 早说过 ，王洋同志突然那么热心的要 解读精益 ，一定是为了混口饭吃。果然吧，不幸而言中。挂个好羊头，卖的是这块 狗肉 。

CSDP 英文为Certified Software Development Professional，即“被认证的软件开发人员”。CSDP认证体系由IEEE-CS于2002年创建，是对全世界范围的软件工程师在知识领域、工作经验及职业道德等方面的资质认证程序。它不仅是一个对软件从业人员的专业评测体系，而且还蕴涵了软件开发与管理的诸多标准，熟悉和掌握这些软件工程国际标准对于我国软件企业走向国际市场具有重要意义。

我这个人偏偏记性比较好。IEEE-CS的SWBOK无疾而终这才几年呢？现在又改头换面来认证软件开发人员了。真是把戏人人会变各有奥妙不同啊。（刚才坐在旁边的销售总监扫了一眼我的标题说：“谁不是无利不起早呢？”嗯嗯，这话说得很对。）

Ricky 和dreamhead 都写了我们周末玩的CodeJam。一言以蔽之曰，好玩，刺激。

黄亮 ，徐x ，Ricky Lui ，dreamhead ，李默 …

我很喜欢这个团队。很好很强大。

http://blog.csdn.net/gigix/archive/2008/04/04/2249120.aspx

本文以ThoughtWorks中国公司与客户合作的咨询项目为背景，为读者介绍如何在一个大型遗留系统的基础上组织和运作重构项目，从而切实有效地改善系统质量。

eMAN是客户的一个核心业务平台。该产品采用了典型的C/S结构，负责处理大量请求和计算的后台部分采用C++开发，负责响应用户操作和处理业务逻辑的前台部分采用Java开发；此外该产品还计划在新版本中提供基于Web的前台，这部分也采用Java开发。

在ThoughtWorks为该产品的开发团队提供咨询时，eMAN产品已经发布了十多个版本，最新版本代码量超过40万行，其中15万行是Java代码。一次又一次的赶工给它留下了大量的“技术债”：系统缺乏测试，代码质量低劣，“copy & paste”的痕迹比比皆是，维护和新功能开发举步维艰。我们这个咨询项目的主要目标之一就是为这个产品找出重构的办法。

(From my chat history with Michael Robinson.)

(11:16:46 PM) xcqmichael: In your situation, it's important to understand that there are two ways of looking at software, the coder way and the business way.
(11:17:22 PM) xcqmichael: The coder says software is successful if all the tests pass, the code is well structured, and easy to understand and maintain.
(11:18:01 PM) xcqmichael: The businessman says software is successful if it delivers more value to the business than the business spent to create it.

(11:19:22 PM) xcqmichael: You separate them in terms of pain points.

(11:25:00 PM) xcqmichael: point 1:
(11:25:53 PM) xcqmichael: Refactoring stories (or other technical debt stories) are like any other kind of story; they should follow INVEST criteria, they should have an estimated effort, and they should have a prioritized business value.
(11:26:18 PM) xcqmichael: Because, in the end, it all comes down to cost to code vs. value to business.
(11:26:28 PM) xcqmichael: point 2:
(11:27:12 PM) xcqmichael: Refactoring, by definition, means making changes to the structure or organization of a code base without changing its functional behavior.
(11:28:06 PM) xcqmichael: When you have a code base that is fragile and has no test coverage, it is very costly to refactor because it is very costly to confirm you have not changed functional behavior.
(11:28:12 PM) xcqmichael: point 3:
(11:28:51 PM) xcqmichael: When the cost of a technical debt story is very high, then the business value must be even higher.
(11:29:44 PM) xcqmichael: Consequently, the worse the code looks to you from a coder point of view, the more you should leave it alone from a business point of view.
(11:29:51 PM) xcqmichael: point 4:
(11:30:27 PM) xcqmichael: Therefore, when someone says, "there's whole bunch of code needs to be refactored", probably, none of it should be.

(11:31:49 PM) xcqmichael: Well, it all comes down to prioritization.
(11:32:00 PM) xcqmichael: And a clear sense of the cost/value tradeoffs.

以前我不认为一个被称为“敏捷成熟度模型”（Agile Maturity Model，AMM）有可能是什么好东西。原因是显而易见的：第一，我担心它把一组实践奉为圭臬，而敏捷的核心正是在于根据团队和项目的实际情况构造自己的方法；第二，我担心它成为一种认证，从而像它的前辈一样被骗子利用。

直到我给客户做了一次AMM评估。

第一，AMM不是认证，它是帮助我们集中注意力、了解真实情况的工具。
第二，AMM不是考试，分数是指示性的而不是决定性的，它的价值是指出改进的方向和切实的目标。
第三，进行AMM评估的目标是帮助团队更加高效地开发更高质量的软件，而不是拿到高分。

不遵循这三点原则的AMM评估，就可能滑入骗子横行的境地。敏捷的本质决定了AMM评估只能并且只应该被用于三个目的：（1）了解“我们在哪儿”；（2）计划“我们要去哪儿”；（3）讨论“如何去”。因此，任何与真实情况不符的、夸大的、粉饰太平的评估，都是毫无价值的自欺欺人。

参见另一个ThoughtWorker，Ross Pettit的文章，An "Agile Maturity Model?"

• 问题是什么？
• 头脑风暴：可能的候选方案有哪些？
• 这些候选方案之间的差异是什么？（分出至少三个维度）
• 选择其中最重要的两个维度，划出四个象限。
  • 标注：每个象限里的候选方案适合哪种场景？
• 我们的问题在哪个象限？（选择推荐方案）
• 从三个角度细化推荐方案
  • 要达到什么目标
  • 采用什么手段来达到目标
  • 如何验证目标是否达到
• 用适当的格式把细化的推荐方案记录下来

Oracle AppsLab Blog
"Mix is Live"
http://tinyurl.com/2hcp8p
An announcement of the Mix application we built in partnership with Oracle. In case you had forgotten, we have a logo/link at the bottom of every page of the application -- there for Oracle's 300,000 customers to see. By the end of the recent Oracle OpenWorld conference, the Mix had over 1,500 signups.

Oracle AppsLab Blog
"Let's Mix"
http://tinyurl.com/26fal3
The Mix application built in less than 5 weeks "with the help of the wonderful people at ThoughtWorks." Mike Royle, Toby Tripp, Matthew Wastrodowski and Sid Pinney were all part of this relationship.

InfoQ
Oracle Mix: First large JRuby on Rails app online
http://tinyurl.com/yqjzqb
ThoughtWorks, JRuby and Ola mentioned in excerpts

Oracle AppsLab Blog
Mix, JRuby on Rails, Small Teams, Agile, and it’s Effects on the World
http://tinyurl.com/26fg5p
A good post about JRuby and its role in the Mix development. Ola Bini and ThoughtWorks are mentioned.

在CSDN看到朱少民的一篇blog：勿忘质量之本（相信作者是把标题写了错别字）。略有感，说说我对QA这件事情的想法。

在北京理工大学做招聘宣讲的时候，有同学问ThoughtWorks的QA做什么。我们似乎很习惯于把QA和测试等同起来，就是坐在门边那个负责抓出所有bug的人。朱少民的blog里说“测试就是为了发现缺陷”，当然这毫无疑问是对的。但作为QA这个角色，我认为他/她的职责分两半：第一是发现缺陷；第二是确保缺陷被修复，并且修复过的缺陷永不再重现。前者是测试工作，后者是流程工作。作为QA（质量保障或者叫质量分析）的负责人，流程工作至少与测试工作具有同样的重要地位。

（那天晚上和江焱风一起吃饭，说到质量管理体系的话题。其实ISO9000就很明白了：质量来自过程和管理，而不是来自检验。）

所以，尽可能地把测试自动化，这实际上是在积累质量管理体系。这事情分为三个环节：（1）发现缺陷；（2）用自动化的测试案例描述缺陷，以测试案例通过为依据验收缺陷修复；（3）频繁运行所有测试案例，确保已经被修复的缺陷永不再进入代码库。而朱少民所说的“为追求测试自动化而忘记发现缺陷之根本”的问题，实际上是一个不存在的伪问题，因为这两件事情分别位于环节（1）和环节（2），彼此正交。朱少民还说“70％缺陷【的发现】还是需要人的智慧和思考”。不是的，100%都得靠人的智慧和思考。你不想发现的缺陷，它是不会被发现的——当然了用户会发现然后暴跳如雷地来找你，那就是另一回事情了。

总结：QA的工作分为测试、流程制定和流程监督三部分。质量不是靠守门守出来的，而是靠贯穿整个软件生命周期的管理管出来的。敏捷项目为什么容易获得更好的质量？因为它把质量管理落实到每个小时的每件具体事情上，而不是写在纸上。