標(biāo)準(zhǔn)來源于目標(biāo)

評價(jià)架構(gòu)好壞是一個(gè)很主觀的東西。既然大家寫出來的程序都能跑，憑什么就說你架構(gòu)好，我的架構(gòu)就差?拿出來大家評評理，張三說好，李四說不行，王五說將就……究竟誰說了算?現(xiàn)在已經(jīng)不是一個(gè)迷信權(quán)威的時(shí)代了，所以不管你多少光環(huán)加持，你都得說出子丑寅卯來，都得服眾才行。

我覺得，這種現(xiàn)象的產(chǎn)生，拋開“同行相輕”和“流派之爭”之類無厘頭的東西，一個(gè)很重要的原因就是沒有明確判斷標(biāo)準(zhǔn)。所以在網(wǎng)上，常常就出現(xiàn)這樣一種很熱鬧很奇葩很無奈的現(xiàn)象：我和你說性能，你跟我說安全;我跟你說安全，你跟我說擴(kuò)展;我跟你說擴(kuò)展，你跟我說維護(hù);我跟你說維護(hù)，你跟我說成本……

這是一個(gè)很簡單的道理，沒有標(biāo)準(zhǔn)，就無法進(jìn)行評判!所以，如果不能統(tǒng)一一個(gè)評判架構(gòu)優(yōu)劣的標(biāo)準(zhǔn)，我們永遠(yuǎn)無法達(dá)成一致。你說有標(biāo)準(zhǔn)啊，性能安全可擴(kuò)展……但這樣還是不行，標(biāo)準(zhǔn)過多，一樣等同于沒有標(biāo)準(zhǔn)。假設(shè)以100分為滿分，性能占多少分?安全占多少分?可擴(kuò)展又占多少分?因?yàn)橐胩岣咝阅埽涂赡芫鸵獱奚蓴U(kuò)展性;要想安全，就會(huì)犧牲性能;要想……就會(huì)……;哪一方面更重要，哪一些可以犧牲?如果不是胸有成竹的話，最后還是會(huì)左支右絀手忙腳亂，亂成一鍋粥。

所以我再提出一個(gè)觀點(diǎn)：以是否實(shí)現(xiàn)架構(gòu)師的設(shè)計(jì)目標(biāo)為標(biāo)準(zhǔn)。如果說一個(gè)系統(tǒng)的架構(gòu)，最終實(shí)現(xiàn)了架構(gòu)師的設(shè)計(jì)目標(biāo)，我們就可以說這是一個(gè)好架構(gòu);如果說沒有能實(shí)現(xiàn)架構(gòu)師的目標(biāo)，這就是一個(gè)不那么好的架構(gòu)。

“等一下等一下”，你要是反應(yīng)夠敏銳的話，肯定會(huì)跳起來，“這是不是太主觀(兒戲)了?我隨便一堆爛代碼，然后告訴你，‘是啊，我設(shè)計(jì)的目的就是讓他爛，越難越好’，按你的邏輯，這樣也行?”(⊙_⊙)，嗯，你要是這樣玩兒我還真沒辦法。但是話又說回來，要讓一堆代碼能跑又還夠“爛”，也還不是一件容易的事，你覺得呢?

總之，我希望大家能明白我的意思：架構(gòu)師開始一個(gè)新項(xiàng)目，應(yīng)當(dāng)設(shè)立一個(gè)適當(dāng)?shù)脑O(shè)計(jì)目標(biāo);然后通過架構(gòu)，努力實(shí)現(xiàn)其預(yù)定目標(biāo)。如果最終系統(tǒng)的運(yùn)行，符合其設(shè)計(jì)預(yù)期，我們就可以說：這個(gè)架構(gòu)不錯(cuò)還行!反正，架構(gòu)就出了問題。

我們的目標(biāo)

