解析极限编程读书笔记2——极限编程的原则

极限编程的原则――鄙人认为其中大多是通用的软件开发原则

今天腊月二十八，家里忙着做菜，自己也帮不上什么忙。看看书，充充电也是个不错的选择。

今天学习极限编程中所讲的“原则”。看过之后，我认为这不光是极限编程这种软件开发方法的原则，也应该是任何软件开发的通用原则，因为我能体会到这些原则对软件开发的促进作用。

人性化

是人在开发软件，这个不能回避的简单事实让绝大多数方法论的建议变得无效。软件开发通常并不符合人的需要，也没有承认人性的弱点和平衡人的力量。如果忽视软件是由“人”编写的，参与者会付出高昂的代价，非人性化的过程不承认参与者的需要，这会腐蚀掉人性。同时这对业务也没什么好处：会因为人员更替带来不必要的成本和断层，也失去了创新的机会。

成为一名优秀的开发者需要什么？

l 基本安全感：没有饥饿、身体伤害和对所爱的人的威胁。害怕失去工作会导致这个需求受到威胁。

l 成就感：为社会做贡献的机会和能力。

l 归属感：参与团队并从中得到认可、责任和为共同目标做贡献的机会。

l 成长：拓展自己的能力和前途的机会。

l 亲切感：与团队其他成员之间的高度理解和被理解的能力。

作者选择了这些实践，是因为它们满足商业和个人的需求。其实还有其他的人性化需求，如休息、锻炼和社会化，但这些并不需要在工作环境中得到满足。团队工作之外的时间可以给每个成员更多的活力和视野，并在工作时间把它们带回给团队。限制工作时间就是为了给其他人性化需求挪出时间，从而提高每个成员在团队工作时的贡献。

团队软件开发的部分挑战来自于如何平衡个人和团队的需求。团队的需求可能与你个人的长远目标相符，所以一些牺牲也是值得的。但总是牺牲个人的需求来满足团队的需求是不可取的。如果我需要私人空间，那么我就需要寻找一种既能满足自己的需求同时又不伤害团队利益的途径。伟大团队的魔力就在于，在团队成员间建立相互信任之后，他们发现合作工作的结果是导致每个人都可以更加自我。

要尽量区分个人的生活与团队工作：隐私的事情只同我的爱人谈论，个人的事情只同我信任的人谈论，公开的事情则可以同任何人谈论。在办公场所给他人讲私人生活细节时（也许你讲得很兴奋），但别人会感到尴尬、无趣或不舒适。

经济学

必须有人为所有这些买单。不考虑经济学的软件开发会有导致空洞单纯的“技术性成功”的危险。要确定你正在做的东西有商业价值，符合商业目标和商业需求。例如，首先解决最高优先级的业务需求会使项目的价值最大化。

经济学上影响软件开发的两个方面分别是：金钱的时间价值，系统和团队的可选择价值。金钱的时间价值是指：今天的1块钱比明天的1块钱更值钱。提前挣钱和推迟花钱都会提高软件开发的价值。明确的增量设计能将设计投资推迟到最后不得不花钱的时候。“依用付费”提供了这样的途径，每次新的功能一部署都可以得到相应的收入。

软件开发的另外一个经济学价值来源于可应对未来选择的价值。如果我能重复部署我的系统来应对各种类似业务，那么它将会比仅用于原来的实现目的更有价值。

所有的实践都是为了增加软件和团队的可选择价值，同时牢记着金钱的时间价值，不在没有把握的地方投资。

互惠互利

每项活动都应使所有与其相关的活动获益。互惠互利是XP中最重要的原则，也是最坚持的原则。任何一个问题总是有让某人付出代价而其他人获益的解决方案。危急关头，这些解决方案似乎很诱人。但是这么做一定是净亏的。因为产生的病态意愿破坏了我们需要重视的人际关系。计算机问题其实是人的问题，维系工作关系是很重要的。

