保持软件设计的品质。坏的架构设计会招致更坏的架构设计。
开发团队中健康的工作关系将直接有益于软件设计。不健康的关系和个性膨胀会导致不健康的软件。
软件设计的关键品质是内聚和耦合。-- 高内聚(Strong cohesion)和低耦合(Low coupling)
松弛而模糊的架构将导致每个代码组件编写得不好，并且相互之间匹配得不好。它也会导致重复的代码和工作。
不良架构的影响不仅限于代码。它会进一步影响到人、团队、过程和时间表。
重要的是要在开始设计系统之前知道你打算设计什么。如果你不知道它是什么，也不知道它将做什么，暂时不要开始设计它。只设计你知道需要的东西。
扁平化团队结构
设计第一步：
确定主要的功能领域
顶层文件结构
如何对事物命名
“内部”展示的风格
共用的编码惯例
选择单元测试框架
支持基础设施（例如版本控制、适合的构建系统和持续集成）
按照XP过程推进，设计和编码要么以结对的方式完成，要么经过仔细的复审，确保工作的正确性。
架构有助于定位功能：添加功能、修改功能或修复缺陷。它为你提供了一个模板，让你将工作纳入到一张系统导航图中。清晰的架构设计将导致一致的系统。所有决定都应该在架构设计的背景下做出。清晰的架构有助于减少功能重复。软件架构不是一成不变的。需要时就改变它。要想做到可以修改，架构就必须保持简单。牺牲简单性的修改要抵制。
XP原则 -- YAGNI(如果你不是马上需要，就不需要去做)。延迟设计决定，知道你必须做出这些决定为止。不要在你还不知道需求的时候就做出架构决定。不要猜测。必须保持架构品质。只有当开发者们相信它并对它负责时，才能做到这一点。你的系统应该有一组不错的自动化测试，它们让你在进行根本的架构变更时风险最小。这为你提供了工作空间。对你的代码进行单元测试将带来更好的软件设计，所以设计时要考虑可测试性。好的项目计划将带来优质的设计。分配足够的时间来创建架构杰作，它们不会立即出现。团队的组织方式必然对它产生的代码有影响。随着时间的推移，架构也会影响到团队协作的好坏。当团队瓦解时，代码的交互就很糟糕。当团队协作时，架构就集成得很好。