我最早聽(tīng)說(shuō)“軟件架構”這個(gè)概念以及UML的名字，是在1999年的水木清華BBS上。當時(shí)有一篇文章介紹了軟件架構作為一個(gè)相對獨立的領(lǐng)域的發(fā)展情況，順便提到在此前一年被接納為OMG標準的UML。該文作者斷言，UML的出現將能“徹底”改變軟件開(kāi)發(fā)的工作方式，甚至“若干年之后，不通UML者無(wú)法染指軟件開(kāi)發(fā)”。三年之后，專(zhuān)訪(fǎng)Ivar Jacobson時(shí)，UML已經(jīng)是盡人皆知。記得Jacobson在那次采訪(fǎng)中勸告中國的開(kāi)發(fā)者，趕快去學(xué)習RUP。從那時(shí)候起，越來(lái)越多的人頂上了“軟件架構師”的頭銜，張口模式閉口架構，一時(shí)間好不風(fēng)光。然而最初的熱乎勁過(guò)去之后，人們發(fā)現，“不通UML者無(wú)法染指軟件開(kāi)發(fā)”的預言似乎落了空，而一些軟件架構師們似乎也并不那么神乎其技，很多時(shí)候反而不如那些實(shí)實(shí)在在寫(xiě)代碼的人管用。他們所宣傳的那些架床迭屋的抽象層，那些復雜精致的模式設計，看上去精美無(wú)比，柔性十足，然而實(shí)踐當中一個(gè)出乎意料的小變更，便常常能把這一切打得粉碎。他們樂(lè )談的松耦合，小接口，往往只是說(shuō)起來(lái)好聽(tīng)，實(shí)際很難落實(shí)，或者代價(jià)過(guò)高，有的時(shí)候，反而是反其道而行之，才更“管用”。
為什么會(huì )出現這種情況？我想這里有客觀(guān)和主觀(guān)的原因。
就客觀(guān)原因來(lái)說(shuō)，軟件開(kāi)發(fā)畢竟還是年輕的行業(yè)，各方面還在劇烈發(fā)展和變化中。如果把軟件技術(shù)做一個(gè)層次劃分的話(huà)，軟件架構及設計屬于上層建筑，而像程序設計語(yǔ)言、技術(shù)平臺、數據管理技術(shù)、網(wǎng)絡(luò )體系結構等，均在其之下，屬于基礎。這幾年隨著(zhù)互聯(lián)網(wǎng)的飛速發(fā)展，基礎尚且在劇烈變化當中，上層建筑自然會(huì )搖搖晃晃，甚至趕不上趟。具體來(lái)說(shuō)，當今的軟件體系結構設計總體上是基于面向對象思想，而且是強類(lèi)型語(yǔ)言時(shí)代的面向對象思想，而動(dòng)態(tài)語(yǔ)言的出現和流行，實(shí)際上很大程度上顛覆了傳統面向對象思想的一些原則。例如，人們曾經(jīng)認為封裝非常重要，對象成員能夠隱藏便應當盡量隱藏，但是Python和Ruby中public是常態(tài)，private反而是變態(tài)，實(shí)踐當中也工作的很好，甚至更好。再例如，幾年來(lái)人們津津樂(lè )道的設計模式，其中有很多在動(dòng)態(tài)語(yǔ)言里毫無(wú)必要。而很多在關(guān)系數據庫時(shí)代被視為秘笈的數據存儲與訪(fǎng)問(wèn)模式，比如層次關(guān)系的表達，反規范化的經(jīng)驗，放到后關(guān)系性數據庫里就沒(méi)有多大意義了。再諸如應用的Web化、RIA、SOA等基本思想的變遷，都是能引起整個(gè)軟件技術(shù)格局強烈震蕩的大事件，所有這些進(jìn)行中的劇烈變化，不可能不對軟件架構的設計產(chǎn)生影響，從而使得很多關(guān)于架構設計的思想迅速過(guò)時(shí)或者必須調整。如果架構師們不能夠充分重視實(shí)踐，與時(shí)俱進(jìn)，那么就很有可能做出不合時(shí)宜的設計。
就主觀(guān)原因來(lái)說(shuō)，很多軟件架構師走入了一個(gè)誤區，即一旦升級為架構師，就可以脫離具體的代碼實(shí)踐，可以陽(yáng)春白雪了。事實(shí)上，由于下層技術(shù)的變化迅速，架構師一旦脫離代碼實(shí)踐，脫離現實(shí)應用，很快就會(huì )與實(shí)實(shí)在在的軟件開(kāi)發(fā)工作產(chǎn)生距離感，忘卻一線(xiàn)開(kāi)發(fā)者需要面對的現實(shí)問(wèn)題，做出一些不切實(shí)際的設計決策。這樣的設計，或者執行不下去，或者執行下去也代價(jià)巨大，該解決的問(wèn)題沒(méi)解決，卻在無(wú)關(guān)緊要的問(wèn)題上大做文章。毫無(wú)疑問(wèn)，這樣的設計得不到一線(xiàn)開(kāi)發(fā)者的衷心支持，得不到好的結果。架構設計跟開(kāi)發(fā)發(fā)生矛盾，誰(shuí)有問(wèn)題？多半是架構設計出了問(wèn)題。因為開(kāi)發(fā)直接面對實(shí)踐，直接從事實(shí)踐，開(kāi)發(fā)出了問(wèn)題，那就是實(shí)踐在向自以為是的偽真理宣戰了。然而，一部分架構師不去檢討自己脫離實(shí)踐的設計，卻搞起本本主義，硬拿書(shū)本教條死扣實(shí)際。另一方面，如果開(kāi)發(fā)者對于架構設計的原則和嘗試缺乏了解，不愿意提高對于軟件架構設計的認識和理解，不愿意付出對長(cháng)遠有利的代價(jià)，也不理解，不支持，甚至消極抵制架構師的決定，那么同樣會(huì )引起架構設計與開(kāi)發(fā)之間的矛盾。結果往往是，兩個(gè)必要的角色之間產(chǎn)生矛盾。開(kāi)發(fā)者抱怨架構設計華而不實(shí)，架構師抱怨開(kāi)發(fā)者不嚴格按設計行事，進(jìn)而相互質(zhì)疑對方角色的必要性。開(kāi)發(fā)者認為架構師就是吃干飯的文人，根本應該人間蒸發(fā)，沒(méi)有存在的必要，而架構師則覺(jué)得開(kāi)發(fā)者是一群無(wú)組織無(wú)紀律的驕傲的野貓，幻想有朝一日自動(dòng)代碼生成器能把這幫不聽(tīng)話(huà)的開(kāi)發(fā)者趕出山門(mén)。
事實(shí)上，開(kāi)發(fā)者和架構師都是軟件開(kāi)發(fā)中必不可少的角色，即使在單人開(kāi)發(fā)的項目中，開(kāi)發(fā)者本人也需要經(jīng)常在這兩個(gè)角色之間切換。兩個(gè)角色的相互理解，和諧協(xié)作，才能夠共同克服現實(shí)困難，開(kāi)發(fā)成功的軟件。在促進(jìn)這種和諧的過(guò)程中，開(kāi)發(fā)者應當積極學(xué)習架構設計的理論并充分實(shí)踐，而架構師則需要本著(zhù)務(wù)實(shí)的態(tài)度貼近一線(xiàn)。
因為從事技術(shù)媒體工作，我也確實(shí)結識了幾個(gè)優(yōu)秀的架構設計師，他們身上的共同特點(diǎn)就是務(wù)實(shí)。這些架構師都具有多年的軟件開(kāi)發(fā)經(jīng)驗，對軟件本質(zhì)的理解相當深入，本身就是開(kāi)發(fā)高手。與一般開(kāi)發(fā)高手不同的是，他們充分實(shí)踐，但不宥于實(shí)踐，而是積極地學(xué)習軟件架構的理論，嘗試用理論來(lái)指導實(shí)踐。而與整天高談闊論的理論架構師不同的是，他們掌握了理論之后，一定要親自落實(shí)，用實(shí)踐來(lái)檢驗。當理論與實(shí)踐產(chǎn)生矛盾的時(shí)候，他們既不會(huì )輕易否定理論，更不會(huì )教條主義般地削足適履，而是認真分析矛盾產(chǎn)生的原因，研究可能的對策。在反復思考和實(shí)踐之下，他們敢于做出“離經(jīng)叛道”的結論，敢于質(zhì)疑大師偶像的論斷，更能夠在錯綜復雜的實(shí)際做出簡(jiǎn)單、可靠、靈活而便于實(shí)現的設計，并且向開(kāi)發(fā)者傳達意圖，答疑解惑，實(shí)現整個(gè)團隊的思想一致。他們做出的設計，開(kāi)發(fā)者看得懂，做得出，自然會(huì )得到衷心的擁護。
聯(lián)系客服
