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