大量的内部软件文档是违反互惠互利原则的实践范例。（有些人认为）我应该放慢开发速度，以便在潜在的将来，未知的某些人在维护代码时可以容易一些。如果这些文档将来仍然有效的话，可能会让将来的人们获益，但现在并不能使我们获益。

XP通过互惠互利的方式来解决“与未来交流”的问题：

l 今天我撰写了能帮助我更好地设计和实现的自动化测试，这些测试同样可以保留给以后的程序员使用。这项实践让现在的我获益，也让以后的维护者获益。

l 我非常谨慎地重构以消除那些偶然导致的复杂性，这既给我带来了满足感和更少的缺陷，也让后来者能更容易地理解他们碰到的代码。

l 我会从清楚且一致的隐喻集中选择名称，这些名称能加速我的开发，也使得留给新程序员的代码更清晰。

如果你想要人们接受你的意见，那你就应该解决更多问题，而不是创造问题。XP的互惠互利原则寻找这样的实践，它使现在的我、以后的我和我的客户都能获益。三赢的实践更容易被执行，因为它们能减轻眼前的痛苦。例如，某个被顽固缺陷纠缠的人很乐于学习测试先行编程的方法。一旦现在能使我获益，那么为帮助现在或将来的其他人做点事情就更容易被接受。

自相似性

大自然找到一个有用的形状，它会在能使用的地方到处使用，例如潮汐所形成水池的形状，虽然尺度不一样，但它们都有着相似的形状。这原则同样适用于软件开发：试着将一个解决方案的结构复制到一个新环境中，即使它们的尺度不同。例如，开发的基本节奏是，写一个不能通过的测试，然后让它运转。这种节奏可运行于不同的尺度。在一个季度里，你可以列出想要解决的主题，然后通过故事来解决。在一个星期里，你可以列出想要解决的主题，编写表达这些故事的测试，然后使它运转，再编写另外一个测试，使它们同时运转，直到所有的测试都做完为止。

在软件开发中，自相似性不是仅有的起作用的原则。仅仅因为复制在一个环境中起作用的结构并不意味着它能在另外一个环境中起作用。可是，它是一个不错的起点。同样地，仅仅因为一个解决方案是独特的（不适用于别的环境）并不意味着它不好。可能这种环境就是需要一个独特的方案。

改进

在软件开发中，“完美”是个动词，而非形容词。完美的过程是不存在的，完美的设计是不存在的，完美的故事也是不存在的。但是，你能使你的过程、设计和故事更加完善。

“‘最好’”是‘足够好’的敌人”表明了庸才更喜欢等待。这句话未理解XP的要点：软件开发的卓越是通过改进达到的。这个循环就是：做到你今天所能做的最好，为了明天能做得更好所必需的认知和理解而努力。这不意味着需要等到完美才开始做。

把价值观转化为实践时，改进原则表示为实践就是：马上开始行动，随着时间的推移逐步精华结果。根据经验改进长期计划，这个可能通过季度周期这一实践得到表现。增量式设计通过精华系统设计来贯彻改进原则。实际的设计永远不可能是理想设计的完美映像，但你可以通过每天的努力来使这两者接近。

软件开发技术的历史就是逐步减少耗费人力的历史。例如，汇编符号消除了将机器指令翻译成物理位编码这种烦闷工作的耗费：然后“自动编程”消除了将程序的抽象描述翻译成汇编语言这种烦闷工作的耗费；等等此类，直到存储单元的自动分配。

虽然改良的科技减少了浪费，但开发组织的社会结构增长的僵化和专业分工却在增加浪费。改进的关键之处在于使这两者协调：使用新的技术让更有效的新的社会关系成为可能。要在工作中改进，而不是等待完美。找一个起点，开始，然后改进。

多样性

如果一个团队的成员都很相似，那么这个团队虽然舒适但效率不高。团队需要将不同技能、态度以及看待问题和缺陷的视角整合在一起，来考虑解决问题和实现解决方案的不同方法。也就是说，团队需要多样性。

多样性不可避免地伴随着冲突。冲突不是“我们彼此痛恨，我们不能取得进展”的意思，而是“解决这样的事情有两个办法”。你将如何选择？