軟件行業(yè)有各種各樣的系統(tǒng)，每一種系統(tǒng)的開發(fā)都可能會(huì)有不同的目標(biāo)。比如導(dǎo)彈發(fā)射的系統(tǒng)，我們可以想象，目標(biāo)(甚至是基本要求)肯定是：1、穩(wěn)定(絕對不能走火);2、迅速反應(yīng)(不允許按下發(fā)射按鈕后一分鐘導(dǎo)彈才開始發(fā)射)。你可能覺得這種要求很好啊!任何系統(tǒng)不都是應(yīng)該滿足這樣要求的嗎?比如我在淘寶買T恤，結(jié)果給我發(fā)一條丁字褲，這怎么行?一個(gè)網(wǎng)頁半天打不開還有理了?我還真得答一句，它就是有理了。“存在即合理”，這里的合理，合理在成本。我們目前日常使用到的絕大部分軟件，都是有bug的，而且是一堆的bug，但我們?nèi)匀辉谑褂盟鼈儭Ｈ绻阆胧褂孟?ldquo;導(dǎo)彈發(fā)射”一樣穩(wěn)定精確迅捷的軟件，可能最后的結(jié)果只有一個(gè)：你用不起。(請自行腦補(bǔ))

所以，其實(shí)我們是做了一個(gè)妥協(xié)，“便宜點(diǎn)，將就用吧”。我們?yōu)榱诉_(dá)到我們的基本目的，犧牲掉一些“無關(guān)緊要”的東西。對于很多追求卓越的程序員來說，這種犧牲妥協(xié)是難以接受的。“白玉微瑕，你讓我怎么能夠接受?”——但很多時(shí)候，你必須接受。這個(gè)問題這個(gè)觀點(diǎn)，我們會(huì)在整個(gè)系列中不斷的提及。請?jiān)囍邮?如果你暫時(shí)還不能接受，請牢記：沒有犧牲，就沒有勝利!

那么，我們的策略是：特色突出、整體均衡。說得更直白一點(diǎn)：有亮點(diǎn)，沒硬傷。這就夠了!而我們的亮點(diǎn)就是：可維護(hù)性。(注意：不是可擴(kuò)展，可維護(hù)性包含可擴(kuò)展，但不僅僅是可擴(kuò)展)

為什么是可維護(hù)性

幸或者不幸，我進(jìn)入軟件行業(yè)之后，絕大部分的工作是幾乎所有程序員都不齒厭惡的維護(hù)。我曾經(jīng)維護(hù)過一個(gè)有十年歷史的、糅合了C、VB、java、C#各種語言在內(nèi)的一個(gè)物流系統(tǒng)的部件。我在那家公司工作了一年多，說實(shí)話，直到我離職，對整個(gè)系統(tǒng)，我連邊都沒摸到——這個(gè)系統(tǒng)太大了，而且連我們公司都只是其主營公司眾多外包公司中的一個(gè)。

在我花了兩周的時(shí)間找到一個(gè)bug的位置之后，我以為我終于明白了為什么會(huì)說：“維護(hù)和開發(fā)的花費(fèi)比是80:20”。但這只是我以為——現(xiàn)實(shí)更加殘忍：差不多一個(gè)月后，我又花了一個(gè)星期的時(shí)間，找到了另外一個(gè)bug的根源，正是我fix前一個(gè)bug所產(chǎn)生的。我淚流滿面，有沒有?腦子里一下就蹦出個(gè)詞：“按下了葫蘆浮起了瓢”!總之，如果fix前一個(gè)bug就會(huì)導(dǎo)致后一個(gè)bug;如果fix后一個(gè)bug，就會(huì)導(dǎo)致前面的bug。我忘了最后是怎么處理這個(gè)問題的，依稀記得是讓項(xiàng)目經(jīng)理去和稀泥去了。因?yàn)檫@不是一個(gè)很關(guān)鍵很常用的功能，所以最后大概是不了了之吧。

后來我了解到，很多的開發(fā)項(xiàng)目，是這樣一個(gè)流程：一群人根據(jù)文檔開始開發(fā)，幾個(gè)月后通過驗(yàn)收上線;然后開發(fā)團(tuán)隊(duì)解散，留下一兩個(gè)項(xiàng)目組里最菜的菜鳥做“維護(hù)”。Game Over!皆大歡喜。這種現(xiàn)象，在各種外包團(tuán)隊(duì)(尤其是以項(xiàng)目計(jì)價(jià)的廉價(jià)外包團(tuán)隊(duì))中更加的突出(這或許也是大家普遍歧視外包公司的一個(gè)原因?)

既然是這樣一種開發(fā)模式，很多開發(fā)人員根本體會(huì)不到維護(hù)的痛苦。在他們看來，“維護(hù)嘛，修修補(bǔ)補(bǔ)，加一兩個(gè)if...else而已，讓我們開發(fā)人員做更高大上的工作吧!”但他們也不是總這么幸運(yùn)，有時(shí)候，他們會(huì)被抓去“填坑”。據(jù)說最通常的做法，就是在“老坑”周圍再挖一堆“新坑”，填平之前的老坑即可。周而復(fù)始，直到有一天，“受不了啦!我們重寫吧!”——等等，為什么不重構(gòu)?呵呵，好問題，你覺得呢?

