這是敏捷中國的一個討論，我問了一下架構設計是否在敏捷迭代過程中有一席之地？大家產(chǎn)生了如下討論。如果我的引用冒犯了當事人，請email我，我會及時修改的。我希望大家能夠一起討論這個topic。
我提出問題：
今天看到InfoQ的一篇文章：敏捷開發(fā)實踐真的不利于架構設計嗎？（
http://www.infoq.com/cn/news/2007/07/AgileBadForDesign）
感覺內(nèi)容非常好，我們的確應該思考一下如何平衡早期的宏觀架構決定和按需求實現(xiàn)的微觀設計，尤其在執(zhí)行敏捷的實踐的時候。
我這樣想，大家可以一起討論一下：
架構是預先設計。實踐證明過早的做決定容易造成過度設計。
但是將決定全部后移則會造成大量浪費性的重構（重構也有可能繞彎路，說明此時的重構使用不當），此時又凸顯了架構設計的價值。
所以1方面架構師非常重要，另一方面從迭代的流程上也應該強調架構設計這個環(huán)節(jié)，要從宏觀和微觀兩個方面保證設計。
我覺得本文這句話很重要"與傳統(tǒng)開發(fā)技術相比，這些工具被不正確的使用是否更危險？"
我想回答是肯定的，如果使用不正確那么更危險。
Shane Duan這樣回復：
我一向的觀點是：如果一個人或小組不能正確的使用重構的工具和方法的話，這個人或小組也不可能做好什么前期的架構.
在這種情況下，先做架構或后做重構對他們的效果是一樣的. 只不過先做架構聽上去好聽一點罷了．
就算我見識淺薄罷. 我見過的和信任的好的架構師都是會寫代碼，會做重構的. 所以在這種情況下，說＂架構師非常重要＂當然是正確的.
小刀回復：
關于敏捷的缺點的爭論，InfoQ上前面還有兩篇新聞：
一篇是有關敏捷度量：
http://www.infoq.com/cn/news/2007/07/Agile_Measurement
一篇也是有關架構的問題：http://www.infoq.com/cn/news/2007/06/enough-agile-architecture
后一篇是舉了一個應用中出現(xiàn)的問題來反駁敏捷中"Just Enough"這種觀點的，文中說：
"一個應用每天早上5點都會宕掉，同時宕掉的還有一個只用于查詢的數(shù)據(jù)庫。引發(fā)這個問題的地方——同時也是受害者——包括一個Web服務器，一個數(shù)據(jù)庫服務器和一個防火墻。如果有些人的第一個想法就是：如果你只是查詢的話，那根本不會導致死鎖??！這些人就應該去看看Nygard到底發(fā)現(xiàn)了什么。"
感覺宏觀架構與微觀設計的平衡真的很重要，但是也很難。比如，在什么樣的情況下，Big Design Up
Front有價值，而在什么情況下它又是無謂的浪費呢？
lixiao回復：
其實敏捷并沒有說非要丟掉前期設計，相對傳統(tǒng)方法，敏捷方法更寬容，只是更多的實踐情況是采用樂重構的方式獲得系統(tǒng)設計的架構，我相信實踐出真知。
Mingle項目早期計劃是在發(fā)布版本中使用Derby數(shù)據(jù)庫的，這個算是前期系統(tǒng)架構吧，但是在early access release臨近的時候，
發(fā)現(xiàn)有些細節(jié)問題難以達到要求，于是迅速換成樂配置Mysql和postgres的方式。
相對于在前期花時間和精力來避免潛在得問題，我們采取的是為應對突發(fā)事件做充分的準備，TDD帶來豐富的單元測試，為所有BUG、STORY和主要業(yè)務流程創(chuàng)建自動化功能測試，幾個CC
BUILD一起跑以保證兼容性，包括數(shù)據(jù)庫、瀏覽器、運行環(huán)境（JRuby & CRuby）等。
我相信這樣做相對更多時間和精力的前期設計價值高得多樂。
徐八插回復：
柔缺剛是攻而不克，剛缺柔是浪費力氣...
莫映回復：
非常非常同意Shane的講法，很有同感！
不只一次的聽到人們對敏捷方法在不強調設計方面的疑慮，一些經(jīng)典的講法就是：好的架構不是重構出來的，敏捷開發(fā)對人有很高的要求，等等。
其實，我覺得可能這是人們在接受新事物時很自然的一種慣性思維吧，可以理解。事實上，即便不用敏捷實踐，先期的設計就能做的足夠好了嗎，恐怕也是因人而異的，菜
鳥依然未必能做好設計。就像看到一些團隊的leader，他們強調團隊成員們一定要做嚴格的設計、思維實驗、沙盤模擬，等等。但是，所有這些都不是建立在實踐的基礎上，從這個角度而言，反而對開發(fā)者提出了*更高*的技能要求。而敏捷中很本質性的一個思路就是*迭代反饋*以及*推遲決策*，通過不斷的反復實踐來獲得足夠的反饋，然后再腳踏實地的做設計決策，從這個角度而言，反而可以認為對人的要求*降低*了，因為不需要在開始的時候一下子設計的很*完美*。如果抓住敏捷中的這兩點，剩下的敏捷最佳實踐，大概就是如何保證這兩點能夠很好達成的手段而已了，也許，以人們的聰明才智，還可以發(fā)揮一下，創(chuàng)造出屬于自己的最佳實踐來，呵呵。。。
我回復：
我非常認同*推遲決策*。這也是我問這個問題的原因。
我想如果所有的決策都在最后提出，那么也是缺乏設計，這個是與不敏捷造成的過渡設計向反的方向。
而實際，應該有一個這種的方案。也就是徐X說的"柔缺剛是攻而不克，剛缺柔是浪費力氣"。
最近在看CrystalClear，這種體系有一個方針就是"借鑒"，吸取的是最佳實踐。而且，每個團隊應該通過項目回顧來不斷的改進這個過程。所以，
我覺得在每一論迭代的計劃階段有一個專門的架構討論是非常好的，所以想知道大家是如何實踐的。
Shane說的一點比較偏激，所謂用不好敏捷工具的人就設計不出好的架構，這個我非常不同意。因為Cockburn就說過程只是產(chǎn)生良好代碼設計的一個
因素，不是全部因素。傳統(tǒng)軟件過程一樣能夠產(chǎn)生好的代碼，這個我們不應該迷信。Gigix不是最近也在說中庸這個問題么？我覺得這個很辯證呀。轉型階段
的團隊，可能還是需要考慮如何使用好敏捷過程，而不要造成用不好反而浪費資源的情況。
我和一位在中國旅行的德國程序員（中軟）討論這個問題的時候，他說我們認為過程是Tools，而中國人（指中軟的同事）認為過程是God，當然他說這個
主要是針對CMM，但是對敏捷這種說法也一樣行得通。
例如，MVC應該不是TDD出來的，當然這種思想的形成過程可能是思維的迭代出來的。我是想說，我覺得預先架構的考量應該被加入敏捷的迭代過程中，畢竟
大家不能總是依賴排腦袋就來的東西。