本课程通过自顶向下的程序设计演示和解释，教授学生如何在机器层面上编写和调试程序，并将有效的设计技巧应用于多种程序设计课程。这种方法简化并消除了学生在学习更高级的计算机体系结构和操作系统课程之前需要掌握的概念。
从多年实战出发，著名架构师Juval L?wy硬核打造软件架构和项目“双重设计”的新世界
构建一条通往成功的设计之道，助力每一位有志成为优秀软件架构师的人梦想成真
几乎没有人是被逼着进入软件开发行业的。相反，许多人爱上了编程并决定以此谋生。然而，大多数人所希望的职业生涯与软件开发那黑暗且令人沮丧的现实之间存在着巨大的差距。整个软件行业正处于一场深刻的危机之中。因为软件开发是多维的，所以导致了非常严重的危机，而软件开发的每个方面都被打破了：
成本。一个项目的预算与实际开发该系统的成本之间的相关性很弱。许多组织甚至不愿意解决成本问题，可能是因为它们根本不知道如何解决，也可能是因为它们认识到根本承担不起系统的高昂成本。即使新系统的第一个版本的成本是合理的，但由于设计不当和无法适应变化，整个生命周期的系统成本也往往会远高于预期。随着时间的推移，维护成本变得非常高，以至于公司通常会决定从头开始，新系统很快就会像之前一样陷入同样甚至更糟糕的局面。而其他任何行业都不会选择“定期从头开始”，因为这样做没有经济意义。航空公司维护大型喷气式飞机几十年，而一栋房子可能维护整整一个世纪。
进度。最后期限（deadline）的设定通常是武断的、无法实现的，因为它与实际开发系统所需的时间几乎没有关系。对于大多数开发人员来说，最后期限是无用的东西，它会在团队努力工作的时候“呼啸而过”。如果开发团队确实在最后期限之前完成了任务，那么每个人都会感到惊讶，因为没有人指望它能按时完成。这也是一个糟糕的系统设计的直接结果，它会导致系统的变更和新工作的连锁反应，并使以前完成的工作失效。而且，这是一个非常低效的开发过程的结果，它忽略了活动之间的依赖关系和构建系统的最快、最安全的方式。不仅整个系统的上市时间相当长，而且单个功能的上市时间也可能很夸张。当项目的进度出现延误时，情况已经很糟了；当管理层和客户都不知道这个延误时，情况就更糟了，因为没有人知道这个项目的真实状况。
需求。开发人员往往最终解决了错误的问题。终端客户或其内部环节参与者（如市场营销人员）与开发团队之间的沟通始终存在问题。大多数开发人员也无法适应他们未能捕获需求的情况。即使需求被完美地传达下去，它们也可能随着时间的推移而改变。此变更将使设计无效，并破坏团队试图构建的所有内容。
人员配备。即使是普通的软件系统也非常复杂，超出了人脑的理解能力。内部和外部的复杂性是系统架构不良的直接结果，这反过来又导致复杂的系统很难维护、扩展或重用。
维护。大多数软件系统不是由开发它们的人员来维护的。新员工不了解系统是如何运行的，因此他们在试图解决旧问题时不断地引入新问题。这很快就拉高了维护成本，推迟了上市时间，甚至导致工作停顿或项目取消。
质量。也许没有任何其他东西可以像质量那样破坏软件系统。软件有缺陷，“软件”这个词本身就是“缺陷”的同义词，开发人员无法想象没有缺陷的软件系统。修复缺陷通常会增加缺陷数，添加功能或简单维护也会增加缺陷数。质量差是由不易测试、理解或维护的系统架构直接导致的。同样重要的是，大多数项目没有考虑到基本的质量控制活动，也没有为每项活动分配足够的时间，使其可以无可挑剔地完成。
几十年前，业界开始开发解决世界问题的软件。今天，软件开发本身就是一个世界级的问题。软件开发中的问题往往以非技术性的方式表现出来，如工作环境压力大、人员流动率高、工作倦怠、缺乏信任、自卑，甚至身体疾病等。
软件开发中的所有问题都不是新问题，甚至，有些人在其软件开发的整个职业生涯中都没有经历过一次正确的软件开发过程。这使他们相信这根本不可能做到，他们对任何试图解决这些问题的尝试都不屑一顾，因为“事情就是这样的”。他们甚至可能会与那些试图改进软件开发的人抗衡。他们已经得出结论，这个目标是不可能实现的，所以任何尝试取得更好结果的人，都是在试图做不可能的事，这侮辱了他们的智商。
我自己的过往经历是一个反例，表明开发人员可以成功地开发软件系统。我负责的每个项目均按时、按预算、零缺陷地交付。在创建IDesign之后，我继续保持了这一纪录，我们在该领域一次又一次地帮助客户兑现了他们的承诺。
这种持续、可重复的成功纪录绝非偶然。我在系统工程领域（包含物理系统和软件系统）接受了培训和教育，这使我很容易地认识到这两个系统的相似之处。将实践原则应用到软件设计中，其他工程领域的常识在软件系统中也是有意义的。我从来没有想过不把软件开发当作工程来对待，或者不经过设计或计划就开发一个系统。我认为没有必要在我的信念上妥协，也没有必要屈服于权宜之计，因为做正确的事情才行得通，而不这样做的可怕后果是显而易见的。我很幸运，能有出色的导师，在正确的时间、正确的地点看到哪些有效、哪些无效，并有机会在早期参与了一些重大而关键的项目，使之成为优秀案例的一部分。
近年来，我注意到该行业的问题越来越严重。越来越多的软件项目失败了。在时间和金钱上失败成本都变得越来越高，甚至已经完成的项目也往往偏离了最初的承诺。这场危机加剧不仅仅是因为系统越来越大或者云计算的发展，也可能是激进的最后期限或者更高的变更率。但我怀疑真正的原因是，开发队伍中越来越缺乏如何设计和开发软件系统的知识。之前大多数团队中都有一位资深人士，他指导年轻人并传授知识。如今，这些导师已经或即将退休。在他们缺席的情况下，普通人只能获得无限的信息，却得不到有用的知识。
我多希望有一个你做了就能解决软件危机的方法，比如使用过程、开发方法、工具或技术。不幸的是，要解决多维问题，就需要多维解决方案。在这本书中，我提供了一个统一的补救方法：软件架构之道（righting software）。
总之，我所建议的是使用工程原理来设计和开发软件系统。好消息是没有必要重新发明轮子，其他的工程学科是相当成功的，因此软件行业可以借用它们的关键通用设计思想并使其适用于软件。你将在本书中看到一套软件工程的基本原理，以及一套完整应用于软件系统和项目的工具与技术。要获得成功，我们必须从工程的角度出发，基于时间和风险方面的考虑，确保软件系统是可维护的、可扩展的、可重用的、可负担的和可行的，这些都是工程方面的问题，而不是技术方面的问题，而且可以直接追溯到系统和项目的设计环节。由于“软件工程师”通常指软件开发人员，所以出现了术语“软件架构师”来描述团队中负责项目所有设计方面的人。因此，我假定本书的读者是软件架构师。
本书中的一些想法并不是你唯一要正确认识的事情，但它们肯定是一个良好的开端，因为它们触及了前面提到的问题的根源。根本原因是设计不当，无论是软件系统本身还是用于构建该系统的项目。你将看到，按计划、按预算交付软件以及设计满足所有可能需求的系统是完全可能的，开发出来的系统也是易维护、易扩展和易重用的。希望通过实践这些想法，你不仅能够学会软件系统构建之道，还能助力自己的职业生涯，并重新点燃对软件开发的热情。
本书的组织结构
本书展示了系统设计和项目设计的结构化工程方法。本书的结构反映了方法论的两个部分：系统设计（通常称为架构）和项目设计。这两部分相辅相成，是成功的必要条件。附录提供了一些补充内容。
在大多数技术书籍中，每一章只针对一个主题并深入探讨，这样更容易编写，但这通常不是人们学习的方式。相比之下，在这本书中，讲解是螺旋式的。本书的两大部分中的每一
章都重申了前几章的观点，通过多方面的洞察来进行更深入的研究或观点的演进。这模仿了自然的学习过程，每一章都依赖于前面的章节，所以你应该按顺序阅读这些章节。本书的两大部分均包含了详细的案例研究，以展示这些观点以及其他方面。同时，为了保持迭代的简洁性，作为一般规则，我通常避免内容重复，因此即使是关键知识点，也只讨论一次。
以下是对各章和附录的简单介绍：
第1章 元设计方法
本章介绍了下列关键思想：要想成功，必须同时设计系统和用来构建系统的项目。这两种设计对于最终成功都是不可或缺的。没有架构就无法设计项目，设计一个无法构建的系统是毫无意义的。
第2章 分解
本章致力于将系统分解为组成其架构的组件。大多数人以最坏的方式来分解系统，所以本章首先解释了不该做什么。一旦这个观念建立起来，你将学会如何正确地分解系统，在该过程中掌握一组有用的、简单的分析工具并获得观察结果。
第3章 结构
本章提升了第2章的思想，引入了结构。你将看到如何捕获需求、如何对架构分层、架构组件的分类及相互关系、特定的分类指导原则以及一些相关的问题，如子系统设计。
第4章 组合
本章说明如何将系统组件组装成满足需求的有效组合。这简短的一章包含了本书的几个关键设计原则，并将前两章的内容转化为将在每个系统中使用的强大的思维工具。
第5章 系统设计示例
本章是一个广泛的案例研究，展示了迄今为止所讨论的系统设计思想。系统设计螺旋结构的最后迭代提供了一个实际的系统，使系统设计与业务保持一致，并展示了如何生成架构并对其进行验证。
第6章 动机
由于大多数人从来没有听说过项目设计（更不用说实践了），本章介绍了项目设计的概念和参与项目设计的动机。这是项目设计螺旋的第0次迭代。
第7章 项目设计综述
本章概述了如何设计一个项目，首先定义了“软件研发的成功”，然后介绍了明智的决定、项目人员配备、项目网络图、关键路径、安排活动和项目费用等关键概念。本章涵盖了随后各章中使用的大多数思想和技术，最后重点讨论了角色和责任。
第8章 网络和浮动时间
本章介绍了项目网络及其作为设计工具的使用。你将看到如何将项目建模为一个网络图，学习浮动时间的关键概念，了解如何在人员配备和调度中使用浮动时间，并了解浮动时间与风险的关系。
第9章 时间和成本
本章定义了在所有项目中时间和成本之间可能的权衡，并讨论了通过正确工作来加速所有项目的方法。除此之外，你还将学习压缩的关键概念、时间-成本曲线和成本要素。
第10章 风险
本章介绍了大多数项目中缺少的要素：量化风险。你将看到如何度量风险并将其映射到上一章的时间和成本概念中，以及如何基于网络计算风险。风险通常是评估选项的最佳方式，也是一流的规划工具。
第11章 实践中的项目设计
本章通过对设计一个项目所涉及的步骤进行系统的演练，将前几章的所有概念付诸使用。其目标是演示设计项目时使用的思维过程，以及如何为业务决策者审查做准备。
第12章 高级技巧
遵循螺旋式学习模型，本章介绍了高级技巧和概念。这些技巧在各种复杂程度（从简单到最具挑战性）的项目中都很有用，是对前几章的补充，而且经常会结合起来使用。
第13章 项目设计示例
本章是与第5章的系统设计示例相对应的项目设计示例。它也是一个案例研究，展示了设计项目端到端的过程。本章的重点是案例研究，而不是技巧。
第14章 总结
最后一章从设计的技术方面进行了回顾，提供了一系列的指导、技巧、视角和开发过程思想。它从“回答何时设计项目这个重要问题”开始，以“项目设计对质量的影响”结束。
附录A 项目跟踪
附录A展示了如何在计划方面跟踪项目的进度，以及如何在需要时采取纠正措施。项目跟踪更多的是关于项目管理，而不是项目设计，但它对于确保你在工作开始后履行承诺至关重要。
附录B 服务契约设计
架构本身是粗略的，你必须设计其每个组件的细节，而这些细节中最重要的是服务契约。附录B指出了设计服务契约的正确方法。此外，关于模块化、规模和成本的讨论也很好地契合了本书大多数章节的内容。
附录C 设计标准
附录C汇总了本书中提到的关键原则、指南和禁忌事项。该标准是简洁的，是关于“什么”，而不是“为什么”。这个标准背后的原理可以在本书的其余部分找到。
关于读者的假设
虽然本书是面向软件架构师的，但读者范围更广泛。读者可以是架构师、高级软件专业人员、项目经理或多重角色的人，也就是说，有志于提高自己技能的开发人员都将从本书中受益。无论你目前处于什么职位，本书都将为你的职业生涯打开一扇大门。当你初次阅读本书时，可能不是一个经验丰富的架构师，但是一旦你阅读并掌握了方法论，就将跻身世界之巅。
本书的技术和思想适用于各种编程语言（如C++、Java、C#和Python）、各种平台（如Windows、Linux、移动设备、本地环境和云）和各种项目规模（从最小到最大的项目），还跨越所有行业（从医疗保健到国防）及所有商业模式和公司规模（从初创企业到大型公司）。
我对读者做出的最重要假设是，你在深层次上关心自己的工作，而当前的失败和浪费使你感到苦恼。你想做得更好，但是缺乏指导，或者为不良的做法所困扰。
使用本书的要诀
阅读本书的唯一先决条件是开放的心态，过去的失败经历和挫折是加分项。
其他在线资源
本书的网页提供了示例文件、附录和勘误表。可以通过以下网址访问此页：
http：//www.rightingsoftware.org
你可以在本书的“下载支持文件”链接下找到示例文件和相关的支持材料。
有关本书的其他信息，请访问informit.com/title/9780136524038。
你也可以通过以下地址与作者联系：http://www.idesign.net。
致谢
首先，感谢督促我写这本书的两个人（他们都有自己独特的方式）：Gad Meir和Jarkko Kemppainen。
感谢策划编辑和顾问Dave Killian：要再多一点编辑修改，我就得把他列为合著者了。接下来，感谢Beth Siron审阅了原稿。同时感谢以下人员花费时间审阅草稿：Chad Michel、Doug Durham、George Stevens、Josh Loyd、Riccardo Bennett Lovsey和Steve Land。
最后，感谢我的妻子Dana，她一直鼓励我写作，并承担了家务；感谢我的父母，他们将自己对工程的热爱传递给了我。
“我参加了架构大师班和项目设计大师班。在参加这两个课程之前，我几乎放弃了弄清楚我的团队付出的努力付之东流的原因，而是努力寻找一个可行的解决方案来制止我们疯狂的‘死亡行军’。然而，大师班让我大开眼界—帮我打开了一个新世界，看到软件开发水平已超越所有其他工程学科，并且以专业、可预测和可靠的方式进行，从而可以在预算内按时开发出高质量的工作软件。我从中获得的知识是无价的！从揭示如何在用户需求不断变化的情况下创建一个稳定、可靠的架构到如何规划和指导项目成功完成的复杂细节，所有这些都融入了作者无与伦比的专业知识和技能。Juval在课堂上分享的每一个浓缩的真理都是源于现实生活并被检验过的，将这种学习经验转化为强大的知识体系，对任何渴望成为软件架构师的人都是福音。”
— Rossen Totev，软件架构师/项目负责人
“项目设计大师班影响了我的职业发展。今天项目期限和预算几乎被滥用的事情随处可见，因此有机会向Juval学习是一个天赐的机会。他逐一提供了正确设计项目的方法和适当的工具。结果是，在变化发展甚至混乱的现代软件开发环境中，成本和进度都受到控制。Juval说，你将参与一场针对逾期和费用过高的非对称战争，并且能真正地有扛枪打仗的感觉。没有魔术，只是将基本的工程和制造原则应用于软件，但你从大师班回到公司时感觉自己已经是行家了。”
— Matt Robold，West Covina Service Group软件开发经理
“很棒的经历，改变了我对软件开发方法的看法。我一直有一些关于设计和编码的想法，之前从来不能用语言表达它，但是现在我可以。它不仅影响了我对软件设计的思考方式，还影响了我关于其他类别的设计。”
— Lee Messick，首席架构师
“多年来，我在从事软件项目工作时，一直被急速而至的最后期限困扰着。仅仅了解软件开发方法和合适的流程似乎感觉精力即将耗尽，因为我不但要满足客户不合理的需求，还不得不与管理层的固执己见作斗争。我在两个战线上同时作战，感到绝望，这时我感觉自己像个浪人。本书给我带来了前所未有的清晰感，它准确无误地教会了我正在寻找的知识。我学到了高深的技术，这些技术改变了我对软件项目运行方式的理解。现在我借助这样的工具，可以在无休止的需求变更洪流中有效且高效地驾驭我的项目。在一个混乱的世界里，这个课程带来了秩序。我永远感谢IDesign，我的生活从此不一样了。”
— Aaron Friedman，软件架构师
“生活在改变，我感觉自己就像是一架布满了几十年的灰尘而又被重新校准的钢琴。”
— Jandan Jan，CTO/架构师
“课程很棒，这无疑是我职业生涯中最紧张但最有意义的一周。”
— Stoil Pankov，软件架构师
“Juval Lo¨wy的课程改变了我的生活。我从单纯的开发人员转变成真正的软件架构师，将其他学科的工程原理运用到软件设计以及我的职业生涯中。”
— Kory Torgersen，软件架构师
“架构大师班是一门关于技能和设计的终生课程，我参加了两次。我第一次参加时，感觉该课程真是太具有变革性了，以至于我希望几十年前我的职业生涯刚开始时，我就已经参加了这门课程。后来即使是第二次参加这门课程，我也只学到了其中的25%，因为这些想法非常深刻。重建思维体系和自我否定真的很痛苦，但是我需要与更多的同事再来一次。最后，每一天，我都会回想起Juval在课堂上所说的话，并用它来帮助我的团队应用到甚至很小的事情上，以便最终使我们大家都可以被称为专业工程师。（附言：我第二次参加课程写了100页笔记！）”
— Jaysu Jeyachandran，Nielsen软件开发经理
“如果你在看到和经历了软件行业的许多失败尝试后感到沮丧、缺乏活力且意志消沉，那么这堂课将使你焕发青春。它带你进入职业成熟的新境界，也给你带来希望和信心，让你可以正确地工作。你将以新的思维方式和充足的无价工具从项目设计大师班毕业，这将使你再也找不到软件项目失败的借口。你开始练习、亲自动手，获得洞察力和经验。是的，你可以在向项目干系人提供成本、时间和项目风险等信息时做到准确无误。现在，如果你对自己的职业生涯很在意，别等公司让你参加这堂课，你应该立刻主动参加本课程或任何IDesign大师课程。这是你可以做出的最佳自我投资。感谢IDesign的整个团队，他们为帮助软件行业成为扎实的工程学科付出了持续努力。”
— Lucian Marian，Mirabel软件架构师
“20多岁尚处于职业生涯相对早期的阶段，我可以诚实地说，这本书改变了我的生活，改变了我看待职业道路的方式，这将是我一生中的关键时刻之一。”
— Alex Karpowich，软件架构师
“我想感谢这改变我职业生涯的一周。通常，我上课的时间不会超过50%—因为课程很无聊，而且他们没有教给我任何我无法自学的知识，要么就是讲一些我已经知道的东西。但在架构大师班上，我一天坐了9个小时，仍感觉时间不够用：我了解了作为软件工程架构师的职责（我之前认为架构师只是软件设计师），关键是不仅要准时交付，还要控制预算并保证质量，不是等待‘成长’为架构师，而是要管理我的职业生涯，以及如何量化和衡量我以前认为的直觉。从本周开始，我有了更多的见识，现在也积累了很多知识。我等不及要参加下一次大师班了。”
— Itai Zolberg，软件架构师
计算机\软件测试
本书展示了著名架构师Juval L?wy在世界各地实践和教授的经过检验的、结构化和高度工程化的软件设计方法。尽管各种各样的公司已经成功地在数百个系统中实现了他最初的设计思想，但这些见解从未出现在正式出版的技术图书中。
L?wy的方法论基于软件工程的基本原理以及一整套匹配的工具和技术，将系统设计和项目设计结合起来。首先，他描述了许多软件架构师失败的主要领域，并展示了如何基于易变性将系统分解成更小的构建块或服务。接下来，他展示了如何在系统设计中进行有效的项目设计，如何准确计算项目持续时间、成本和风险，以及如何设计多个执行选项。
无论你的项目和公司规模、技术、平台或行业如何，本书中的方法和原则都适用。作者通过展示如何设计正确的软件系统和项目来指导读者应对当今软件开发的关键挑战，软件专业人士、架构师、项目负责人或经理在职业生涯的任何阶段都将从本书中受益。
我从中获得的知识是无价的！从揭示如何在用户需求不断变化的情况下创建一个稳定、可靠的架构到如何规划和指导项目成功完成的复杂细节，所有这些都融入了作者无与伦比的专业知识和技能。Juval在课堂上分享的每一个浓缩的真理都是源于现实生活并被检验过的，将这种学习经验转化为强大的知识体系，对任何渴望成为软件架构师的人都是福音。
—— Rossen Totev，软件架构师/项目负责人
很棒的经历，改变了我对软件开发方法的看法。我一直有一些关于设计和编码的想法，之前从来不能用语言表达它，但是现在我可以。它不仅影响了我对软件设计的思考方式，还影响了我关于其他类别的设计。
—— Lee Messick，首席架构师
本书给我带来了前所未有的清晰感，它准确无误地教会了我正在寻找的知识。我学到了高深的技术，这些技术改变了我对软件项目运行方式的理解。现在我借助这样的工具，可以在无休止的需求变更洪流中有效且高效地驾驭我的项目。
—— Aaron Friedman，软件架构师
生活在改变，我感觉自己就像是一架布满了几十年的灰尘而又被重新校准的钢琴。
—— Jandan Jan，CTO/架构师
20多岁尚处于职业生涯相对早期的阶段，我可以诚实地说，这本书改变了我的生活，改变了我看待职业道路的方式，这将是我一生中的关键时刻之一。
—— Alex Karpowich，软件架构师
在敏捷、DevOps盛行的时代，人们关注CI/CD、工具链，追求快速迭代，追求效率，但往往欲速则不达，因为忽视了架构设计和项目管理。众所周知，开发速度越快，架构设计更要力求简单，以有利于代码的实现和测试；当软件研发高速运行时，管理也显得更为重要，否则容易出现混乱，造成“事倍功半”的不利局面。在现实中这种局面倒是不少见，许多软件研发团队的项目管理越来越简单、粗暴，研发过程过于随意，工作量估算更是儿戏，项目里程碑的设定往往比较主观，与开发系统所需的实际时间相差太远，导致经常加班，甚至进入恶性循环。同时，对需求、架构和功能设计等也关注不够，需求经常变更，开发人员和测试人员经常返工，推倒重来，但没有人关注开发成本，没有人去算一算这笔账，而总是感觉人力资源不够，“缺人”这个坑永远无法填平。
大家对这样的状况并不陌生。当这样的状况成为普遍现象时，一本讲解架构设计和项目设计的书摆在你面前，简直就是雪中送炭。
是时候需要这样一本书帮助我们改变认知，重新认识软件系统设计和项目设计的必要性和价值，并深刻认识一个软件架构师的职责不局限于软件系统架构的设计，还应包括项目设计，两者相辅相成，才能确保项目按预期进展且按质按量地交付产品。过去，我们也阅读了大量的技术图书，有专门讨论系统架构设计的，也有专门讨论项目管理的，但从来没见过一本书可以将系统设计和项目设计融为一体，让它们相辅相成，达到最好的效果，从而确保每一个项目都获得成功。本书的确让我们眼前一亮，吸引我们迫不及待地去阅读。
软件架构决定了组件的划分和组件之间的关系，系统设计能力就体现在分解和组合的能力上，包括如何进行层次划分、厘清不同组件之间的关系。更重要的是，要坚持几个关键的设计原则，善于使用工具，包括分析或思维工具。这样，我们就能设计出一个良好的系统架构，不仅能确保系统是高内聚、松耦合的，有利于未来产品的升级和维护，而且能确保系统具有良好的性能、弹性、安全性、兼容性等，将质量内建于系统之中。
如果系统是松耦合的，有利于系统的分解和开发任务的分解，从而有利于项目工作量的估算和人员的配备，并且在软件开发过程中沟通协作的成本也会显著降低。相反，如果系统设计不好，导致系统过于复杂、强耦合，那么系统将很难维护、扩展或重用，系统维护成本就会陡增，甚至当系统出现严重缺陷时短时间内无法修复，从而导致项目交付延期，甚至导致项目彻底失败。
在项目设计中，自然首先要明确项目的目标，设计就是为了以更低的成本、更快的速度达成项目的目标，所以项目设计需要综合考虑各种因素（特别是风险因素和不同的选项），完成项目建模（如绘制项目网络图、找出关键路径），客观地估算成本，量化项目风险和评估风险，基于网络计算风险，了解浮动时间与风险的关系、时间与成本的关系，在它们之间进行权衡，从而做出明智的决策。
基于一系列成功的经验（按时、按预算、高质量的交付），作者更加坚定了先进的设计理念，提出了有效的设计原则和实践方法，形成软件架构之道（righting software），并鼓励我们不妥协、不屈服于权宜之计，要坚持做正确的事，采用结构化工程方法做好系统设计和项目设计，基于时间和风险方面的考虑，确保软件系统是可维护的、可扩展的、可重用的。除此之外，本书清楚地讲述了软件工程的基本原理，提供了一套应用于软件系统和项目的完整设计工具和技术。
本书的学习是以螺旋式深入下去，系统设计和项目设计也必然是螺旋式提升的过程，希望每一位读者在学习本书的思想、方法、技巧时，能够进行实践，然后再学习、再实践，让自己掌管的项目立于不败之地，这就是对我们辛勤的翻译工作的最好回报。
朱少民
辛丑年于上海
赞誉
译者序
前言
作者介绍
第1章 元设计方法 / 1
1.1 什么是元设计方法 / 2
1.1.1 设计验证 / 3
1.1.2 紧迫的时间 / 3
1.1.3 消除分析瘫痪 / 4
1.1.4 沟通 / 5
1.2 元设计方法不是什么 / 6
|第一部分| 系统设计
第2章 分解 / 8
2.1 避免功能分解 / 9
2.1.1 功能分解带来的问题 / 9
2.1.2 关于功能分解的思考 / 13
2.1.3 避免领域分解 / 15
2.1.4 错误的动机 / 17
2.1.5 可测试性和设计 / 17
2.1.6 示例：功能型交易系统 / 19
2.2 基于易变性的分解 / 21
2.2.1 分解、维护和开发 / 22
2.2.2 普遍性原则 / 23
2.2.3 基于易变性的分解与测试 / 24
2.2.4 易变性的挑战 / 24
2.3 识别易变性 / 26
2.3.1 易变性与可变性 / 26
2.3.2 易变轴 / 27
2.3.3 伪装成需求的解决方案 / 29
2.3.4 易变列表 / 30
2.3.5 示例：基于易变性的交易系统 / 30
2.3.6 抵制“塞壬之歌” / 34
2.3.7 易变性与业务 / 35
2.3.8 为竞争对手设计 / 37
2.3.9 易变性和寿命 / 38
2.3.10 实践的重要性 / 38
第3章 结构 / 40
3.1 用例和需求 / 41
3.2 分层方法 / 43
3.3 典型分层 / 44
3.3.1 客户端层 / 44
3.3.2 业务逻辑层 / 45
3.3.3 资源访问层 / 46
3.3.4 资源层 / 47
3.3.5 实用工具库栏 / 48
3.4 分类指南 / 48
3.4.1 命名的玄机 / 48
3.4.2 四个问题 / 49
3.4.3 管理器与引擎比 / 50
3.4.4 关键观察 / 51
3.5 子系统和服务 / 52
3.5.1 增量构造 / 52
3.5.2 关于微服务 / 54
3.6 开放和封闭式架构 / 56
3.6.1 开放式架构 / 56
3.6.2 封闭式架构 / 56
3.6.3 半封闭/半开放架构 / 57
3.6.4 放宽规则 / 57
3.6.5 设计禁忌 / 59
3.6.6 力求对称 / 61
第4章 组合 / 62
4.1 需求与变更 / 62
4.1.1 憎恨变更 / 63
4.1.2 设计基本准则 / 63
4.2 可组合设计 / 64
4.2.1 核心用例 / 64
4.2.2 架构师的使命 / 65
4.3 这里没有功能 / 68
4.4 处理变更 / 69
第5章 系统设计示例 / 71
5.1 系统概述 / 72
5.1.1 遗留系统 / 73
5.1.2 新系统 / 74
5.1.3 公司 / 74
5.1.4 用例 / 74
5.2 反设计工作 / 80
5.2.1 巨型系统 / 80
5.2.2 颗粒化构建块 / 80
5.2.3 域分解 / 81
5.3 业务对齐 / 82
5.3.1 愿景 / 82
5.3.2 业务目标 / 83
5.3.3 使命陈述 / 84
5.4 架构 / 84
5.4.1 TradeMe词汇表 / 84
5.4.2 TradeMe易变区域 / 85
5.4.3 静态架构 / 88
5.4.4 操作概念 / 90
5.4.5 工作流管理器 / 92
5.5 设计验证 / 93
5.5.1 添加技工/承包商用例 / 94
5.5.2 请求技工用例 / 95
5.5.3 匹配技工用例 / 96
5.5.4 分配技工用例 / 98
5.5.5 终止技工用例 / 100
5.5.6 支付技工用例 / 101
5.5.7 创建项目用例 / 101
5.5.8 结束项目用例 / 102
5.6 接下来会是什么 / 103
|第二部分| 项目设计
第6章 动机 / 106
6.1 项目设计的背景和基本动机 / 106
6.1.1 项目设计和项目稳健 / 107
6.1.2 组装说明 / 108
6.2 软件项目的需求层级 / 108
第7章 项目设计综述 / 111
7.1 定义成功 / 111
7.2 项目初始人员配备 / 113
7.2.1 一个架构师，非一群架构师 / 113
7.2.2 核心团队 / 114
7.3 明智的决定 / 116
7.3.1 计划，不计划 / 116
7.3.2 软件开发计划评审 / 117
7.4 服务和开发人员 / 117
7.4.1 设计和团队效率 / 119
7.4.2 任务连续性 / 120
7.5 工作量的估算 / 120
7.5.1 经典错误 / 121
7.5.2 估算技术 / 123
7.5.3 总体项目估算 / 124
7.5.4 活动估算 / 126
7.6 关键路径分析 / 127
7.6.1 项目网络图 / 127
7.6.2 关键路径 / 130
7.6.3 分配资源 / 131
7.7 安排活动 / 134
7.8 项目费用 / 140
7.9 挣值计划 / 143
7.9.1 经典错误 / 144
7.9.2 浅S曲线 / 145
7.10 角色和责任 / 148
第8章 网络和浮动时间 / 149
8.1 网络图 / 149
8.1.1 节点图 / 150
8.1.2 箭头图 / 150
8.1.3 箭头图与节点图 / 151
8.2 浮动时间 / 152
8.2.1 总浮动时间 / 153
8.2.2 自由浮动时间 / 153
8.2.3 计算浮动时间 / 154
8.2.4 可视化浮动时间 / 155
8.3 基于浮动时间的进度安排 / 157
第9章 时间和成本 / 159
9.1 加速软件项目 / 159
9.2 进度压缩 / 162
9.2.1 利用更好的资源 / 162
9.2.2 并行工作 / 162
9.2.3 并行工作和成本 / 164
9.3 时间-成本曲线 / 164
9.3.1 时间-成本曲线上的要点 / 165
9.3.2 离散建模 / 167
9.3.3 避免经典错误 / 168
9.3.4 项目可行性 / 168
9.3.5 找到常规方案 / 169
9.4 项目成本要素 / 171
9.4.1 直接成本 / 171
9.4.2 间接成本 / 172
9.4.3 会计与价值 / 172
9.4.4 总成本、直接成本和间接成本 / 172
9.4.5 压缩和成本要素 / 173
9.4.6 人员配备和成本要素 / 176
9.4.7 固定成本 / 178
9.5 网络压缩 / 178
第10章 风险 / 181
10.1 选择选项 / 181
10.2 时间-风险曲线 / 182
10.3 风险建模 / 184
10.3.1 标准化风险 / 185
10.3.2 风险和浮动 / 185
10.3.3 风险和直接成本 / 186
10.3.4 临界风险 / 186
10.3.5 斐波那契风险 / 188
10.3.6 活动风险 / 189
10.3.7 临界风险与活动风险 / 191
10.4 压缩和风险 / 191
10.5 风险缓解 / 192
10.5.1 如何缓解 / 192
10.5.2 缓解目标 / 193
10.6 风险指标 / 194
第11章 实践中的项目设计 / 196
11.1 使命 / 196
11.1.1 静态架构 / 197
11.1.2 调用链 / 197
11.1.3 活动清单 / 199
11.1.4 网络图 / 200
11.1.5 计划假设 / 201
11.2 寻找常规的解决方案 / 203
11.2.1 无限的资源（迭代1） / 203
11.2.2 网络和资源问题 / 204
11.2.3 基础设施优先（迭代2） / 204
11.2.4 有限的资源 / 205
11.2.5 亚临界化（迭代7） / 208
11.2.6 选择常规的解决方案 / 211
11.3 网络压缩 / 211
11.3.1 使用更好的资源进行压缩 / 211
11.3.2 引入并行工作 / 213
11.3.3 压缩迭代结束 / 219
11.3.4 产出分析 / 219
11.4 效率分析 / 221
11.5 时间-成本曲线 / 221
11.5.1 时间-成本相关模型 / 222
11.5.2 死亡区域 / 224
11.6 规划与风险 / 225
11.6.1 风险缓解 / 226
11.6.2 重建时间-成本曲线 / 228
11.6.3 风险模型化 / 230
11.6.4 风险包含与排除 / 232
11.7 SDP评审 / 232
第12章 高级技巧 / 234
12.1 上帝活动 / 234
12.2 风险交叉点 / 235
12.3 找到缓解目标 / 238
12.4 几何风险 / 240
12.4.1 几何临界风险 / 241
12.4.2 几何斐波那契风险 / 241
12.4.3 几何活动风险 / 242
12.4.4 几何风险行为 / 243
12.5 执行复杂度 / 244
12.5.1 圈复杂度 / 244
12.5.2 项目类型与复杂度 / 245
12.5.3 项目压缩与复杂度 / 246
12.6 超大型项目 / 247
12.6.1 复杂系统与脆弱性 / 248
12.6.2 网络群 / 250
12.6.3 设计网络群 / 250
12.7 小项目 / 253
12.8 基于层次设计 / 253
12.8.1 基于层次设计的利弊 / 254
12.8.2 层次与构造 / 255
第13章 项目设计示例 / 256
13.1 估算 / 257
13.1.1 单个活动估算 / 257
13.1.2 总体项目估算 / 258
13.2 依赖关系和项目网络 / 259
13.2.1 行为依赖 / 259
13.2.2 非行为依赖 / 259
13.2.3 覆盖某些依赖 / 260
13.2.4 完整性检查 / 260
13.3 常规方案 / 261
13.3.1 网络图 / 261
13.3.2 计划进度 / 263
13.3.3 计划的人员配备分布 / 263
13.3.4 成本和效率 / 264
13.3.5 结果总结 / 264
13.4 压缩方案 / 264
13.4.1 添加启用活动 / 264
13.4.2 分配资源 / 265
13.4.3 计划进度 / 266
13.4.4 计划的人员配备分布 / 266
13.4.5 成本和效率 / 266
13.4.6 结果总结 / 267
13.5 分层设计 / 268
13.5.1 分层设计和风险 / 268
13.5.2 人员配备分布 / 269
13.5.3 结果总结 / 269
13.6 亚临界方案 / 269
13.6.1 持续时间、计划进度和风险 / 270
13.6.2 成本和效率 / 270
13.6.3 结果总结 / 270
13.7 比较选项 / 271
13.8 计划与风险 / 271
13.8.1 风险缓解 / 271
13.8.2 重新计算成本 / 274
13.9 为SDP评审做准备 / 274
第14章 总结 / 276
14.1 项目设计时间 / 276
14.1.1 真实的答案 / 277
14.1.2 迈向未来 / 278
14.2 一般性指导 / 279
14.2.1 架构与估算 / 279
14.2.2 设计立场 / 280
14.2.3 可选性 / 280
14.2.4 压缩 / 281
14.2.5 计划与风险 / 283
14.3 项目设计的设计 / 283
14.4 不同的视角 / 285
14.5 交接 / 287
14.5.1 初级交接 / 287
14.5.2 高级交接 / 287
14.5.3 资深开发人员作为初级架构师 / 288
14.6 实践 / 289
14.7 项目设计的口头汇报 / 290
14.8 关于质量 / 291
14.8.1 质量控制活动 / 291
14.8.2 质量保证活动 / 292
14.8.3 质量与文化 / 293
|附录|
附录A 项目跟踪 / 296
附录B 服务契约设计 / 310
附录C 设计标准 / 323