需求變更

很多程序員把這種困境歸咎于“需求變更”。如果不是那些傻逼客戶一天到晚的改需求，我一定會(huì)做出一個(gè)完美的作品!

或許是因?yàn)槲沂前肼烦黾业脑颍秃芏喑绦騿T相反，我覺得：不是需求變更驅(qū)動(dòng)著軟件的不斷更改，而是“軟件可以隨意更改”的這種特性刺激了不斷的需求變更。你裝修好的房子，是不是住一段時(shí)間之后就會(huì)覺得這里那里不合適?這里少了一個(gè)插座，陽臺上該加一個(gè)龍頭，櫥柜用著不順手……“要是能改改就更好了!”，只是這樣的改動(dòng)太費(fèi)力，所以大多數(shù)時(shí)間我們都還是算了。但軟件可以!理論上怎么改都可以。想想軟件真的是一種很特殊的商品——它是可以交付“半成品”的。你先用著，如果有問題我再改改，有新需求我再改改，一直可以改到面目全非。沒有在其他傳統(tǒng)行業(yè)里待過的程序員無法理解，“可以隨意更改”是一種多么出色的特質(zhì)。這意味著產(chǎn)品可以自我進(jìn)化，應(yīng)對各種變化，可以永生!想象這樣一臺“汽車”，開始可以在馬路上跑，過段時(shí)間改一下就可以在水里游，再拆裝一下可以當(dāng)摩托拉風(fēng)，堵車的時(shí)候展開翅膀……這是什么樣一種屌爆天的體驗(yàn)啊?

所以，“擁抱變化”絕不是一句口號，這是一種胸懷。

作為示例的這兩個(gè)系統(tǒng)，我是希望能用他們一輩子的。但我甚至無法想象一年之后他們會(huì)是什么樣子——他們需要接受市場的檢驗(yàn)，應(yīng)對技術(shù)的升級換代，會(huì)有各種想象不到的變化。所以，可維護(hù)性無疑是必須放到首位的。

為了可維護(hù)

明確了架構(gòu)的首要目標(biāo)，我們就可以做一些基礎(chǔ)的選擇了。比如開發(fā)語言，可是是面向?qū)ο蟮腃#，不需要“性能卓越”的C。

說道“面向?qū)ο?rdquo;，可能有些同學(xué)就會(huì)比較high，腦子里就會(huì)冒出“抽象”、“封裝”、“設(shè)計(jì)模式”等各種高大上的東西出來。但我不得不提醒你們：首先，這些都是微觀層面考慮的東西，而架構(gòu)是宏觀的;然后，這些都不是架構(gòu)，而是潤滑黏合支持架構(gòu)的東西;最后，在其他條件不變的情況下，系統(tǒng)中這些東西用得越少，說明架構(gòu)越好。

我們以“設(shè)計(jì)模式”為例。大家在學(xué)習(xí)設(shè)計(jì)模式的過程中有沒有這樣一種困惑，“這樣繼承封裝多態(tài)亂七八糟的繞來繞去的干嘛?”我花了很長一段時(shí)間才明白，要理解設(shè)計(jì)模式，必須要明白三個(gè)字：“不得已”。是迫不得已，才用設(shè)計(jì)模式來解決一些特定的問題，而不是說正常的代碼就應(yīng)該這樣寫!這種迫不得已，有很多種原因。個(gè)人覺得最容易理解的就是“適配器模式”，因?yàn)槌霈F(xiàn)了接口的沖突，所以我們不得不進(jìn)行適配。但一個(gè)很自然的問題就是：為什么不直接改接口讓他們自然融洽呢?這不是一種更自然更直觀的解決方案嗎?答案很有可能就是因?yàn)榧軜?gòu)——大的架構(gòu)已經(jīng)確立，局部必須服從整體。那么，如果一個(gè)完全理想化的架構(gòu)，是不是根本就不應(yīng)該出現(xiàn)這種問題接口沖突的問題，因而根本就不需要這種設(shè)計(jì)模式?

