這是敏捷中國的一個討論，我問了一下架構設計是否在敏捷迭代過程中有一席之地？大家產生了如下討論。如果我的引用冒犯了當事人，請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出來的，當然這種思想的形成過程可能是思維的迭代出來的。我是想說，我覺得預先架構的考量應該被加入敏捷的迭代過程中，畢竟
大家不能總是依賴排腦袋就來的東西。