图灵社区的电子书没有采用专有客 户端，您可以在任意设备上，用自 己喜欢的浏览器和PDF阅读器进行 阅读。 但您购买的电子书仅供您个人使用， 未经授权，不得进行传播。 我们愿意相信读者具有这样的良知 和觉悟，与我们共同保护知识产权。 如果购买者有侵权行为，我们可能 对该用户实施包括但不限于关闭该 帐号等维权措施，并可能追究法律 责任。 内 容 提 要 本书会帮你降低构建与维护软件的成本。如果你是软件开发者，将学到一套实践方法以构建易修改的 代码，因为在应用当中代码经常需要修改。对于和软件开发者合作的管理者来说，本书会向你展示为何引 入这 9 个基本的实践方法，会使你的团队更加有效地交付软件而不至于让软件演变成遗留代码。 本书适合软件开发人员和 IT 经理阅读。 [美] David Scott Bernstein 译 李满庆 责任编辑 朱 巍 执行编辑 张海艳 责任印制 彭志环 北京市丰台区成寿寺路11号 ◆ 人民邮电出版社出版发行 ◆ 著 邮编 100164 网址 http://www.ptpress.com.cn 北京 电子邮件 [email protected] 印刷 ◆ 开本：800×1000 1/16 印张：12 字数：284千字 印数：1 — 3 500册 著作权合同登记号 2017年 10 月第 1 版 2017年 10 月北京第 1 次印刷 图字：01-2016-9522号 定价：55.00元 读者服务热线：(010)51095186转600 印装质量热线：(010)81055316 反盗版热线：(010)81055315 广告经营许可证：京东工商广登字 20170147 号 版权声明 Copyright © 2015 The Pragmatic Programmers, LLC. Original English language edition, entitled Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. Simplified Chinese-language edition copyright © 2017 by Posts & Telecom Press. All rights reserved. 本书中文简体字版由 The Pragmatic Programmers, LLC.授权人民邮电出版社独家出版。未经 出版者书面许可，不得以任何方式复制或抄袭本书内容。 版权所有，侵权必究。 2 引 言 本书赞誉 本书从全新的视角展现了现代软件开发流程。工程师们会在其中找到解决日常问题的方案， 而非工程师们可以对软件开发中所面对的挑战和困难有所认识。 ——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，极客，骇客，首席工程师，架构师 序 遗产 遗产是已经死亡的事物存留下的依旧影响着世界的那部分。 能留下遗产的生命是优秀的，但是软件并非如此。我们用温和的词语“遗留”来形容那些已 经失去活力但是依旧运行的代码，让那些过去的决策持续影响着那些深陷其中的人。 软件和硬件要区分对待。我们称硬件为“硬”是因为它是固定的，没有工具是无法调整的。 软件的“软”是指它由思想而生，通过代码来表达，加载到硬件中然后行使一些职责。 讽刺的是，代码在编写完成脱离开发者之后变得比硬件还难修改。 开发者通过编程的逻辑表达想法和需求，赋予软件生命。就像是无中生有一样，直到我们意 识到所有的这些小心论证都是为了让这个新生命成为我们所期望的那样。 敏捷 面对威胁与机遇的时候，反应迅速的组织被称为“敏捷”组织。一个敏捷的组织会吸取经验 教训，不会被那些短期内不会修改的软件束缚手脚，无法行动。 一些思想者，包括我在内，选择“敏捷”这个词来形容我们都希望软件能拥有即刻适应需求 变化的能力。这股敏捷的势力在新开发的软件中很强烈，而且不以任何形式消失，因为软件如此 重要，它应该在这整个软件生命周期中持久旺盛。 这些思想者向那些“算命”的管理实践提出异议，它们要求软件开发者在一个合作的流程中 对未来进行预估，然后根据那些预估的准确与否评判开发者。 这些思想者向那些“提前大规模设计”的开发实践提出异议，它们需要预料到所有可能的情 况才能保证后面维护不至于出现“大问题”。 然后这些思想者将他们的建议用“软件开发宣言”的形式发布给开发者和管理者，这宣言在 今天比在十多年前发布的时候吸引了更多的注意力。 图灵社区会员 ChenyangGao([email protected]) 专享 尊重版权 2 序 宣言并不完美。它在两个方面有所欠缺。它的短小让读者以为它仅仅是些一般性观点而不是 具体编写软件的特定建议。 同时，宣言标题中的“开发”也让读者认为仅仅是新项目才需要采用，到上线时就不需要了。 奏效 受雇的开发者必须意识到，仅仅言听计从是不够的，他们有义务让交付的软件持续产生价值。 软件的复杂度可能因为不当的处理而加剧，成为程序员的负担，难以逃避。大部分的敏捷方 法，尤其是本书，描述了在接受这种现实的组织中工作的方式。 这本书温习了那些实践，它们在最近二十年中被一遍又一遍证实了既有效但又难以实施。 “名义上的敏捷”形容那些采用了在无数的书中描述的实践，却收效甚微的组织。本书将这 些实践进行解剖，分析其背后的原因。只有牢牢地把握住敏捷的逻辑，才能判断“名义上的敏捷” 的问题所在。 计算成本的不断下降，让真正的高质量软件的价值凸显了出来。哪里商业更迅速，哪里就有 财富。在边界逐渐瓦解之时，任何生意都需要优秀的软件才能生存。 奇怪的是，激增的廉价计算机让编程更难了。多数的敏捷开发者，所谓的“多语言程序员”， 知道他们的技艺在敏捷组织之外很难得到欣赏。 David Bernstein解释了为什么敏捷方法会起作用。他深入挖掘了自身的经验，用自己的故事 展示了这些实践的价值。 《修改软件的艺术》明确了成功使用这些实践并从中获取最大价值的前提。 Ward Cunningham 美国俄勒冈州波特兰市 引 言 本书会帮你降低构建与维护软件的成本。 如果你是软件开发者，将学到一套实践方法以构建易修改的代码，因为代码在应用当中经常 需要修改。对于和软件开发者合作的管理者来说，本书会向你展示为何引入这9个基本的实践方 法，会使你的团队更加有效地交付软件，而不至于让软件演变成遗留代码。为此，你需要的不仅 仅是一份技术性的任务清单，还需要对为什么有这些实践方法以及如何实施这些实践方法有着深 刻的理解。 每天，我们都会因为遗留代码而损失时间、金钱和机遇。 不同的人对“遗留代码”有着不同的定义，但是简而言之，遗留代码就是指因为种种原因， 格外难以修正、改进以及使用的代码。 这样的代码有很多。实际上我所见过的所有生产环境下的软件几乎都是遗留代码。 软件产业通常轻视可维护性，所以到最后，企业花在维护代码上的成本比一开始编写代码的 成本还高。正如我们将在第2章看到的，软件开发的低效仅在美国每年就造成百亿美元级的开销， 这可不仅仅是某份报告上的抽象数字。我们每天都受到遗留代码的影响。软件很昂贵，容易出错， 而且难以改进。 业内外人士已经开始拉帮结派为某些项目管理方法论争论不休（其中不乏杰出的点子），但 是为了更好地做出持久性的变革，我们首先要对软件开发的基础目标达成共识。 本书不仅仅是关于如何构建更好的软件，更是关于如何构建更好的软件产业。书中囊括了我 身为专业开发者三十年所学的精华。我从业的头二十年都是在传统的瀑布式开发下度过的，系统 分别按照设计、构建、测试的阶段开发。问题是，规划软件开发的方式充满了不可预见的问题， 这迫使我们必须对质量和预算做出严重的妥协。 但是在最近的十年间，对我以及其他我认识的开始尝试极限编程（Extreme Programming， XP）的软件开发者来说，事情发生了改变。采用这种敏捷开发方法论之后，我们放弃试图在一 开始把所有事情想明白，而是循序渐进地来做，每次只设计、构建、测试一小部分软件。 极限编程中的一些实践方法，诸如测试驱动开发和重构，在构建和扩展软件过程中降低风险 2 引 言 和成本方面给我上了重要的一课。这些实践方法的应用呈现给我各种各样的解决软件问题的方 法。是否能利用这些实践方法，揭示出构建高质量、高可维护的软件的方法呢？ 我的回答是响亮的“能”！ 在程序员生涯初期，我被指派去从标准普尔的feed中整理股票数据，并将数据发送到客户的 私有数据库中。在此之前，这一过程都是手动完成的，容易出错而且平均每天需要花费十四小时 完成。我需要将这一过程自动化，但是对于如何找到最佳的解决方案，一开始我却摸不着头脑。 几周之后的某一天，在已经写了四十多页代码之后，我突然灵光一闪，有了重组数据处理方 式的想法。在几个小时之内，我就完成了这个项目并且将代码削减到只剩下五页。那天早上开工 时预计要花几个月完成的工作，结果在当天下班前就完成了。从那时起，我有过多次灵光一闪， 甄别出藏在问题之下的规律，而这些规律让我能够迅速地构建出高可维护的解决方案。 这仅仅是一