所以，我說設(shè)計(jì)模式之類的東西是潤滑劑是黏合劑，他們的作用是彌補(bǔ)架構(gòu)的局部缺陷，更好的支撐架構(gòu)。更極端的一種說法可以送給癡迷于設(shè)計(jì)模式的同學(xué)：設(shè)計(jì)模式是藥，沒病就不要吃藥!

那么，為了可維護(hù)性，架構(gòu)中究竟應(yīng)該注意些什么?這是一個(gè)很大的話題，開篇我們只說一點(diǎn)。

模塊劃分

模塊有大有小，大可以是一個(gè)分層一個(gè)項(xiàng)目，小可以是一個(gè)方法一個(gè)類。我們通常的做法是由大到小，逐步細(xì)分。

模塊的劃分是相當(dāng)?shù)目简?yàn)架構(gòu)能力的。良好的模塊劃分，能夠讓我們方便的安排人手、合理的組織項(xiàng)目進(jìn)度、迅速的定位代碼……各種好處說都說不完。所以還是說說不好的模塊劃分有什么問題更容易一些，嗯，這個(gè)好像根本就不要說，想想你在一堆亂七八糟的代碼里不斷的F11的情形吧!

我個(gè)人認(rèn)為，模塊劃分的難度在于“整齊”和“靈活”之間取舍。通常來說，大的模塊我們都是“一刀切”，著重強(qiáng)調(diào)的是“整齊”，比如口熟能詳?shù)腢I層、BLL層和DAL層，但這種“一刀切”的做法，更多的是一種無奈。我們的人類的思維局限決定了我們在考慮復(fù)雜問題時(shí)無法深入到每一個(gè)細(xì)節(jié)，所以只能先“大而化之”的把一個(gè)復(fù)雜問題先進(jìn)行簡單化。這樣帶來的一個(gè)嚴(yán)重的副作用就是，限制了代碼的靈活性;而靈活性，正是應(yīng)對復(fù)雜變化的有效武器。所以，在更小一些的模塊(比如說：類)里，我們引入了豐富多彩的抽象繼承設(shè)計(jì)模式等一系列充滿各種靈活性的機(jī)制，以彌合“一刀切”造成的問題。這一松一緊一張一弛中“度”的掌握，就只能說是一種藝術(shù)了。

模塊劃分，籠統(tǒng)的說教用處不大，我們將在后面的文章中結(jié)合具體情況逐一說明。但我希望大家能夠明白：模塊劃分是必須的——這種必須，是一種無可奈何的選擇。所以，喜歡從頁面直接寫sql到數(shù)據(jù)庫的同學(xué)，老大讓你把你的代碼拆成幾段放到不同地方的時(shí)候，不要嫌麻煩;喜歡把一個(gè)簡單項(xiàng)目切成七層的同學(xué)，先仔細(xì)想不想這樣做是不是真的有必要。

代碼之外

為了代碼能夠長期有效的維護(hù)，我們還需要做很多工作，比如良好的文檔、完善的項(xiàng)目管理流程。但我想說的，還是不是這個(gè)，而是代碼之外的因素對項(xiàng)目架構(gòu)的影響。比如開發(fā)團(tuán)隊(duì)的背景能力偏好，一群C#程序員，你一定要整個(gè)node.js，這純粹是給自己找不痛快。除了這些稍稍用腦袋想一想就能明白的東西，有一件事，很多程序員并沒有意識到。

架構(gòu)的一個(gè)天然目的就是：讓代碼更智能讓程序員更傻瓜。換一張說法就是，架構(gòu)要“創(chuàng)造便利，讓程序員更關(guān)注業(yè)務(wù)”。

這可能是一個(gè)讓程序員感到悲哀的事實(shí)。正如機(jī)械師不停的發(fā)明，讓機(jī)器變得越來越聰明，取代流水線上的工人，最終取代了他們自己。從某種意義上說，我們都是自掘墳?zāi)沟娜恕Ｒ粋€(gè)良好的架構(gòu)，就應(yīng)該是讓每一個(gè)普通開發(fā)人員，都是一個(gè)個(gè)盡量廉價(jià)隨時(shí)可以替換的螺絲釘，這樣才能保證系統(tǒng)永遠(yuǎn)健康正常的運(yùn)行下去。告訴你這個(gè)事實(shí)可能讓你一整天都不開心，但接受這個(gè)事實(shí)之后能幫助你在工作中變得更加的“心平氣和”。螺絲釘就要有螺絲釘?shù)挠X悟;更何況，當(dāng)好一顆螺絲釘也不是一件很容易的事。