架构设计--仅是软件开发之第二大影响力？！ （原文最终修订于2006-07-01 凌晨03:20:31）

SDWest2006（译注1）对我来说是个有趣的大会。我除了星期三之外（当时我正飞往费城参加一个客户会议 == 因此错过了Jolt颁奖部分）每天都在演讲。我也参加了一些谈话和会议；其中最引人关注的是Mike Cohn的计划与估算的谈话。我的两个谈话都是半天的关于Ood原则的导引。这些谈话都参与的非常好，现场反映也很热烈。
这里是我谈话的几份演讲稿：

类设计之高级原则 在OO设计中，掌控类间组合或是关联关系的原则到底是什么？

组件设计之高级原则 在大型OO设计中，你该如何掌控组件的组合或关联关系？

首要导向因素 专业与否的最低界限是什么？

在星期二我主导了一个关于“敏捷与架构设计”的圆桌会议。很多人是挤着进入会议现场的，而且一直参与到会议结束。配合着讨论要点的导航图，我们将这些要点一一讨论过。我的好朋友John Kern也在那儿，还帮助解答了很多提问。你可以从这里了解更多有关这个会议的。

会议的一些关键要点如下：

架构设计的主要目标是灵活性，可维护性和可扩展性。

但我们认识到，由测试驱动开发原则指导产生的单元测试和验收测试（译注2）要比灵活性，可维护性和可扩展性来得更重要。

因而测试才是首要的影响力，而架构设计只是第二位的。

在此次会议前，我从未想到过这点。这里就有一群架构师和设计师，他们激烈的争辩着架构设计的角色和位置，可是我们辛苦争论出的一致结论是灵活性，可维护性和可扩展性是处于次要的影响作用的，是编写测试（测试优先于产品代码）起着最主要的效用。

这好像是吞下了苦黄莲，而且很多架构设计师们搞不好立即就会拒绝。然而，没人认为架构师不重要，或者认为应该丢掉它转而去青睐测试。正相反，是测试让我们无所顾虑的改进系统的设计。不是测试胜于架构设计；而应该说是测试成全了它！

自动化测试给了我们一个可靠的方式去了解系统是否运行良好。因此我们不必再惧怕一个设计的改变会破坏它。这让实施那些能够改进系统的设计变得更容易。因此测试的粉末登台意味着在持续改进系统的结构、设计和架构时遇到的阻碍会来得更少。

失去测试，架构设计就是天方夜谭，因为一但重大的开发启动后设计将很难改变。而自动化测试给设计留下了空间。设计改变所带来的风险如此之大的被削减，以至于我们可以在肆无忌惮中就让系统进化。


译注：
1，SDWest，全称Software Development West，即西部开发者大会，是全美颇受瞩目的开发者大会，著名的Jolt大奖就在每年一度的大会上颁发。
2，验收测试，原文acceptance test，又成为容忍测试，敏捷方法认为，如果一个构建（build）通过了验收测试，基本上这个构建就可被“接受了”。

（原文链接网址：http://www.butunclebob.com/ArticleS.UncleBob.ArchitectureIsaSecondaryEffect; Robert C. Martin的英文blog网址： http://www.butunclebob.com/ArticleS.UncleBob）

译者注：Robert C. Martin是Object Mentor公司总裁，面向对象设计、模式、UML、敏捷方法学和极限编程领域内的资深顾问。他不仅是Jolt获奖图书《敏捷软件开发：原则、模式与实践》（中文版）（《敏捷软件开发》（英文影印版））的作者，还是畅销书Designing Object-Oriented C++ Applications Using the Booch Method的作者。Martin是Pattern Languages of Program Design 3和More C++ Gems的主编，并与James Newkirk合著了XP in Practice。他是国际程序员大会上著名的发言人，并在C++ Report杂志担任过4年的编辑。