一个设计有两种想法，代表的是机会，而不是问题。多样性原则表示，程序员应该共同致力于问题的解决，两个观点都应该得到重视。

如果团队不擅于解决冲突怎么办？每个团队都有冲突。问题在于他们是否已经合理地解决了冲突。作者告诉我们：尊重他人，保持自我，可以使沟通顺畅。

反省

好的团队并不只是进行他们的工作，他们会思考如何工作和为什么工作。他们会分析为什么成功或失败。他们不会试图掩盖他们的错误，而是暴露它们并从中学习。谁都不可能突然间变为优秀。

在进行结对编程和持续集成时，季度和星期的周期计划中包含了团队中的反省时间。但是反省不应该被限制在“官方”场合。与配偶或朋友的谈话、假期、与软件无关的阅读和活动，都能给你提供单独的机会思考怎么和为什么你的工作方式是这样的。和别人进餐以及和咖啡也都提供了非正式的环境，大家可以互相思考和反思。

反省不是纯粹的智力锻炼。你能通过分析数据领悟到什么，你也同样可以从你的内心感觉中得知。像害怕、愤怒和焦虑之类的负面情绪始终暗示有糟糕的事情将要发生。虽然聆听你的情绪告诉你关于自己工作的情况需要花费精力，但通过理性调和后的感觉，却是领悟的一个来源。

反省可能会耗费太多的时间。软件开发长期以来有一个恶俗，就是人们是如此地忙于思考软件开发以至于没有时间去开发软件。反省紧跟着行动，学习是反省的行为。为了得到最大的反馈，XP团队中的反省是与行动结合在一起的。

流

软件开发的流是指通过同时参与所有的开发活动来交付有价值软件的稳定流。XP的实践倾向于活动的连续流，而不是离散的阶段。

长久以来，软件开发都是用大块的程序进行交付。“宇宙大爆炸”式的集成反映了这种趋势。许多团队应对压力的倾向是，减少部署和集成的频率，从而使程序块更大，——这会让问题变得更糟。反馈减少使问题更糟，导致更大的程序块。被延迟的事情越多，程序块就越大，风险也越大。相反，流的原则建议通过频繁地部署较小的增量来改善这种情况。

软件开发中几个趋势都和大批量处理的概念相反。例如日构建就是面向流的，但它是迈向流之路的一小步。仅仅每天编译和链接软件是不够的，还要保证软件的功能每天都能正常运作，最好一天运转几次。

机遇

要学会把问题看作是改变的机遇。这不是说软件开发中没有问题。但是，得过且过的态度会导致仅仅解决足够的问题而蒙混过关。要达到优秀，就必须把问题转化为学习和改进的机遇，而不仅仅是得过且过。

你也许不知道如何解决一个问题，你也许希望有更多的时间来考虑。有时候对更多时间的渴望是一个面具，它背后隐藏了我们对开始行动的后果的恐惧。尽管有时候耐心本身就可以解决问题。

将问题转化为机遇，这可以发生在整个软件开发过程中的任何时候。它将优点最大化而将缺点最小化。难道不能制定精确的长期计划吗？OK，可以制定一个季度周期，在其中精华你的长期计划。单个人可能犯太多的错误？Ok，结对编程可以解决这个问题。这些实践确实是有效的，因为它们解决了长久以来人们共同开发软件的问题。

当你开始实践XP，你肯定会遇到问题。极限的一部分意思就是有意识地选择，将每个问题转化为机遇：个人成长的机遇、关系升华的机遇、软件改进的机遇。

冗余

没错，冗余。软件开发中关键的困难问题应该用几种不同的方法解决。甚至如果一种方案最终失败了，其他的方案还可以阻止灾难发生。冗余的成本不止是与没有灾难发生的情况相比多出来的那部分花费。

比如，缺陷会侵蚀信任，而信任能极大地消除浪费。缺陷是一个关键的困难问题。在XP中缺陷由多个实践来解决，例如：结对编程、持续集成、坐到一起、真是客户参与和每日部署。即使一个错误没有被你的搭档发现，它也可能被坐在同屋的其他人发现，或者下一次集成时被发现。这些实践中有一些确实是冗余的，它们会发现同样的缺陷。

