这是敏捷中国的一个讨论，我问了一下架构设计是否在敏捷迭代过程中有一席之地？大家产生了如下讨论。如果我的引用冒犯了当事人，请email我，我会及时修改的。我希望大家能够一起讨论这个topic。
我提出问题：
今天看到InfoQ的一篇文章：敏捷开发实践真的不利于架构设计吗？（
http://www.infoq.com/cn/news/2007/07/AgileBadForDesign）
感觉内容非常好，我们的确应该思考一下如何平衡早期的宏观架构决定和按需求实现的微观设计，尤其在执行敏捷的实践的时候。
我这样想，大家可以一起讨论一下：
架构是预先设计。实践证明过早的做决定容易造成过度设计。
但是将决定全部后移则会造成大量浪费性的重构（重构也有可能绕弯路，说明此时的重构使用不当），此时又凸显了架构设计的价值。
所以1方面架构师非常重要，另一方面从迭代的流程上也应该强调架构设计这个环节，要从宏观和微观两个方面保证设计。
我觉得本文这句话很重要"与传统开发技术相比，这些工具被不正确的使用是否更危险？"
我想回答是肯定的，如果使用不正确那么更危险。
Shane Duan这样回复：
我一向的观点是：如果一个人或小组不能正确的使用重构的工具和方法的话，这个人或小组也不可能做好什么前期的架构.
在这种情况下，先做架构或后做重构对他们的效果是一样的. 只不过先做架构听上去好听一点罢了．
就算我见识浅薄罢. 我见过的和信任的好的架构师都是会写代码，会做重构的. 所以在这种情况下，说＂架构师非常重要＂当然是正确的.
小刀回复：
关于敏捷的缺点的争论，InfoQ上前面还有两篇新闻：
一篇是有关敏捷度量：
http://www.infoq.com/cn/news/2007/07/Agile_Measurement
一篇也是有关架构的问题：http://www.infoq.com/cn/news/2007/06/enough-agile-architecture
后一篇是举了一个应用中出现的问题来反驳敏捷中"Just Enough"这种观点的，文中说：
"一个应用每天早上5点都会宕掉，同时宕掉的还有一个只用于查询的数据库。引发这个问题的地方——同时也是受害者——包括一个Web服务器，一个数据库服务器和一个防火墙。如果有些人的第一个想法就是：如果你只是查询的话，那根本不会导致死锁啊！这些人就应该去看看Nygard到底发现了什么。"
感觉宏观架构与微观设计的平衡真的很重要，但是也很难。比如，在什么样的情况下，Big Design Up
Front有价值，而在什么情况下它又是无谓的浪费呢？
lixiao回复：
其实敏捷并没有说非要丢掉前期设计，相对传统方法，敏捷方法更宽容，只是更多的实践情况是采用乐重构的方式获得系统设计的架构，我相信实践出真知。
Mingle项目早期计划是在发布版本中使用Derby数据库的，这个算是前期系统架构吧，但是在early access release临近的时候，
发现有些细节问题难以达到要求，于是迅速换成乐配置Mysql和postgres的方式。
相对于在前期花时间和精力来避免潜在得问题，我们采取的是为应对突发事件做充分的准备，TDD带来丰富的单元测试，为所有BUG、STORY和主要业务流程创建自动化功能测试，几个CC
BUILD一起跑以保证兼容性，包括数据库、浏览器、运行环境（JRuby & CRuby）等。
我相信这样做相对更多时间和精力的前期设计价值高得多乐。
徐八插回复：
柔缺刚是攻而不克，刚缺柔是浪费力气...
莫映回复：
非常非常同意Shane的讲法，很有同感！
不只一次的听到人们对敏捷方法在不强调设计方面的疑虑，一些经典的讲法就是：好的架构不是重构出来的，敏捷开发对人有很高的要求，等等。
其实，我觉得可能这是人们在接受新事物时很自然的一种惯性思维吧，可以理解。事实上，即便不用敏捷实践，先期的设计就能做的足够好了吗，恐怕也是因人而异的，菜
鸟依然未必能做好设计。就像看到一些团队的leader，他们强调团队成员们一定要做严格的设计、思维实验、沙盘模拟，等等。但是，所有这些都不是建立在实践的基础上，从这个角度而言，反而对开发者提出了*更高*的技能要求。而敏捷中很本质性的一个思路就是*迭代反馈*以及*推迟决策*，通过不断的反复实践来获得足够的反馈，然后再脚踏实地的做设计决策，从这个角度而言，反而可以认为对人的要求*降低*了，因为不需要在开始的时候一下子设计的很*完美*。如果抓住敏捷中的这两点，剩下的敏捷最佳实践，大概就是如何保证这两点能够很好达成的手段而已了，也许，以人们的聪明才智，还可以发挥一下，创造出属于自己的最佳实践来，呵呵。。。
我回复：
我非常认同*推迟决策*。这也是我问这个问题的原因。
我想如果所有的决策都在最后提出，那么也是缺乏设计，这个是与不敏捷造成的过渡设计向反的方向。
而实际，应该有一个这种的方案。也就是徐X说的"柔缺刚是攻而不克，刚缺柔是浪费力气"。
最近在看CrystalClear，这种体系有一个方针就是"借鉴"，吸取的是最佳实践。而且，每个团队应该通过项目回顾来不断的改进这个过程。所以，
我觉得在每一论迭代的计划阶段有一个专门的架构讨论是非常好的，所以想知道大家是如何实践的。
Shane说的一点比较偏激，所谓用不好敏捷工具的人就设计不出好的架构，这个我非常不同意。因为Cockburn就说过程只是产生良好代码设计的一个
因素，不是全部因素。传统软件过程一样能够产生好的代码，这个我们不应该迷信。Gigix不是最近也在说中庸这个问题么？我觉得这个很辩证呀。转型阶段
的团队，可能还是需要考虑如何使用好敏捷过程，而不要造成用不好反而浪费资源的情况。
我和一位在中国旅行的德国程序员（中软）讨论这个问题的时候，他说我们认为过程是Tools，而中国人（指中软的同事）认为过程是God，当然他说这个
主要是针对CMM，但是对敏捷这种说法也一样行得通。
例如，MVC应该不是TDD出来的，当然这种思想的形成过程可能是思维的迭代出来的。我是想说，我觉得预先架构的考量应该被加入敏捷的迭代过程中，毕竟
大家不能总是依赖排脑袋就来的东西。