前幾天看到一篇架構(gòu)師已死的文章，頗為有趣，仔細(xì)想想，架構(gòu)師之所以興盛和之所以必死，多半是因?yàn)樘嗟娜藢?duì)軟件架構(gòu)師的工作存在諸多誤解的緣故。而諸多媒體和原廠商出于自身利益在國(guó)內(nèi)行業(yè)進(jìn)行的過度吹捧，給予了架構(gòu)和軟件架構(gòu)師太多的光芒，程序員們自然而讓的就把個(gè)人的職業(yè)規(guī)劃扔到了聚焦點(diǎn)上。
寫一些自己對(duì)架構(gòu)設(shè)計(jì)和架構(gòu)師的一些不是很成熟的看法，寫到哪算那，全當(dāng)口水了。
架構(gòu)的概念非常廣泛，解決的問題域空間也各有差距， 不能從一而論， 此處單指企業(yè)應(yīng)用的范圍而已，和互聯(lián)網(wǎng)應(yīng)用等其他范疇有較大差距。
1. 架構(gòu)是設(shè)計(jì)出來。
這是很多人對(duì)軟件架構(gòu)的一個(gè)最大誤解。
傳統(tǒng)的瀑布模型里，人為的劃分設(shè)計(jì)和編碼實(shí)現(xiàn)過程，也劃出了設(shè)計(jì)和驗(yàn)證過程的鴻溝，整體設(shè)計(jì)（概要設(shè)計(jì)）的可驗(yàn)證性，要在項(xiàng)目的中后期才能得到體現(xiàn)，這時(shí)候?yàn)闀r(shí)已晚。而為了保證設(shè)計(jì)的質(zhì)量，回避中后期風(fēng)險(xiǎn)，又往往會(huì)強(qiáng)調(diào)加強(qiáng)設(shè)計(jì)粒度和評(píng)審粒度，這樣一來，無形中又繼續(xù)加大了設(shè)計(jì)和驗(yàn)證的鴻溝，拖長(zhǎng)了問題反饋周期，規(guī)模越大的項(xiàng)目，問題越為突出。
據(jù)我的印象，業(yè)界中最早的最有影響的關(guān)于架構(gòu)和架構(gòu)師的界定其實(shí)來源于RUP.有別于傳統(tǒng)的瀑布模型的中的概要設(shè)計(jì)，軟件架構(gòu)很難再說是按流水線方式設(shè)計(jì)出來。架構(gòu)設(shè)計(jì)和概要設(shè)計(jì)的最大差別在于架構(gòu)設(shè)計(jì)更看重反饋和驗(yàn)證過程，更看重架構(gòu)師在整個(gè)軟件開發(fā)過程中的由始而終的參與。在rup中，項(xiàng)目早期的關(guān)鍵迭代都和架構(gòu)設(shè)計(jì)有直接關(guān)系。
架構(gòu)設(shè)計(jì)應(yīng)該強(qiáng)調(diào)通過更好的反饋-溝通-驗(yàn)證機(jī)制， 能在項(xiàng)目的較早期就得到技術(shù)和業(yè)務(wù)上的驗(yàn)證，為整個(gè)項(xiàng)目打下穩(wěn)定的基礎(chǔ)。 在某些敏捷開發(fā)過程中，架構(gòu)設(shè)計(jì)并不會(huì)作為一個(gè)顯著的KPI提出，更多是作為一種隱喻。通過使用迭代和其他更好的反饋交流機(jī)制，讓項(xiàng)目的架構(gòu)設(shè)計(jì)在在項(xiàng)目的前期以驗(yàn)證和演進(jìn)的方式完成。可以說一個(gè)真正的架構(gòu)設(shè)計(jì)，必須是可以有效驗(yàn)證的。
而現(xiàn)在很多公司和組織流行的先讓大拿組織做設(shè)計(jì)，設(shè)計(jì)做完再評(píng)審，然后丟給小兵去干活的架構(gòu)設(shè)計(jì)流程，實(shí)際是對(duì)瀑布模型的繼續(xù)，我個(gè)人認(rèn)為是完全背道而馳的。我多次參加過這樣的架構(gòu)設(shè)計(jì)評(píng)審，基本上可以說沒有什么有真正營(yíng)養(yǎng)的東西，只是一些流行概念的堆砌，昨天EJB,今天SSH，明天又是OSGI，這樣的架構(gòu)設(shè)計(jì)作出來也有可能會(huì)大幅度修改，或者堅(jiān)決不修改讓下面的人痛苦不堪，所謂的評(píng)審和存檔過程只是自欺欺人而已。再考慮現(xiàn)在各大公司流行的CMM/CMMI，過程改進(jìn)管理，這些paper的工作還可能會(huì)因?yàn)橐霃?fù)雜的審批修改流程把人拖入泥潭。
這種做法，在java圈子里面，因?yàn)樵缙趕un和一些大公司對(duì)架構(gòu)和模式概念的極力鼓吹，大為盛行。某些人甚至只是看完了blueprint，做了幾個(gè)tutorial，就搖身一變架構(gòu)師，開始了架構(gòu)設(shè)計(jì)生涯。
這樣的架構(gòu)師也往往很少編寫代碼（我們可以理解，一個(gè)人寫完300頁(yè)的設(shè)計(jì)文檔以后，還有多少意愿再去寫實(shí)現(xiàn)代碼？），很少參與項(xiàng)目的開發(fā)工作，只滿足做一些試驗(yàn)性質(zhì)的代碼工作（對(duì)呀，現(xiàn)在開源東西這么多，流行的東西組裝一下架構(gòu)設(shè)計(jì)就算over了么，還實(shí)現(xiàn)什么設(shè)計(jì)）和指導(dǎo)工作，甚至有些paper的架構(gòu)師，完全就是靠粗讀各種pattern和x寶典來做設(shè)計(jì)，設(shè)計(jì)的可行性和高風(fēng)險(xiǎn)性，可想而知，早期大量EJB的濫用導(dǎo)致的項(xiàng)目失敗，其實(shí)根本原因在于甚少有架構(gòu)師以驗(yàn)證演進(jìn)的手段來決定是否應(yīng)該使用EJB，怎樣合理的使用EJB，將架構(gòu)設(shè)計(jì)草率的外包給各大原廠商鼓吹的概念或者各種blueprint。而小兵們?cè)诿鎸?duì)架構(gòu)+模式兩頂大帽的時(shí)候也只會(huì)怯懦的懷疑自己的個(gè)人能力，然后堅(jiān)持不懈的向架構(gòu)師這一偉大位置繼續(xù)奮斗。
而另一方面項(xiàng)目管理者也往往會(huì)誤以為有了正規(guī)的架構(gòu)設(shè)計(jì)就可以更好的保證軟件項(xiàng)目質(zhì)量，可以將項(xiàng)目的重心放置在需求和非技術(shù)工作之外，可以不用再考慮一般程序員的技術(shù)能力問題， 可以大幅度的xxx，xxx， 最后一堆苦水，然后再把責(zé)任歸咎于架構(gòu)師不成熟。
我早年經(jīng)歷過的幾個(gè)項(xiàng)目就有此方面沉痛的教訓(xùn)，事后我個(gè)人復(fù)審設(shè)計(jì)，發(fā)現(xiàn)基本上整個(gè)方向都是錯(cuò)誤的，個(gè)別項(xiàng)目設(shè)計(jì)者甚至連EJB的一些基本概念都沒有了解，自己重頭實(shí)現(xiàn)了一遍。過長(zhǎng)的驗(yàn)證周期導(dǎo)致后期已經(jīng)無法再做任何修改，只能咬牙吞下。
真正實(shí)用的架構(gòu)是以逐步嚴(yán)謹(jǐn)?shù)姆绞津?yàn)證出來的，即便是自稱中國(guó)java NO.1的袁紅崗告訴你EJB非常好，沒有EJB的架構(gòu)就不是真正的J2EE架構(gòu)，你也要驗(yàn)證以后再說，在此順便bs一下csdn。
在那篇架構(gòu)師之死的小品里，boss問小兵，你如何說服大家要使用hibernate？ 其實(shí)答案很簡(jiǎn)單，架構(gòu)又不是設(shè)計(jì)出來的， 為什么要說服？