但你无法用单一的实践来解决缺陷问题。缺陷问题非常复杂，有太多的方面，永远不会被完全解决。你所能期望达到的只能是，使缺陷少到足够在团队内部以及团队和客户之间保持信任度。

失败

如果继续下去有困难，那么你就选择失败。不知道实现一个故事的三种方法中哪一种可行？那就尝试所有三种方法。即使它们都失败了，你肯定还是会学到一些有价值的东西。

失败不是浪费吗？不是，如果它能够产生知识的话。知识是有价值的，这种价值有时候很难获得。失败也许是不可避免的浪费。如果你知道实现故事的最佳方法，你只需用那种方法实现它就可以了。如果你不知道，找到它最经济的办法是什么呢？

作者曾指导过一个团队，其中有几个不错的设计师，他们是如此出色以至于每个人都能够对任何问题提到两到三种解决办法。他们一坐就是几个小时，依次讨论各自的想法。到讨论累了的时候，花费的时间足够他们将每种可能的方案实现两次了。他们不想浪费编码的时间，然后取而代之的是，他们浪费了花在讨论上的时间。

作者给这个团队买了一个厨房定时器，并要求他们把设计讨论的时间限制在十五分钟以内。时间一到，他们中的两个就应该去编码实现一些东西。那个计时器他们只用了两次，但他们把它保留下来以提醒自己：失败好过（无休止的）讨论。

这不是说，在你真的知道如何能做到更好的时候故意找借口失败。但当你不知道要怎么做的时候，冒一点风险失败可能是通向成功的最短最稳妥的道路。

质量

通过牺牲质量来控制的手段是没有效率的。质量不是一个控制变量。项目不会因为接受低质量而加快速度，也不会因为要求更高的质量而使进度减慢。要求高质量通常导致更快的交付，而降低质量标准通常会导致更晚的不可预见的交付。

质量不是一个纯粹的经济因素。好的质量会让开发者自己感到自豪。

不能通过控制质量来控制项目，那该如何控制项目呢？时间和费用通常是固定的。XP选择了限制范围作为计划、跟踪和驾驭项目的基本手段。范围是不可能预先精确知道的，因此它是一个好的杠杆。以星期和季度为周期跟踪和选择范围提供了明确的时间点。

关心质量不是不行动的借口。如果你不知道做一项必需要做的工作的明确方法，那么尽你最大的努力去做。如果你知道但是需要的时间太长，那么用你现在所拥有的全部时间去做，稍后想办法完善它。这个经常发生在架构演化的时候，你不得不面对两种解决同一问题的架构，从其中一种转变到另外一种。这个转变本身也是一个如何保证质量的示例：用一些小的、安全的步骤来高效地实现大的改变。

婴儿步

人们总是试图大步地进行大的改变。毕竟有一段很长的路要走，而且要在很短的时间内抵达。但突然间发生重大改变是危险的。被要求改变的是人，而改变是令人不安的，人们适应变化的速度毕竟是有限的。

婴儿步并不是说多慢或者停止变化。在适当的条件下，人们和团队可以非常快地迈出很多的小步，以至于看起来就像是在跳跃前进。

婴儿步的观点认为：相比于团队终止失败的大改变所引起的消耗，多个小步前进的代价要少得多。

接受责任

责任不能被指派，只能被接受。如果有人试图给你责任，只有你自己能够决定是否负这个责任。

接受责任对应的一些实践，比如，负责实现故事的人最终也负责这个故事的设计、实现还有测试。

责任和权力需要并行。两者错位会扭曲团队的沟通。当一个人告诉我该怎么工作，却不承担这些工作及其后果的时候，权力和责任就错位了。我俩都无法从一个理智的角度出发看待或使用那些有助于我们改进的反馈。另外，错位还要付出情绪方面的成本。

屈剑峰

2010-02-11