准备工作的中心目标就是降低风险：一个好的项目规划者能够尽可能早地将主要的风险清除掉，以使项目的大部分工作能够尽可能平稳地进行。目前，软件开发中最常见的项目风险是糟糕的需求分析和糟糕的项目计划，因此准备工作就倾向于集中改进需求分析和项目规划。
在实现一个系统之前，你需要理解“这个系统应该做什么”，以及“它该如何做到这些”。
“问题定义”只定义了“问题是什么”，而不涉及任何可能的解决方案。问题定义应该用客户的语言来书写，而且应该从客户的角度来描述问题。通常不应该用计算机的专业术语叙述。最好的解决方案未必是一个计算机程序。
明确的需求有助于确保是用户，而不是程序员，驾驭系统的功能。如果需求明确，那么用户就可以自行评审，并进行核准。否则，程序员就常常会在编程期间自行决定需求。明确的需求免得你去猜用户想要的是什么。
明确的需求还有助于避免争论。在开始编程之前，先把系统的范围确定下来。如果你和另外一个程序员对于“程序应该做什么”意见不一致，你们可以查看书面的需求，以解决分歧。
充分详尽地描述需求，是项目成功的关键，它甚至很可能比有效的构建技术更重要。
架构的质量决定了系统的“概念完整性”，后者继而决定了系统的最终质量。一个经过慎重考虑的架构为“从顶层到底层维护系统的概念完整性”提供了必备的结构和体系，它为程序员提供了指引——其细节程度与程序员的技能和手边的工作相配。它将工作分为几个部分，使多个开发者或者多个开发团队可以独立工作。
架构的目标应该清楚地表述。以系统的可更改性为首要目标的设计，与以性能方面决不妥协为首要目标的设计肯定是不同的——即使两个系统的功能一样。
架构应该描述所有主要决策的动机。谨防“我们向来这么做”这种自认为有理的说法。
Beth想按照她丈夫家祖传的广受好评的炖肉菜谱来做一锅炖肉。她丈夫Adbul说，他母亲是这样教他的：先撒上盐和胡椒，然后去头去尾，最后放到平底锅里盖上盖子炖。Beth就问了：“为什么要去头去尾呢？”Adbul回答说：“我不知道，我向来这么做。这得问一下我母亲。”他打电话给母亲，母亲说：“我不知道，我向来这么做。这得问一下你祖母。”他母亲打电话问祖母，祖母回答说：“我不知道你为什么要去头去尾。我这么做是因为我的锅太小了装不下。”
优秀的软件架构很大程度上是与机器和编程语言无关的。
架构应该明确指出有风险的区域。它应该解释为什么这些区域是有风险的，并说明已经采取饿哪些步骤以使风险最小化。
架构应该包含多个视角。
大多数重要的编程原则并不依赖特定的语言，而依赖于你使用语言的方式。如果你使用的语言缺乏你希望用的构件，或者倾向于出现其他种类的问题，那就应该试着去弥补它。发明你自己的编码约定、标准、类库以及其他改进措施。
