作者：戴维·斯科特·伯恩斯坦（David Scott Bernstein）
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
修改软件的艺术：构建易维护代码的9条最佳实践试读：
本书赞誉
本书从全新的视角展现了现代软件开发流程。工程师们会在其中找到解决日常问题的方案，而非工程师们可以对软件开发中所面对的挑战和困难有所认识。——Stas Zvinyatskovsky，埃森哲公司资深首席软件架构师
David帮我们认清了我们是如何陷入此番境地的。他给出了行之有效的理论和工具，也提出了一些值得深刻思考的问题。对于关心软件开发的人来说，本书是一份厚礼。要善用它。——Ron Jeffries，RonJeffries.com
如果你想要优化软件交付流程，但是感觉到裹足不前、无能为力，那么这本书正适合你。对于开始频繁迭代交付以及尝试采用敏捷却未见显著效果的人来说，这是本好书。——Gojko Adzic，Neuri Consulting LLP公司合伙人
本书讨论的内容可以帮我让客户更加满意，也能让他们在需求出现变化时一直开心。——David Weiser，Moz软件工程师
对于所有的开发者和管理者来说，这都是一本好书，而且适用于各类公司的各类代码。——Troy Magennis，Focused Objective CEO
David的解释清晰明了，我甚至希望开发团队的管理者以及开发定制软件的公司领导们也能看看这本书。理解这些实践，将能构建出更经济、更易维护和扩展的软件。——Jim Fiolek，黑骑士金融服务公司软件架构师
书中的各种观点令人欣慰。如果可以让人们都遵从这些原则，我们的生活以及软件开发会变得更加轻松惬意。——Nick Capito，Unboxed Technology公司软件开发总监
我们努力让每一行代码成为真实产品的一部分。要找出让我们误入歧途的原因。要找到合适的方法，让你的团队在现在以及今后能更有效地开发出客户真正想要的产品。——Michael Hunter，极客，骇客，首席工程师，架构师序遗产
遗产是已经死亡的事物存留下的依旧影响着世界的那部分。
能留下遗产的生命是优秀的，但是软件并非如此。我们用温和的词语“遗留”来形容那些已经失去活力但是依旧运行的代码，让那些过去的决策持续影响着那些深陷其中的人。
软件和硬件要区分对待。我们称硬件为“硬”是因为它是固定的，没有工具是无法调整的。软件的“软”是指它由思想而生，通过代码来表达，加载到硬件中然后行使一些职责。
讽刺的是，代码在编写完成脱离开发者之后变得比硬件还难修改。
开发者通过编程的逻辑表达想法和需求，赋予软件生命。就像是无中生有一样，直到我们意识到所有的这些小心论证都是为了让这个新生命成为我们所期望的那样。敏捷
面对威胁与机遇的时候，反应迅速的组织被称为“敏捷”组织。一个敏捷的组织会吸取经验教训，不会被那些短期内不会修改的软件束缚手脚，无法行动。
一些思想者，包括我在内，选择“敏捷”这个词来形容我们都希望软件能拥有即刻适应需求变化的能力。这股敏捷的势力在新开发的软件中很强烈，而且不以任何形式消失，因为软件如此重要，它应该在这整个软件生命周期中持久旺盛。
这些思想者向那些“算命”的管理实践提出异议，它们要求软件开发者在一个合作的流程中对未来进行预估，然后根据那些预估的准确与否评判开发者。
这些思想者向那些“提前大规模设计”的开发实践提出异议，它们需要预料到所有可能的情况才能保证后面维护不至于出现“大问题”。
然后这些思想者将他们的建议用“软件开发宣言”的形式发布给开发者和管理者，这宣言在今天比在十多年前发布的时候吸引了更多的注意力。
宣言并不完美。它在两个方面有所欠缺。它的短小让读者以为它仅仅是些一般性观点而不是具体编写软件的特定建议。
同时，宣言标题中的“开发”也让读者认为仅仅是新项目才需要采用，到上线时就不需要了。奏效
受雇的开发者必须意识到，仅仅言听计从是不够的，他们有义务让交付的软件持续产生价值。
软件的复杂度可能因为不当的处理而加剧，成为程序员的负担，难以逃避。大部分的敏捷方法，尤其是本书，描述了在接受这种现实的组织中工作的方式。
这本书温习了那些实践，它们在最近二十年中被一遍又一遍证实了既有效但又难以实施。“名义上的敏捷”形容那些采用了在无数的书中描述的实践，却收效甚微的组织。本书将这些实践进行解剖，分析其背后的原因。只有牢牢地把握住敏捷的逻辑，才能判断“名义上的敏捷”的问题所在。
计算成本的不断下降，让真正的高质量软件的价值凸显了出来。哪里商业更迅速，哪里就有财富。在边界逐渐瓦解之时，任何生意都需要优秀的软件才能生存。
奇怪的是，激增的廉价计算机让编程更难了。多数的敏捷开发者，所谓的“多语言程序员”，知道他们的技艺在敏捷组织之外很难得到欣赏。
David Bernstein解释了为什么敏捷方法会起作用。他深入挖掘了自身的经验，用自己的故事展示了这些实践的价值。《修改软件的艺术》明确了成功使用这些实践并从中获取最大价值的前提。Ward Cunningham美国俄勒冈州波特兰市
引言
本书会帮你降低构建与维护软件的成本。
如果你是软件开发者，将学到一套实践方法以构建易修改的代码，因为代码在应用当中经常需要修改。对于和软件开发者合作的管理者来说，本书会向你展示为何引入这9个基本的实践方法，会使你的团队更加有效地交付软件，而不至于让软件演变成遗留代码。为此，你需要的不仅仅是一份技术性的任务清单，还需要对为什么有这些实践方法以及如何实施这些实践方法有着深刻的理解。
每天，我们都会因为遗留代码而损失时间、金钱和机遇。
不同的人对“遗留代码”有着不同的定义，但是简而言之，遗留代码就是指因为种种原因，格外难以修正、改进以及使用的代码。
这样的代码有很多。实际上我所见过的所有生产环境下的软件几乎都是遗留代码。
软件产业通常轻视可维护性，所以到最后，企业花在维护代码上的成本比一开始编写代码的成本还高。正如我们将在第2章看到的，软件开发的低效仅在美国每年就造成百亿美元级的开销，这可不仅仅是某份报告上的抽象数字。我们每天都受到遗留代码的影响。软件很昂贵，容易出错，而且难以改进。
业内外人士已经开始拉帮结派为某些项目管理方法论争论不休（其中不乏杰出的点子），但是为了更好地做出持久性的变革，我们首先要对软件开发的基础目标达成共识。
本书不仅仅是关于如何构建更好的软件，更是关于如何构建更好的软件产业。书中囊括了我身为专业开发者三十年所学的精华。我从业的头二十年都是在传统的瀑布式开发下度过的，系统分别按照设计、构建、测试的阶段开发。问题是，规划软件开发的方式充满了不可预见的问题，这迫使我们必须对质量和预算做出严重的妥协。
但是在最近的十年间，对我以及其他我认识的开始尝试极限编程（Extreme Programming，XP）的软件开发者来说，事情发生了改变。采用这种敏捷开发方法论之后，我们放弃试图在一开始把所有事情想明白，而是循序渐进地来做，每次只设计、构建、测试一小部分软件。
极限编程中的一些实践方法，诸如测试驱动开发和重构，在构建和扩展软件过程中降低风险和成本方面给我上了重要的一课。这些实践方法的应用呈现给我各种各样的解决软件问题的方法。是否能利用这些实践方法，揭示出构建高质量、高可维护的软件的方法呢？
我的回答是响亮的“能”！
在程序员生涯初期，我被指派去从标准普尔的feed中整理股票数据，并将数据发送到客户的私有数据库中。在此之前，这一过程都是手动完成的，容易出错而且平均每天需要花费十四小时完成。我需要将这一过程自动化，但是对于如何找到最佳的解决方案，一开始我却摸不着头脑。
几周之后的某一天，在已经写了四十多页代码之后，我突然灵光一闪，有了重组数据处理方式的想法。在几个小时之内，我就完成了这个项目并且将代码削减到只剩下五页。那天早上开工时预计要花几个月完成的工作，结果在当天下班前就完成了。从那时起，我有过多次灵光一闪，甄别出藏在问题之下的规律，而这些规律让我能够迅速地构建出高可维护的解决方案。
这仅仅是一个例子，说明同一问题的不同解决方式之间有着巨大的效率差别。我从其他开发者那里听到过许多类似的故事。也许你也有灵光一闪之后，问题化繁为简的故事。
以我的专业经验，效率极高的开发者和一般开发者之间的差别可以非常大。我花了职业生涯中的大部分时间，研究那些罕见的、比一般软件开发者效率高数倍的个例。我了解到，那些人并非生来如此。他们仅仅是形成了一些和我们不同的特质，也许是遵循一些不同寻常的实践方式。所有的这些都是可以后天习得的技能。
作为一个新生的产业，我们依然在摸索着，并且学着去抓住重点。构建软件和构建实体物品不同。也许，软件产业面对的一些挑战乃是植根于对软件开发本质的理解误区。为了理解软件开发，使其可以预估，软件开发被拿来和制造业以及土木工程相比较。尽管软件工程和其他工程领域有着相似点，但是有些基础性的差异对那些不是日常编写软件的人来说不那么显而易见。
软件工程和其他形式的工程不一样，这一点并不为奇。医学和法学并不一样，木工和烘焙并不一样。软件开发与且只与一个东西一样，那就是软件开发。我们需要一些实践方法，使我们能够更高效、更可校验、更容易做出更改。如果我们能做到这些，就可以削减构建软件的短期成本，并且完全消除维护它的那些可怕的长期成本。
为此，我给出来自于极限编程、Scrum和精益等敏捷方法论的9种实践方法。当这9种实践方法不仅被应用而且被彻底理解的时候，它们可以帮助我们避免编写的代码在将来变成遗留代码。
尽管还有很多近乎无法修复或者已经濒临废弃的代码，我们依然可以利用相同的实践方法，慢慢地在已经堆积成山的遗留代码之中找到出路。
这9种实践方法将帮助开发团队构建更好的软件，并且帮助整个产业避免浪费金钱、时间和资源。
我见证过客户如何受益于这些实践方法。那些客户曾构建了一些有史以来最大、最复杂的软件。我知道使用这些实践方法可以产生非凡成效，但是仅仅“使用”它们并不能确保有成效。为了正确使用它们，我们必须理解这些实践方法背后的道理。
这是一个令人着迷的时代，而我们身在其中。当我们作为先行者在未知的领域里探险时，会有灯光为我们照亮方向。本书中的9种实践方法照亮了我的软件开发之路。我希望它们也成为你的指路明灯。如何使用本书
本书探讨软件开发，但并不是非得成为软件开发者才能理解本书。
软件的编写过程对于大多数人来说可能是个陌生的概念，但是它却影响着我们所有人。它已经成为了一个如此复杂的活动，以至于开发者经常发现自己在试图给客户甚至经理解释各种概念，可能没有一点参考。本书有助于架起沟通的桥梁，用通俗的语言解释技术概念，帮我们在究竟什么是优秀的软件开发这个问题上达成共识。
尽管让不同类型的读者针对技术实践方法达成共识并非易事，但本书的设计目标是为了帮助5种不同的人群对软件开发拥有同样的理解：● 软件开发者● 软件开发和 IT 经理人● 软件购买者● 各个行业的产品经理和项目经理● 其他所有对这个重要技术感兴趣的人
我试图让软件开发对于所有人来说都容易理解，通过讲述故事并利用大量的轶事、类比和隐喻将技术概念形象化。软件开发难以一概而论，所以从我所说的话中找出反例是很容易的，但是通常都会有更深层次的见解尚待发现。
为了让非开发者也能够阅读本书并关注这些实践方法的重要性，本书并没有按照教程方式编写。关于撰写用户故事以及重构等各个方面，已经有许多优秀图书了（见参考文献）。尽管本书也提供了很多实际的建议，但是它最特别也是最有价值的地方是探讨了为什么这些技术实践方法会有用。这种方式能让那些非开发者（如管理人员和其他利益相关者）明白开发者在构建软件期间面临的问题和挑战。第一部分：遗留代码危机
在第一部分，我们将直面软件产业发展的若干重大问题，并且发现由于糟糕的软件开发流程导致每年数十亿美元流失。
大部分维系我们生存的软件易出错、脆弱并且近乎无法扩展，也就是我们所谓的“遗留代码”。这一部分将探讨我们是如何变成现在这样的，这样的情况又意味着什么。探讨不仅针对软件产业，而且针对所有与其相关的人和产业。
如果你已经对软件产业耳熟能详，甚至已经深感疲惫，将会对这些内容“倍感亲切”。你将会更加深刻地理解为什么在软件构建过程中，事情总无法按照计划执行，以及为什么需要更好的方法。
即使对于业内人士来说，第一部分也可以帮助他们从适当的角度来看待这些巨大挑战。管理人员和开发者都可能会从这些问题中发现全新的视点，而这些问题对我们这个产业来说是每天都在发生的。正如一位经理对我说的那样：“它使我的炮火更加精准。”本书可以帮你说服他人：在解决问题之前，至少我们必须识别出问题所在。
如果你是软件行业的局外人，我敢保证第一部分会让你称奇，甚至震惊。第二部分：延续软件生命（和价值）的9种实践方法
在第二部分中，由于之前已经说明了问题所在，本书剩下的四分之三将从阴暗压抑中走出，介绍一套实践方法，提供真实、可操作的解决方案，首先是一些对管理者特别有用的实践方法。
在第5章和第6章，我将提出一些自己实践后总结的建议，不仅针对如何更好地开始实施复杂软件的开发流程，还针对如何一路把控流程直到完成。这两个实践方法对于软件行业以外的人会非常有用，同时我也提供了适用于任何项目管理环境的建议。实施这些实践方法后，你将能够：● 更加高效地执行任务● 节约短期和长期成本● 构建更高质量的软件● 增加客户的满意度，带来回头客
接下来是我在职业生涯中发现的非常有效的7个技术性实践方法。这些方法更适合软件开发者。
我见过这些实践方法的成功与失败。有些软件开发团队运用了最好的实践方法，但是技术很差，所以无法获取所期望的价值。成功运用这些实践方法的团队和那些失败的团队之间的差异是，失败的团队没有弄明白这些实践方法为什么如此重要。而这正是本书所强调的。
即便这些是技术性的实践方法，我也想敦促管理者们（任何行业的管理者）以开放的心态了解这些基本的概念。了解你管理的开发者所面对的挑战，跟他们分享这些实际的、可以迅速上手的实践方法，帮助在破碎不堪的流程中苦苦挣扎的团队提高效率与效益。
当你读到这些实践方法的描述时，我希望你在思考如何在项目中实施之前，先想想这些实践方法为什么有其价值，这样会帮助你更加有效地运用这些实践方法。
虽然我建议阅读（并应用）这9个实践方法，但是可以按照任意的顺序去执行。我当然意识到本书的每个读者都有具体的问题和需求，所以我将第二部分组织为9个独立的实践方法。专注于那些对你最有帮助和能快速生效的方法，但是不要止步于此。我并不想独树一帜，而是想抛砖引玉
如何阅读本书，从中有什么样的收获，全在于你。我努力避免玩弄“敏捷”“Scrum”“极限编程”这样的词汇。我希望本书改变人们对于软件开发这个新兴产业的看法，使其进入主流的视野。我希望在软件开发社区里展开讨论，这个社区常常拉帮结派对细节争论不休但缺乏大局观，我们不应该做井底之蛙，而应该基于一个共同目的分享想法，这个目的就是：尽一切可能构建最优秀的软件。线上资源
本书的代码示例可以在Pragmatic Programmers网站上的本书主页（http://pragprog.com/book/dblegacy）找到。你也可以在论坛中提问并得到回答，还会发现一个可以提交错误报告的勘误表，等等。
致谢
首先要感谢我的妻子 Staci Bernstein给了我编写本书所需的空间以及一切支持，让我可以完成夙愿，还有我们的迷你杜宾犬Nicki，它在我写作、编辑的时候时刻陪伴着我。
其次我要感谢 Ward Cunningham 为本书编写了序，感谢他给予我的所有鼓励。
写一本书是一项重大的任务，而本书依仗许多人的支持，对此我深表感激。感谢我的伙伴、同事，以及客户在我写作此书过程中给予的探讨和支持。
我还要对本书的审阅者深表感谢，他们将自己的时间和经验无私地投入本书，提出宝贵意见，才让本书更加优秀，尤其感谢 Scott Bain，Heidi Helfand，Ron Jeffries，Jim Fiolek，Stas Svinyatskovsky，Ed Kraay，James Couball，Pat Reed，Stephen Vance，Rebecca Wirfs-Brock，Jeff Brice，Jerry Everand，Greg Smith，Ian Gilman，Llewellyn Falco，Fred Daoud，Michael Hunter，Woody Zuill，GojkoAdzic，Troy Magennis，Kevin Gisi，David Weiser，Nick Capito，Sam Who，Michael Hunger，Ken Pugh，Max Guernsey，以及 Chris Sterling。
最后，我要感谢在过去三十年中参加过我课程的数千名软件开发者。我非常感激从你们那里所学到的东西！第一部分遗留代码危机
只有我一个人这样吗？其他人是否也注意到——或者在乎——有那么多的软件并未按照期望的那样工作，或者没有正常工作多长时间，而且近乎无法修补。
软件远远达不到100%的成功。但是软件行业到底情况如何？有多少软件项目是成功的？我们对于成功和失败的定义又是什么？如何度量它们？
我向很多人问过这些问题，软件行业内外的人都有。许多软件行业外的人觉得这样问很奇怪：“你说有些项目竟然不成功？”但是软件行业内的人却倾向于问：“你的意思是有的项目竟然成功了？”第1章有些事情不对劲
有些事情不对劲。
组织内部毫无信任可言。繁重的软件开发流程处处碍事，让他们再也无法生产代码。整个公司陷入死亡的漩涡，总价值七亿五千万美元的生意危在旦夕。
你也许是这个团队核心开发人员中的一位。这些核心开发人员十分杰出，但是同时也会有二等的初级开发人员，以及一些编外的或者第二梯队的团队，他们允许混入一些“码农气息”的短见，只关注眼前一个功能，而不是这个功能如何与整个系统整合，而且意识不到，他们在做的这些事情中有些将会在短期内引发大问题，并且在以后导致更加严重的后果。
即使由聪明的、经验丰富的专业开发者带领开发工作，创造出的软件依然不符合标准并且难以使用。整个开发团队不清楚技术实践背后的原因。他们在这里偷工减料，那里钻个空子，建立一个个“小团队”甚至各自为战，各自使用不同的标准，而对整个系统只有片面的认识。这让代码集成变成了没人愿意看到的噩梦般的体验。
或者你是管理者中的一员，负责让这个软件开发完成、交付、盈利而非亏损。这些管理者聪明而且经验丰富，但到头来也和开发者一样，身心俱疲，甚至失去信心。公司管理者看到最后期限被推迟，眼看着不稳定的预发布版本被推上线，而又不知道说些什么能帮开发者们把事情做好。所以管理层的应对是加入更多的流程，愈发地破坏团队的信任，进而让最后期限一再推迟。
在各种组织中，开发人员、质量保证人员、实施人员之间总是会衍生出敌意，这家苦苦挣扎的公司就是这样。开发者和管理者都不明白为什么他们要反过头来重新审视他们的工作，事实是他们的燃尽图让他们不得不这样。
我是他们雇佣的第三个顾问了，而且是第一个不把他们的问题归结为“人为因素”的人。我看到的是一个遗留代码的问题。他们的软件脆弱且难以使用。公司在过去的十年中飞速发展，他们的代码却因此受到了连累。
公司曾经尝试“敏捷”过几年，但是即使他们的许多团队施行了一些敏捷实践，他们已有的代码依旧碍事，使得预估不准确进而拖慢进度。他们知道必须解决他们已有的遗留代码，以及那些一路养成的让他们陷入这般境地的坏习惯。
我们关注本书中的这些实际的工程实践，以及它们的原理。当我说这些开发者和管理者是聪明的经验丰富的专业人士的时候，我不是在开玩笑。他们认真倾听，将自己投入到一个需要自我改变的合作过程中去。他们对修改软件和流程的问题下了必要的功夫。
如果你是这些开发者中的一员，你将发现你不再会在凌晨三点钟由于系统停机被叫起来。你开始变得迅速，从你添加的测试得到正确反馈，让你明白你的代码正如你所预期那样执行。与团队的其他成员一起，将20%的时间花在清理已有的代码上，你们会见证这些努力在将来的一年内得到的丰厚回报。
如果你是管理团队的一分子，你会看到团队成员合作更加有效率。你将不会再担惊受怕由于一些“关键资源”（主要开发者）决定换个工作，剩下的人无法维护那个人的代码，进而使公司遭受打击。你会看到团队中开发者的态度发生了变化，开始处理遗留代码问题而非视而不见。
虽然花了几个月，但是随着代码的改进，团队的速度也变快了。团队的规划变得更稳妥，他们开始连续地按期完成而不偷工减料。
他们开始打破心理上和空间上的围墙了。部门之间开始沟通。他们通力协作，开始重构质量保证和需求控制的方式。测试人员和开发人员坐在一起想办法自动化测试他们的待发布版。最终，从耗时两周的大量手动测试过程变成一个完整的自动化测试过程，大部分情况下只花费不到两分钟。这样做，每年为公司节约了大量的金钱，也为组织结构改革提供了基础。
简而言之一句话：人们开始上心了。
这是一个真实的故事。我看着它一次又一次上演。如果你是软件开发者，或者你管理软件开发者，害怕正朝这个死亡漩涡一头栽下，那么本书会让你了解这个公司是如何扭转局面的。如果你正挣扎求生，要知道，你不是一个人在战斗。
软件开发和维护的方式中有什么东西不对劲。但是并不是非得如此。1.1 什么是遗留代码
软件开发是世上独一无二的工作。当我们理解了它的本质以及它需要持续更新的特性后，就可以找到许多方式来增强所编写的代码的健壮性，进而降低维护和扩展的成本。
Michael Feathers在他的《修改代码的艺术》[Fea04]一书中，提出了当我们听到“遗留代码”的时候会想到什么：如果你也和我一样，那么大抵会联想到错综复杂的、难以理清的结构，需要改变然而实际上又根本无法理解的代码；你会联想到那些不眠之夜，试图添加一个本该很容易就添加上去的特性；你会联想到自己是如何的垂头丧气，以及你的团队中的每个人对一个似乎没人管的代码库是如何打心底里感到厌烦的，这种代码简直让你生不如死。你内心深处甚至对于想一想怎样才能改善这种代码都感到痛苦。这种事情似乎太不值得我们付出努力了。
我们知道软件是如何演变成遗留代码的。和其他事物一样，软件也有一定的生命周期。程序被创造、使用、修补，最终淘汰。软件像生物一样，如果它赖以生存的操作系统被淘汰，也会死亡。正如医生一样，软件开发者能做的最多是推迟大限的到来。如果病患术后的生活质量比之前得到了提升，则治疗是成功的。但我们都清楚，我们所有人都有大限将至的一天，软件也一样。
在一个程序的生命中，代码被修修改改，使得原本的设计变得脆弱，所以软件变得越来越难用。由于许多现如今编写的软件通常都是难以变更的，最后我们往往是替换代码而不是修复代码。
一种全新的被称为“软件考古学”的领域因这种情况而兴起，这一名称在2002年被《程序员修炼之道》的作者Dave Thomas和Andy 1Hunt提出。当我面对一个多年前构建的、没有文档、变量命名糟糕的软件时，有时候会觉得，考古学家在从一块陶片中窥视一个失落文明的秘密的时候一定也是这种感觉。简直是无以为继。
Hunt, Andy, and Thomas, Dave. “Software Archaeology.” 1Software Construction/IEEE Software March/April 2002. http://media.pragprog.com/articles/mar_02_archeology.pdf
当我们深入观察软件构建过程中的缺点时，可以发现这些缺点是如何导致遗留代码的产生和繁衍的。如果可以意识到预估一件我们从未做过的事情的时间、成本和进度是多么具有挑战性的事情，并意识到软件工程和其他工程学巨大的差异，我们才能开始了解遗留代码是从哪里来的以及该如何应对。
Michael Feathers进一步把遗留代码定义为任何没有测试的代码。这是因为他和我一样，十分重视优秀的自动化单元测试，这些测试可以使代码更健壮并保证其表现得和预期一样。
良好的单元测试的前提是你有优秀的、可测试的代码，但对于遗留代码来说经常并非如此，所以你必须清理代码，使其处于更好的状态。这通常说起来比做起来容易。让不可测试代码变为可测试可能需要重新架构整个系统，即使有些技术手段作为辅助，也需要大量的工作。
对于遗留代码，没有简单的答案，没有快速的修复方式。在第2章中，我们会看到到底这个问题有多么普遍，又是对软件产业造成了多少损失。一个如此巨大的问题让我们需要退后一步，从整个不同的角度去审视它。如果过去实施的方法并未奏效，那么我们也许需要寻找其他的解决方案。1.2 顺流直下
瀑布模型是从制造业和建筑行业借鉴而来，最早于1970年由2Winston Royce提出。它是一系列用于软件构建的阶段——但是他紧跟着又在下一页说这样的流程不会起作用。显而易见，从来没人读到过那里。
http://agileconsortium.pbworks.com/w/page/52184647/Royce2%20Defining%20Waterfall
一度作为软件构建的主流方法，瀑布模型的概念很简单，提供了7个独立的步骤，按照如下顺序进行。
需求分析
从对应领域的专家和潜在用户那里收集信息，从而建立一个需求文档。需求文档是一系列要求，指导我们在当前发布版本中应该实现哪些功能。功能就是软件的种种职责。
设计
接着是要根据写好的需求文档去设计软件。这些设计的形式通常是设计图例和其他表达设计思想的产出物。这并非代码，相当于另一个文档：如何构建软件的图例和描述。和蓝图不一样，蓝图是对建筑的每个细节的事无巨细的表达，但是软件的架构远谈不上精确或者全面。
实现
在设计之后是实现阶段，这个阶段代码被编写出来以满足设计。编码就是单纯地完成设计产出物中描述的设计。
集成
在所有代码编写完毕之后开始集成阶段。在集成阶段中，所有团队成员编写的代码放到一起。这通常是第一次所有代码被编译到一个计算机程序中。
测试
一旦软件集成完毕则测试阶段开始，验证软件表现是否如预期的那样。这个阶段包括对软件执行一系列的测试用于证明软件正常工作。
安装
在安装阶段，软件发布给用户。此阶段可能包括将载有程序的CD邮寄给用户或者在线上提供软件下载。
维护
最后，就是对软件进行持续维护：修复问题，添加新功能，提供更新。
瀑布模型在桥梁建造或者制造小物品时意义重大，因为将需求整合投入生产的方式更加高效。但软件开发并不是一个制造业的流程。软件开发者不是通过预先生产好的部件组装程序。当然，有些软件部件可以提前构建，但是大部分我们所需的组件要自己构建或者修改，甚至研发。直到真正需要使用之前，我们很少知道要构建、修改或研发什么样的组件，更不用说如何加固我们的架构了。1.3 孤注一掷
我们在瀑布模型开发的项目中持续累积风险的方式，和在拉斯维加斯赌博的方式有着惊人的相似。
在传统的瀑布开发中，为了让一个部分正常工作，所有其他部分必须都能正常工作。程序员并不知道他们的代码和系统其他部分配合得如何，直到集成阶段——发布前最后的阶段之一——所有的独立代码才组合到一起。
直到最后阶段才做集成，基本上是在玩轮盘赌，而且连中十次才算赢。
整个过程中一个错误，甚至一行代码的问题，就会造成整个程序没法编译成可执行代码，或者编译成功但在执行的时候崩溃。这就是我们所谓的“bug”。
许多bug都是只在集成阶段才会出现。我们在项目的最后阶段才集成代码，这给开发过程带来极大的不确定性。由于已经进入集成阶段，任何必要的修改和奇怪的bug都会成为严重且代价高昂的问题，需要付出大量的努力（以及附带的成本）去修复。我难以想象，还会有其他编写软件的方式比这样风险更高、更容易出错。
这就是为什么在软件开发中最后一刻的修改会有如此昂贵的代价。它需要大量的人力去重新测试和集成代码。有可能一个局部的小改动会影响程序的其他部分，所以通常情况下都会谨慎地重新测试整个系统，无论系统中哪个部分作了修改。如果整个过程是手动进行的，成本会极高，而且会阻碍最后一刻的一切修改，这些修改可能来自于重要的信息或者是开发后期才产生的更好的主意。1.4 为什么瀑布模型不管用
当软件以一个长的发布周期构建的时候，开发者可能在他编写代码几个月后才能看到它执行。开发者可能会建立一个测试场景来让他们的代码可以被调试器（一种帮你检查其他软件中bug的软件）管辖，然后一条语句一条语句地执行，但是这和代码本来应该在的整个系统的上下文环境中执行完全不一样。
这是将不同功能打包成成品的构建方式的主要缺点之一。先部分后整体非常符合直觉，这是我们建造东西的方式。如果你在盖房子，你会希望打地基需要用的所有东西都在手边，而不是停下来等着混凝土或者其他东西被送来。你也会希望所有的木材到位，不用花钱请木匠干坐着等顶梁或者其他什么被送来。
这是现实事物和虚拟事物之间主要不同之一。事实证明，先部分后整体的方式在虚拟世界并不奏效。
并不仅仅是因为这种方式效率低下——我们会在考察不同发布周期优劣的时候讨论这种低效——而是它让我们建造出来的东西难以改变。这个问题看上去非常不明显，却至关重要。
仅当增量构建时，你可以在其中增加些伸缩缝以便后期扩展。你在优化构建持续发布软件过程中从没这么想过。在瀑布模型中，这从来不是重点也不是问题。没人会在盖房子的时候想着以后加上额外的房间。蓝图怎么画的你就怎么盖。现实中又有多少人会想在房子里增加额外的房间呢？相比之下，向软件中加入新功能又是多么得频繁。1.4.1 食谱与配方
食谱和配方有所不同。举例来说，你可以根据食谱制作意式番茄罗勒酱，它尝起来和其他厨师按照同一食谱制作的酱一样，但是仅仅是在严格遵循食谱的前提下。如果一个厨师加了点胡椒，另一个厨师多用了点罗勒少用了些牛至，虽然做出来的依然是意式番茄罗勒酱，但味道不同。另一方面来说，如果两个面包师烤面包，其中一个改变了水、面粉和酵母的比例，面包就会发不起来——面包也就完蛋了。烘焙面包需要的是配方。
我们必须停止将软件开发视为配方，应严格按照细节执行，将其看作食谱，让不同的主厨可根据独有的理解依不同情况做出调整。
除了其中一些最乏味的任务以外，编程并不是一种“按图索骥”的活动。许多任务需要开拓新领地，进入没有前人涉足的地方。软件开发有许多禁忌，在一种场景下“正确”的方法在另一场景却会失败。
这种前途未知的情况迫使传统的瀑布流程为了预估和简化诸多的未知而变得越来越复杂。但是，使某样东西更复杂并不会自动让其变得更好，而且可能很容易就变得碍手碍脚。1.4.2 开发和测试分离“我的工作是尽我所能、尽快地完成安排给我的所有功能，而质量保证团队是我的守护天使，所以我可以草率些，大胆地去尝试，因为我的工作是做出粗糙的草案，然后交给这个‘共同作者’去完善它。”
作为软件开发人员，有多少次你这么想过或说过？或者你是管理人员，听人这么说过？但是质量保证团队真的不是软件开发人员的“共同作者”。质量保证人员所能说的就是：“回去再试试。哎，顺便说一句，你没什么时间了。”
将自己置于如此境地，我们该如何取胜？但是我们却习以为常，这是一个严重的问题，因为这会鼓励开发者不认真关注他们正在做的事情。
问题并非局限于瀑布模型开发。多数的软件开发项目依然有独立的质量保证工作，对待发布的版本进行耗时数天甚至数周的手动测试。
刺激与反馈要尽可能紧密结合以便改变我们的习惯。当开发者直到几个月后才看到行为的结果的时候，它已经变得不完全合适了。就像我们的人生座右铭：找出错误并非我的工作；创造错误才是。
正如瀑布模型一样，诸如“六西格玛”和“全面质量管理”等其他流行的项目管理方法学，在商品制造业上对持续性和质量都有着非凡成效，但应用在软件方面却一败涂地。讽刺的是，我们花了大量时间在注重方法论本身的检查和协调，却忽视了提高产品本身的质量。
传统的软件开发实践，关注着对未来的预计以及可预估的工作流，结果开发者和管理者都规避了过程中的繁杂特性，而仅仅关注于完成任务。1.5 当“流程”变成“体力劳动”
当我还是IBM的程序员的时候，我们有个规矩，每行代码都需要包含一句来自开发者的注释。这无意中鼓励了开发者对数据和函数使用糟糕的命名规范，因为可以使用注释来“解释”代码。人们开始阅读注释而非代码。在时间紧迫的时候，开发者常常更新代码而忽略了注释，使得代码和注释不同步。过期的注释比没有注释更加糟糕。这会使得代码成了谎言，而我们不希望代码中出现谎言。
假设有如下代码：x++; /* 此处 x 增一 */
我们并不需要“/* 此处 x 增一 */”这样的注释。我们可以假设读者理解编程语言的基础。冗余的注释在好的情况下是噪音，在糟糕的情况下则变为谎言，无论是否故意为之。
看到大量的“流水账注释”——那些并非描述代码缘由而是描述代码行为的注释——的时候，我会意识到写出这样注释的开发者格外担心阅读代码的人是否理解其代码的所作所为。代码应该是自解释的，应该通过优秀的命名和通行的用法使得软件易于理解。
冗余的注释成了编写低质量代码的借口。用块注释为一段代码提供大段的描述——而不是将该行为放入独立的私有方法中使其能通过见名知意的方法名来调用——会使代码难以阅读而且导致方法职责过多。
有充分的理由相信，IBM在这个注释规则背后的初衷是好的。事实上，我认为整个软件开发的“地狱之路”都是由良好的初衷所铺筑的，除非我们理解了软件开发的真正本质，我们实施的“解决方案”往往注定适得其反。
比如，我知道有一家公司在编写一行代码之前需要写十二个主要文档并且要求所有的部门主管签字，因为之前的失败导致了管理层和开发者之间明显缺乏信任。讽刺的是，他们大部分问题的根源正是繁复的流程，而非开发人员的不负责任。管理层以增加更多的流程作为应对，反而让事情进一步错乱。
应该假设在任何项目的开始时期，相关人员都是想尽力交付高质量产品的。但是不知为何，我们从准备充分且乐于奉献演变成了疏远而对立——准备钻钻空子。
人们在对事情的结果没有影响力或者仅仅觉得自己没有影响力的时候，就会感到被疏远了。这样的事可能每时每刻在我们身边发生着。反之，让人们参与到某件事情中的最有效方法可以总结为一个词：尊重。1.6 坚如磐石的管理
现代管理技术发展乃是工业革命的结果。那些早期的管理者们拿着秒表在工厂里面溜达，为做着不同任务的工人们计算时间，然后给出一个简单命令：快点！
但是在软件开发中，没有那些可以用一组标准评判完成质量的重复性任务让我们可以干得“快点”。当然，我们的手指在键盘上忙碌，但实际上是我们的脑子在工作，形象化，模型化，然后用代码使这些模型具体化。每个任务都是与众不同的，寻求解决方案需要不停学习新东西。
管理者希望保证他们的开发人员在做着正确的事情，但是更深层次的问题是：
究竟什么是“正确的事情”？
我们构建软件的目标是什么？遵循什么样的原则？许多其他领域的专业人士都能轻易回答这个问题，但是我未见几个软件开发者能给出答案。
为了回答“什么是‘正确的事情’”，管理者倾向于通过提高生产率（早期的产品线管理者用秒表），或者强制执行更复杂的计划，即使这样的做法往往适得其反，最后消磨人们的斗志。我们加入的流程越多情况越糟糕，因为流程无法支配创造力。我们必须认清软件开发本质上是一个创造过程。1.7 此处有龙
我们可以利用地图出行，计划旅途，可以清晰地标出A点和B点以及其间的最短路径。即使拉丁词语Hic sunt draconnes（意即“此处有龙”）没有如大部分人认为的那样出现在古代地图上，它也成为了对于有待探索的未知领域的象征。那些位于地图边缘的地方十分恐怖，充满了怪兽……而软件开发者深陷其中。
众所周知，依赖数字、图表和最后期限能让管理层——其实是几乎所有的人——感到安心。但是想在任何专业领域做出伟大事迹，都意味着要挑战未知，而未知是难以量化的。
既然软件开发常常在充满“龙”的土地上进行，我们为何要度量软件开发呢？又是如何度量？度量什么？
进行度量是为了找出待改进的部分，增加可预测性，减少风险等。除此之外，是为了在前往未知领域的征途中感到安心。度量是为了能合理地猜测项目所需的时间和成本。
但是无论多么合理，终究还是猜测。
最终，我们进行度量是让我们自以为一切尽在掌握之中。
然而这些都是错觉。
猜测和错觉可以给我们的前行提供信心，但同样会给我们虚假的信息，让我们误入歧途，而后为之付出代价。
不难想象，我们管理的项目挑战性越大，在过程中做出的量化就越不精确，至少有时如此。当我们构建虚拟产品时，必须习惯对过程有着更抽象的理解，在大多数人并不理解虚拟产品开发的情况下保证进度。
传统上来说，软件开发管理者需要创建用于系统设计、编码和测试的时间表。这种分段方法让每个人都能了解项目进展情况。不幸的是，这种方式时常演变成谎言。一个九个月的项目进行了八个月时，我们发现进度比预期晚了六个月。这一切是如何发生的呢？
其实我们一直是晚了六个月，只不过我们到了第八个月才发现而已，此时做什么都为时已晚。
管理者在给开发人员安排任务的时候常常询问他们需要多长时间完成，而开发人员常常说他们也不知道。开发人员并不是有意闪烁其词，也不是故意摆架子。他们只是不知道而已。坊间流传着一个关于软件开发的笑话：
开发者有三种状态：已完成，未开始，快完事了。1.8 评估未知
我们难以知晓某一任务需要的时间是因为我们从未做过。
有可能，事实上非常可能，我们少了一步。我们也许以为有些现成的代码会帮我们做些子任务，然后发现其实并没有，或者我们发现这一任务并非独一无二的，正好已经有一个库来完成我们所需的功能。最重要的是我们需要想透彻，而我们不可能像实际开发中那样有效地做到这点。
每时每刻，每天，每个月，每个项目，我们编写软件当中执行的任务都大有不同。当然，其中有些熟悉的事情我们每天都在做：设计、测试、编码等，也有些相似的技术我们每天都在用，也有处理问题的惯用方式。但是问题本身（以及它们对应的解决方案）常常和我们之前遇到过的大相径庭。
我知道有些公司（尤其是大公司）只给团队很少的时间去编码。很多时候还都是打着为了提高质量的旗号。
比如，花了很大力气用于编写内部设计文档并在开发过程中保持更新。在这样的开发过程中，所有的设计文档都一视同仁，但许多文档虽然曾经有用最后却被遗弃，显然不再有价值。
如果客户并没有花钱让我们编写这些额外的分析和设计文档，那么我们为什么还要这么做？答案是我们相信这些文档能帮助我们理解和表达问题，从而可以找到一个优秀的解决方案。但结果是我们常常花费大量时间在那些没有给客户带来价值的问题上。当我们关注于度量无意义的事情，诸如实际时间对比基于错误假设估计出的计划时间，那么我们就迈错了步子。
软件开发充满风险。少有能够顺利完成的，而且写出来的软件几乎马上就过时了。面对这不断增加的复杂度，传统的修复问题的方法是创立一个更好的流程。我们依赖流程告诉我们去做什么，保持我们步入正轨，保证我们诚实，确保我们的进度，等等。
这是瀑布模型开发背后的基本哲学。因为在开始的设计阶段之后便难以修改代码，我们禁止在设计完成之后再进行修改。因为测试消耗大量时间而且昂贵，所以我们等到项目的后期才统一进行。这种方式理论上行得通但是实际上却明显低效。在许多方面我们故意避免痛苦与困难，不是因为瀑布模型帮助我们构建更好的软件，而是因为它本身困难、耗时（至少比我们一开始预估的多）、花费更多金钱。1.9 一个充满外行人的产业
软件产业被称为外行人的产业。不幸的是，这句话在很多层面都是正确的。
关于软件开发者应该具备什么样的知识体系并没有广泛接受的共识，开发者有大量不同的方式去解决问题。掌握一门编程语言并不能使你成为软件开发者，正如掌握一门自然语言并不能使你成为作家。
如果学生将来以软件开发为职业，许多计算机科学课程并未给他们做好准备。这些课程通常关注编程的数学特性，但这不是大部分软件开发者的工作内容。这就像在你成为画家之前要求你必须证明你能解复杂的微分方程。软件开发者有着不同的背景，通常用不同的方法解决问题。结果是，沟通设计思想并达成共识成为了难事。
科学和工程学的课程来自于广泛接受的标准和实践，软件产业却少有这类标准和实践。部分是因为我们解决的问题是如此天差地别，部分是因为这是一个年轻的产业。
我认识的最优秀的程序员都是自己独立解决问题。软件行业中重复发明轮子的事情有很多。
在土木工程中，也许对建筑美学有争论，但是在建造层面上却不会有。在给定结构尺寸和使用材料的情况下，需要相应的建筑材料和一套规定好的建造流程。建筑建造的规范依照这些原则实施。软件的情况却并非如此。
我认为我们永远也不会有一本如《土木工程指南》那样的《软件工程指南》。土木工程是——并非双关——坚如磐石的，正如软件工程是行云流水般抽象的。软件开发是在一个我们无法看到、听到、闻到或者摸到的虚拟领域中进行的。
这让我们中的大多数人难以理解。我们不习惯想象抽象的事物，我们也尚未理解软件开发的背景。我们无法像描述物理世界中的重力那样描述影响着虚拟世界的法则。
当代医学中，希波克拉底总结出了至关重要的前提：“首先，勿做伤害。”医生的目标是治病救人，尽管有时候会为了拯救而损伤病人，比如锯掉感染的腿，最终目的还是挽救病人的生命。
但是软件开发中却没有对应的希波克拉底誓言——没有法则可以指导我们做出最好的选择。
软件开发流程中的每一步我们都会做出几乎无数个的选择。针对一定情况做出最佳权衡需要我们理解每个选项的所得所失。
为了解决本章开头提出的问题，无论是软件开发人员还是管理者都需要对软件开发的本质和软件随着时间变化达成共识，这样他们才能编写出可以更好应对变化的代码。我们必须填补基础认知方面的巨大空白。
软件产业面对的巨大挑战，对于那些准备正视它们且从中获益的人们来说也是巨大的机遇。这个年轻产业中的种种失败给我们指出了更好的方式，挑战着我们的基本假设，给我们展现了更优秀、更高效的工作方式。
所以我们必须要有勇气，不仅仅是提出一些困难的问题，而是要突破我们的固有观念、我们核心的信念和封闭的社区。我们必须共同回答这些问题，把软件开发变成更好、更高效、更可靠、更注重质量。1.10 回顾
大多数软件开发和维护的方式“有些不对劲”，在传统的瀑布模型开发环境下，我们要等到最后才能看到一切是否正常运转，当bug出现的时候，它难以修复，非常耗时，以至于追踪修复的成本很高。
本章中心思想如下。● 许多人不了解软件是如何构建的，软件又是如何演变成遗留代码（那些成本高且难以使用的软件）的，以及如何从一开始避免这
样。● 先分别开发功能再组装发布的方式效率低下。● 传统的瀑布模型流程导致遗留代码的产生和繁衍。● 软件工程尚未创建其核心的原则，也缺乏每个开发者都必须知道
的通用知识体系。
瀑布模型促进了难以维护软件的产生。瀑布模型方法学在构造建筑方面很有成效，但是构造软件的时候先分别开发功能再组装发布是高风险、高成本的。传统的管理技巧通常不适用于软件工程，开发者也没有可以共享的通用知识体系。
我看到了这些想法在我接触的项目中的负面影响，但不知道其他项目是如何深受其害的。接下来，我们会将软件产业视为一个整体看看它的情况如何。第2章逃出混乱
如果你和我一样，那你应该也知道现如今多数软件的开发与维护方式有着种种问题，但是却找不到问题的症结所在。没有这一数据，你可能无法说服你的团队成员或管理者，让他们意识到遗留代码不仅仅是一个商业成本问题，而且是一个真正迫在眉睫的危机。如果想避免重蹈那些失败项目的覆辙，首先需要意识到都有哪些关键问题导致了项目的失败。
软件产业总体来说是一个尚未被充分探索的行业，尤其是考虑到世界范围内有多少的其他产业和软件息息相关。斯坦迪什咨询集团（Standish Group）试图对这个年轻、复杂而又混乱的软件产业一问究竟。尽管他们承认数据可能不够全面，但的确可以让任何一位做过几天软件开发的人都能够清楚意识到，我们这个行业的成功率其实并不算很高。
我亲历过一些项目的苦苦挣扎甚至失败，但我从未想过整个行业都处在危机之中，每年都因为破败不堪的软件开发流程损失数以百亿计的美元。作为一个给全世界最大的软件公司做过咨询的人，我想知道我的经历是否属于典型。所以我把目光投向了行业中规模最大、最受关注且被广泛引用的研究：斯坦迪什咨询集团的“混乱报告”。2.1 混乱报告1
斯坦迪什咨询集团是一家专注软件产业的研究机构。他们最著名的研究名叫“混乱研究”（CHAOS Study），观察了大量的软开发项目并通过不同指标评估其成功与否。此项研究囊括了3.4万个软件项目，从套装软件和操作系统到定制化应用和嵌入式系统。连续十年的研究囊括了大量不同的软件项目和不同的参与者。每年停止跟踪3400个十年前开始的项目，同时开始跟踪3400个新项目。
http://www.standishgroup.com1
斯坦迪什咨询集团给365个参与者发送问卷，覆盖了8380个应用，为的是把项目归为三类。2.1.1 成功的
斯坦迪什咨询集团对成功的软件项目的定义是：“按时完成，没超过预算，所有的功能和性能与预先定义的一样。”2.1.2 遇到困难的
遇到困难的项目不太容易界定。这些项目虽然完成了，但是总会有些妥协，不是预算上的（成本过多），就是时间上的（延迟交付），或者交付较少的功能，或者性能不如预期。2.1.3 失败的（有缺陷的）
失败的项目是那些被取消的、不曾见天日的项目。通常，项目由于开发者以外的原因被取消或者失败。一个项目可能因种种原因导致失败：资金不足、市场变化、公司策略变化，等等。2
在1994年，混乱研究显示3.4万个项目中有16%是成功的，53%3遇到了困难，31%失败了。十年之后的2004 年，29%的项目成功了，只有18%的项目失败了。
http://www.projectsmart.co.uk/docs/chaos-report.pdf2
http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS34
在2010年，混乱研究显示有37%的项目成功，42%的项目遇到5了困难，21%的项目失败。仅仅两年之后，在2012年则是39%的项目成功，只有18%的项目失败。
http://www.versionone.com/assets/img/files/4ChaosManifest_2011.pdf
http://www.versionone.com/assets/img/files/5CHAOSManifesto2013.pdf
虽然在这些年中有着长足的进步，但是软件项目成功的比例依然不高，仅有不到三分之一的项目能成功，至少斯坦迪什咨询集团是这么说的。
2004年成功率的提高，我相信很大一部分要归功于软件产业的成熟和敏捷方法论被越来越多地采用。但是，虽然有“敏捷”这样的新想法，依然只有三分之一的项目能够成功。
我曾经为一些非常庞大的组织效力过，他们中大多数（但并不是所有的）组织的成功率更加低。那些并非单纯从事软件开发的公司甚至有时只有5%左右的成功率。
业界对这项研究非常关注，很多人翘首以待。但是这项报告发布后不久，期待就变成了质疑，不是对这项研究的结果，而是对这项研究本身。2.2 驳斥斯坦迪什咨询集团
所有的研究都应该证明其客观性，但是斯坦迪什咨询集团采用的对成功的定义非常不精确：“按时完成的，没超过预算，所有的功能和性能与预先定义的一样。”“预先定义”对于预算、时间和功能来说，最多不过是最合理的猜测。而且也没有关于软件上市之后状况的数据。
初始的定义依赖于我们精确了解需要这个软件做什么，精确了解如何让其工作，精确了解需要多长时间，精确了解期间公司会遇到什么样的挑战……而没有给更好的想法留出任何生存空间。
斯坦迪什咨询集团对成功的定义刚好是个关于失败的食谱。它建立在一个荒谬的概念上，以为我们可以事先预知一切，但我们连精确了解其中任意一项都是不可能的，更别说全部了。更糟糕的是，它假设我们在每个项目开始的时候知道每件事情的最佳做法，以至于没有留下任何时间去实验、讨论、修改、重新思考等，没时间想出更好的主意。6
在论文《混乱报告数据的起起落落》中，信息技术产业研究员 J. 劳伦斯·伊夫琳斯和克里斯·弗霍夫说明了，斯坦迪什咨询集团对“成功的”和“遇到困难的”项目的定义具有误导性，是片面的，导致了对实际评估的曲解而得出无意义的数据。
Eveleens, J. Laurenz, and Verhoef, Chris. “The Rise and Fall of 6the Chaos Report Figures,”IEEE Software, 2010, 27(1) http://www.computer.org/csdl/mags/so/2010/01/mso2010010030-abs.html
混乱研究真正度量的是项目管理团队对时间成本预估的能力，以及推动需求的能力。正如伊夫琳斯和弗霍夫指出的那样，斯坦迪什咨询集团的定义并未真正考虑软件开发的真实场景，如可用性、收益和用户满意度。
实现最初的目标其实更像是对于“失败的”定义，因为它意味着我们没有弄清楚客户真正想要的东西，也不知道如何构建出优于一开始所设定的软件。我们只是单纯为了把事情做完而开工：按时交付、符合预算、仅仅做初始需求所列出的功能。
按照斯坦迪什咨询集团的定义，如下这样的项目也会被归为“成功”之列。● 程序一个月后崩溃。● 用户想要添加一个无法完成的简单功能，需要大量的金钱和时间
投入，或者引入诸多新bug。● 糟糕的代码在项目中成年累月的堆积，遗留代码造成了大量的“技术债”。● 这是客户最后一次从我们这里采购。
这也许意味着，多数混乱报告中被标记为“成功的”项目也许并非真正成功了。
由此类推，被斯坦迪什咨询集团归为“遇到困难的”项目也许并
试读结束[说明：试读内容隐藏了图片]