前言
新技術(shù)層出不窮。過(guò)去十年時(shí)間里，我們經(jīng)歷了許多激動(dòng)人心的新技術(shù)，包括那些新的框架、語(yǔ)言、平臺(tái)、編程模型等等。這些新技術(shù)極大地改善了開(kāi)發(fā)人員的工作環(huán)境，縮短了產(chǎn)品和項(xiàng)目的面世時(shí)間。然而作為在軟件行業(yè)第一線(xiàn)工作多年的從業(yè)者，我們卻不得不面對(duì)一個(gè)現(xiàn)實(shí)，那就是當(dāng)初采用新技術(shù)的樂(lè)趣隨著項(xiàng)目周期的增長(zhǎng)而迅速減少。無(wú)論當(dāng)初的選擇多么光鮮，半年、一年之后，只要這個(gè)項(xiàng)目依然活躍，業(yè)務(wù)在擴(kuò)張 —— 越來(lái)越多的功能需要加入，一些公共的問(wèn)題就會(huì)逐漸顯露出來(lái)。構(gòu)建過(guò)慢，完成新功能讓你痛不欲生，團(tuán)隊(duì)成員無(wú)法很快融入，文檔無(wú)法及時(shí)更新等等。
在長(zhǎng)期運(yùn)轉(zhuǎn)的項(xiàng)目中，架構(gòu)的腐化是怎么產(chǎn)生的？為什么常見(jiàn)的面向?qū)ο蠹夹g(shù)無(wú)法解決這類(lèi)問(wèn)題？如何延緩架構(gòu)的腐化？
本文將嘗試解釋這一切，并提出相應(yīng)的解決方案。讀者需要具備相當(dāng)?shù)拈_(kāi)發(fā)經(jīng)驗(yàn) —— 至少在同一個(gè)項(xiàng)目的開(kāi)發(fā)上一年以上；公司負(fù)責(zé)架構(gòu)演進(jìn)、產(chǎn)品演進(jìn)的角色會(huì)從本文找到靈感。
架構(gòu)
架構(gòu)這個(gè)詞在各種場(chǎng)合不斷地以各種面目表現(xiàn)出來(lái)。從維基百科的詞條看來(lái)，我們經(jīng)常聽(tīng)到的有插件架構(gòu)（Plugin），以數(shù)據(jù)庫(kù)為中心的架構(gòu)（Database Centric），模型-視圖-控制器架構(gòu)（MVC），面向服務(wù)的架構(gòu)（SOA），三層模型(Three-Tier model)，模型驅(qū)動(dòng)架構(gòu)（MDA）等等等等。奇妙的是，這些詞越大，實(shí)際的開(kāi)發(fā)者就越痛苦。SOA很好 —— 但在它提出的那個(gè)年代，帶給開(kāi)發(fā)者的只是面向廠商虛無(wú)縹緲的“公共數(shù)據(jù)類(lèi)型”；MDA甚至都沒(méi)有機(jī)會(huì)淪為新一輪令人笑話(huà)的CASE工具。
在繼續(xù)閱讀之前，讀者不妨問(wèn)自己一個(gè)問(wèn)題：在長(zhǎng)期的項(xiàng)目中，這些大詞是否真的切實(shí)給你帶來(lái)過(guò)好處？更為功利的問(wèn)題是：你，作為戰(zhàn)斗在一線(xiàn)的開(kāi)發(fā)者，在長(zhǎng)期項(xiàng)目中可曾有過(guò)美好的體驗(yàn)？
技術(shù)的演變與揮之不去的痛
企業(yè)應(yīng)用的發(fā)展似乎從十年前開(kāi)始騰飛。從Microsoft ASP/LAMP(Linux、Apache、MySQL、PHP)年代開(kāi)始，各種企業(yè)應(yīng)用紛紛向?yàn)g覽器遷移。經(jīng)過(guò)十年的發(fā)展，目前陣營(yíng)已經(jīng)百花齊放。與過(guò)去不同，現(xiàn)在的技術(shù)不僅僅在編程語(yǔ)言方面，常見(jiàn)的編程套路、最佳實(shí)踐、方法學(xué)、社區(qū)，都是各種技術(shù)獨(dú)特?fù)碛械摹Ｄ壳罢紦?jù)主流的陣營(yíng)有：
- Rails
- Java EE平臺(tái)。值得一提的是Java VM已經(jīng)成為一種新的宿主平臺(tái)，Scala、JRuby更為活躍并引人矚目
- LAMP平臺(tái)。Linux/MySQL/Apache并沒(méi)有多少變化，PHP社區(qū)從Rails社區(qū)獲得了不少養(yǎng)分，出現(xiàn)了許多更加優(yōu)秀的開(kāi)發(fā)框架
- Microsoft .NET平臺(tái)
- Django
沒(méi)有理由對(duì)這些新技術(shù)不感到振奮。它們解決了許多它們出現(xiàn)之前的問(wèn)題。在它們的網(wǎng)站上都宣稱(chēng)各種生產(chǎn)效率如何之高的廣告語(yǔ)，類(lèi)似于15分鐘創(chuàng)建一個(gè)博客應(yīng)用；2分鐘快速教程等等。比起過(guò)去21天才能學(xué)會(huì)XXX，現(xiàn)在它們?cè)谏鲜蛛y度上早已大幅度降低。
需要潑冷水的是，本文開(kāi)篇提出的問(wèn)題，在上述任何一種技術(shù)下，都如幽靈般揮之不去。采用Ruby on Rails的某高效團(tuán)隊(duì)在10人團(tuán)隊(duì)工作半年之后，構(gòu)建時(shí)間從當(dāng)初的2分鐘變成2小時(shí)；我們之前采用Microsoft .NET 3.5 (C# 3.0)的一個(gè)項(xiàng)目，在產(chǎn)生2萬(wàn)行代碼的時(shí)候，構(gòu)建時(shí)間已經(jīng)超過(guò)半小時(shí)；我們的一些客戶(hù)，工作在10年的Java代碼庫(kù)上 —— 他們竭盡全力，保持技術(shù)棧與時(shí)俱進(jìn)：Spring、Hibernate、Struts等，面對(duì)的困境是他們需要同時(shí)打開(kāi)72個(gè)項(xiàng)目才能在Eclipse中獲得編譯；由于編譯打包時(shí)間過(guò)長(zhǎng)，他們?nèi)サ袅舜蟛糠值膯卧獪y(cè)試 —— 帶來(lái)巨大的質(zhì)量風(fēng)險(xiǎn)。
如果你真的在一個(gè)長(zhǎng)期的項(xiàng)目工作過(guò)，你應(yīng)該清楚地了解到，這種痛苦，似乎不是任何一種框架能夠根本性解決的。這些新時(shí)代的框架解決了大部分顯而易見(jiàn)的問(wèn)題，然而在一個(gè)長(zhǎng)期項(xiàng)目中所面對(duì)的問(wèn)題，它們無(wú)能為力。
一步一步：架構(gòu)是如何腐化的
無(wú)論架構(gòu)師在任何時(shí)代以何種絢麗的方式描述架構(gòu)，開(kāi)發(fā)中的項(xiàng)目不會(huì)超出下圖所示：
基本架構(gòu)示意
一些基本的準(zhǔn)則：
- 為了降低耦合，系統(tǒng)應(yīng)當(dāng)以恰當(dāng)?shù)姆绞竭M(jìn)行分層。目前最經(jīng)考驗(yàn)的分層是MVC+Service。
- 為了提供基礎(chǔ)的訪問(wèn)，一些基本的、平臺(tái)級(jí)別的API應(yīng)該被引入。用Spring之類(lèi)的框架來(lái)做這件事情。
- 用AOP進(jìn)行橫向切分業(yè)務(wù)層面共性的操作，例如日志、權(quán)限等。
- 為了保證項(xiàng)目正常構(gòu)建，你還需要數(shù)據(jù)庫(kù)、持續(xù)集成服務(wù)器，以及對(duì)應(yīng)的與環(huán)境無(wú)關(guān)的構(gòu)建腳本和數(shù)據(jù)庫(kù)遷移腳本。
階段1
滿(mǎn)足這個(gè)條件的架構(gòu)在初期是非常令人愉悅的。上一部分我們描述的框架都符合這種架構(gòu)。這個(gè)階段開(kāi)發(fā)非常快：IDE打開(kāi)很快，開(kāi)發(fā)功能完成很快，團(tuán)隊(duì)這個(gè)時(shí)候往往規(guī)模較小，交流也沒(méi)有問(wèn)題。所有人都很高興 ——因?yàn)橛昧诵录夹g(shù)，因?yàn)檫@個(gè)架構(gòu)是如此的簡(jiǎn)單、清晰、有效。
階段2
好日子不算太長(zhǎng)。
很快你的老板（或者客戶(hù)，隨便什么）有一攬子的想法要在這個(gè)團(tuán)隊(duì)實(shí)現(xiàn)。工作有條不紊的展開(kāi)。更多的功能加入進(jìn)來(lái)，更多的團(tuán)隊(duì)成員也加入了進(jìn)來(lái)。新加入的功能也按照之前的架構(gòu)方式開(kāi)發(fā)著；新加入的團(tuán)隊(duì)成員也對(duì)清晰的架構(gòu)表示欣喜，也一絲不茍的遵循著。用不了多久 —— 也許是三個(gè)月，或者更短，你會(huì)發(fā)現(xiàn)代碼庫(kù)變成下面的樣子：
正常開(kāi)發(fā)之后
你也許很快會(huì)意識(shí)到這其中有什么問(wèn)題。但你很難意識(shí)到這到底意味著什么。常見(jiàn)的動(dòng)作往往圍繞著重構(gòu) —— 將縱向相關(guān)的抽取出來(lái)，形成一個(gè)新的項(xiàng)目；橫向相關(guān)的抽取出來(lái)，形成一個(gè)名叫common或者base的項(xiàng)目。
無(wú)論你做什么類(lèi)型的重構(gòu)，一些變化在悄悄產(chǎn)生（也許只是快慢的不同）。構(gòu)建過(guò)程不可避免的變長(zhǎng)。從剛開(kāi)始的一兩分鐘變成好幾分鐘，到十幾分鐘。通過(guò)重構(gòu)構(gòu)建腳本，去掉那些不需要的部分，構(gòu)建時(shí)間會(huì)降到幾分鐘，你滿(mǎn)意了，于是繼續(xù)。
階段3
更多的功能、更多的成員加入了。構(gòu)建時(shí)間又變長(zhǎng)了。隨著加載代碼的增多，IDE也慢了下來(lái)；交流也多了起來(lái) —— 不是所有人能夠了解所有代碼了。在某些時(shí)候，一個(gè)很有道德的程序員嘗試重構(gòu)一部分重復(fù)邏輯，發(fā)現(xiàn)牽涉的代碼太多了，好多都是他看不懂的業(yè)務(wù)，于是他放棄了。更多的人這么做了，代碼庫(kù)越來(lái)越臃腫，最終沒(méi)有一個(gè)人能夠搞清楚系統(tǒng)具體是怎么工作的了。
系統(tǒng)在混亂的狀態(tài)下繼續(xù)緩慢地混亂 —— 這個(gè)過(guò)程遠(yuǎn)比本文寫(xiě)作的時(shí)間要長(zhǎng)很多，之間會(huì)有反復(fù)，但據(jù)我觀察，在不超過(guò)1年的時(shí)間內(nèi)，無(wú)論采用何種技術(shù)框架，應(yīng)用何種架構(gòu)，這個(gè)過(guò)程似乎是不可抗拒的宿命。
常見(jiàn)的解決方案
我們并非是坐以待斃的。身邊優(yōu)秀的同事們?cè)趩?wèn)題發(fā)現(xiàn)之前采取了各種解決方案。常見(jiàn)的解決方案如下：
升級(jí)工作環(huán)境
沒(méi)有什么比一臺(tái)與時(shí)俱進(jìn)的電腦更能激勵(lì)開(kāi)發(fā)人員了。最多每隔三年，升級(jí)一次開(kāi)發(fā)人員的電腦 —— 升級(jí)到當(dāng)時(shí)最好的配置，能夠大幅度的提升生產(chǎn)效率，激勵(lì)開(kāi)發(fā)人員。反過(guò)來(lái)，利用過(guò)時(shí)的電腦，在慢速的機(jī)器上進(jìn)行開(kāi)發(fā)，帶來(lái)的不僅僅是客觀上開(kāi)發(fā)效率的降低，更大程度上帶來(lái)的是開(kāi)發(fā)人員心理上的懈怠。
升級(jí)的工作環(huán)境不僅僅是電腦，還包括工作的空間。良好的，促進(jìn)溝通的空間（以及工作方式）能夠促進(jìn)問(wèn)題的發(fā)現(xiàn)從而減少問(wèn)題的產(chǎn)生。隔斷不適合開(kāi)發(fā)。
分階段的構(gòu)建
一般而言，構(gòu)建的順序是：本地構(gòu)建確保所有的功能運(yùn)行正常，然后提交等待持續(xù)集成工作正常。本地構(gòu)建超過(guò)5分鐘的時(shí)候就變得難以忍受；大多數(shù)情況下你希望這個(gè)反饋時(shí)間越短越好。項(xiàng)目的初期往往會(huì)運(yùn)行所有的步驟：編譯所有代碼，運(yùn)行所有測(cè)試。隨著項(xiàng)目周期的變長(zhǎng)，代碼的增多，時(shí)間會(huì)越來(lái)越長(zhǎng)。在嘗試若干次重構(gòu)構(gòu)建腳本再也沒(méi)辦法優(yōu)化之后，“分階段構(gòu)建”成為絕大多數(shù)的選擇。通過(guò)合理的拆分、分層，每次運(yùn)行特定的步驟，例如只運(yùn)行特定的測(cè)試、只構(gòu)建必要的部分；然后提交，讓持續(xù)集成服務(wù)器運(yùn)行所有的步驟。這樣開(kāi)發(fā)者能夠繼續(xù)進(jìn)行后續(xù)的工作。
分布式構(gòu)建
即便本地快了起來(lái)，采用分階段構(gòu)建的團(tuán)隊(duì)很快發(fā)現(xiàn)，CI服務(wù)器的構(gòu)建時(shí)間也越來(lái)越讓人不滿(mǎn)意。每次提交半小時(shí)之后才能得到構(gòu)建結(jié)果太不可接受了。各種各樣的分布式技術(shù)被創(chuàng)建出來(lái)。除了常見(jiàn)的CI服務(wù)器本身提供的能力，許多團(tuán)隊(duì)也發(fā)明了自己的分布式技術(shù)，他們往往能夠?qū)⒋a分布到多臺(tái)機(jī)器進(jìn)行編譯和運(yùn)行測(cè)試。這種解決方案能夠在比較長(zhǎng)的一段時(shí)間內(nèi)生效 —— 當(dāng)構(gòu)建變慢的時(shí)候，只需要調(diào)整分布策略，讓構(gòu)建過(guò)程運(yùn)行在更多的集群機(jī)器上，就可以顯著的減少構(gòu)建時(shí)間。
采用JRebel或者Spork
一些新的工具能夠顯著地提速開(kāi)發(fā)人員的工作。JRebel能夠?qū)⑿枰幾g的Java語(yǔ)言變成修改、保存立即生效，減少了大量的修改、保存、重新編譯、部署的時(shí)間；Spork能夠啟動(dòng)一個(gè)Server，將RSpec測(cè)試相關(guān)的代碼緩存于其中，這樣在運(yùn)行RSpec測(cè)試的時(shí)候就不用重新進(jìn)行加載，極大提升了效率。
到底是什么問(wèn)題？
上述的解決方案在特定的時(shí)間域內(nèi)很好地解決了一部分問(wèn)題。然而，在項(xiàng)目運(yùn)轉(zhuǎn)一年，兩年或者更久，它們最終依然無(wú)法避免構(gòu)建時(shí)間變長(zhǎng)、開(kāi)發(fā)變慢、代碼變得混亂、架構(gòu)晦澀難懂、新人難以上手等問(wèn)題。到底問(wèn)題的癥結(jié)是什么？
人們喜歡簡(jiǎn)潔。但這更多的看起來(lái)是一個(gè)謊言 —— 沒(méi)有多少團(tuán)隊(duì)能夠自始至終保持簡(jiǎn)潔。人們喜歡簡(jiǎn)潔只是因?yàn)檫@個(gè)難以做到。并不是說(shuō)人們不愿意如此。很多人都知道軟件開(kāi)發(fā)不比其他的勞動(dòng)力密集型的行業(yè) —— 人越多，產(chǎn)量越大。《人月神話(huà)》中已經(jīng)提到，項(xiàng)目增加更多的人，在提升工作產(chǎn)出的同時(shí)，也產(chǎn)生了混亂。短期內(nèi)，這些混亂能夠被團(tuán)隊(duì)通過(guò)各種形式消化；但從長(zhǎng)期看來(lái)，隨著團(tuán)隊(duì)人員的變動(dòng)（新人加入，老人離開(kāi)），以及人正常自然的遺忘曲線(xiàn)，代碼庫(kù)會(huì)逐漸失控，混亂無(wú)法被消化，而項(xiàng)目并不會(huì)停止，新功能不斷的加入，架構(gòu)就在一天天的過(guò)程中被腐蝕。
人的理解總有一個(gè)邊界，而需求和功能不會(huì) —— 今天的功能總比昨天的多；這個(gè)版本的功能總比上個(gè)版本的多。而在長(zhǎng)時(shí)間的開(kāi)發(fā)中，忘記之前的代碼是正常的；忘記某些約定也是正常的。形成某些小而不經(jīng)意的錯(cuò)誤是正常的，在巨大的代碼庫(kù)中，這些小錯(cuò)誤被忽視也是正常的。這些不斷積攢的小小的不一致、錯(cuò)誤，隨著時(shí)間的積累，最終變得難以控制。
很少有人注意到，規(guī)模的變大才是導(dǎo)致架構(gòu)腐化的根源 —— 因果關(guān)系在時(shí)空上的不連續(xù)，使得人們并不能從其中獲得經(jīng)驗(yàn)，只是一再重復(fù)這個(gè)悲劇的循環(huán)。
解決方案
解決方案的終極目標(biāo)是：在混亂發(fā)生之前，在我們的認(rèn)知出現(xiàn)障礙之前，就將項(xiàng)目的規(guī)模控制在一定范圍之內(nèi)。這并不容易。大多數(shù)團(tuán)隊(duì)都有相當(dāng)?shù)慕桓秹毫Α４蠖鄶?shù)的業(yè)務(wù)用戶(hù)并沒(méi)有意識(shí)到，往一個(gè)項(xiàng)目/產(chǎn)品毫無(wú)節(jié)制地增加需求只會(huì)導(dǎo)致產(chǎn)品的崩潰。看看Lotus Notes，你就知道產(chǎn)品最終會(huì)多么令人費(fèi)解、難以使用。我們這里主要討論的是技術(shù)方案。業(yè)務(wù)上你也需要始終對(duì)需求的增長(zhǎng)保持警惕。
0. 采用新技術(shù)
這可能是最廉價(jià)的、最容易采用的方案。新技術(shù)的產(chǎn)生往往為了解決某些特定的問(wèn)題，它們往往是經(jīng)驗(yàn)的集合。學(xué)習(xí)，理解這些新技術(shù)能夠極大程度減少過(guò)去為了完成某些技術(shù)目標(biāo)而進(jìn)行的必要的經(jīng)驗(yàn)積累過(guò)程。就像武俠小說(shuō)中經(jīng)常有離奇遭遇的主人公突然獲得某個(gè)世外高人多年的內(nèi)力一樣，這些新技術(shù)能夠迅速幫助團(tuán)隊(duì)從某些特定的痛點(diǎn)中解脫出來(lái)。
已經(jīng)有足夠多的例子來(lái)證明這一觀點(diǎn)。在Spring出現(xiàn)之前，開(kāi)發(fā)者的基本上只能遵循J2EE模式文檔中的各種實(shí)踐，來(lái)構(gòu)建自己的系統(tǒng)。有一些簡(jiǎn)單的框架能夠幫助這一過(guò)程，但總體來(lái)說(shuō)，在處理今天看起來(lái)很基礎(chǔ)的如數(shù)據(jù)庫(kù)連接，異常管理，系統(tǒng)分層等等方面，還有很多手工的工作要做。Spring出現(xiàn)之后，你不需要花費(fèi)很多精力，很快就能得到一個(gè)系統(tǒng)分層良好、大部分設(shè)施已經(jīng)準(zhǔn)備就緒的基礎(chǔ)。這為減少代碼庫(kù)容量以及解決可能出現(xiàn)的低級(jí)Bug提供了幫助。
Rails則是另外一個(gè)極端的例子。Rails帶來(lái)的不僅僅是開(kāi)發(fā)的便利，還帶來(lái)了人們?cè)贚inux世界多年的部署經(jīng)驗(yàn)。數(shù)據(jù)庫(kù)Migration， Apache + FastCGI或者nginx + passenger，這些過(guò)去看起來(lái)復(fù)雜異常的技術(shù)在Rails中變得無(wú)足輕重 —— 稍懂命令行的人即可進(jìn)行部署。
任何一個(gè)組織都無(wú)法全部擁有這些新技術(shù)。因此作為軟件從業(yè)者，需要不斷地保持對(duì)技術(shù)社區(qū)的關(guān)注。閉門(mén)造車(chē)只能加速架構(gòu)的腐化 —— 特別是這些自己的發(fā)明在開(kāi)源社區(qū)早已有成熟的方案的時(shí)候。在那些貌似光鮮的產(chǎn)品背后，實(shí)際上有著無(wú)數(shù)的失敗的案例成功的經(jīng)驗(yàn)在支撐。
我們?cè)?jīng)有一個(gè)項(xiàng)目。在意識(shí)到需求可能轉(zhuǎn)向類(lèi)似于key-value的文檔數(shù)據(jù)庫(kù)之后，團(tuán)隊(duì)大膽的嘗試采用SQL Server 2008的XML能力，在SQL Server內(nèi)部實(shí)現(xiàn)了類(lèi)似于No-SQL的數(shù)據(jù)庫(kù)。這是一個(gè)新的發(fā)明，創(chuàng)造者初期很興奮，終于有機(jī)會(huì)做不同的事情了。然而隨著項(xiàng)目的進(jìn)行，越來(lái)越多的需求出現(xiàn)了：Migration的支持、監(jiān)控、管理工具的支持、文檔、性能等等。隨著項(xiàng)目的進(jìn)展，最終發(fā)現(xiàn)這些能力與時(shí)下流行的MongoDB是如此的相似 —— MongoDB已經(jīng)解決了大多數(shù)的問(wèn)題。這個(gè)時(shí)候，代碼庫(kù)已經(jīng)有相當(dāng)?shù)囊?guī)模了 —— 而這部分的代碼，讓許多團(tuán)隊(duì)成員費(fèi)解；在一年之后，大約只有2個(gè)人能夠了解其實(shí)現(xiàn)過(guò)程。如果在早期采用MongoDB，團(tuán)隊(duì)本有機(jī)會(huì)摒棄大部分相關(guān)的工作。
值得一提的是，高傲的開(kāi)發(fā)者往往對(duì)新技術(shù)不夠耐心；或者說(shuō)對(duì)新技術(shù)的能力或局限缺乏足夠耐心去了解。每一個(gè)產(chǎn)品都有其針對(duì)的問(wèn)題域，對(duì)于問(wèn)題域之外，新技術(shù)往往沒(méi)有成熟到能夠應(yīng)對(duì)的地步。開(kāi)發(fā)者需要不斷地閱讀、思考、參與，來(lái)驗(yàn)證自己的問(wèn)題域是否與其匹配。淺嘗輒止不是好的態(tài)度，也阻礙了新技術(shù)在團(tuán)隊(duì)內(nèi)的推廣。
新技術(shù)的選型往往發(fā)生在項(xiàng)目/產(chǎn)品特定的時(shí)期，如開(kāi)始階段，某個(gè)特定的痛點(diǎn)時(shí)期。日常階段，開(kāi)發(fā)者仍然需要保持對(duì)代碼庫(kù)的關(guān)注。下一條，重構(gòu)為物理隔離的組件則是對(duì)不斷增大的代碼庫(kù)另一種解決方案。
1. 重構(gòu)為物理隔離的組件
顯而易見(jiàn)的趨勢(shì)是，對(duì)于同一個(gè)產(chǎn)品而言，需求總是不斷增多的。去年有100個(gè)功能，今年就有200個(gè)。去年有10萬(wàn)行代碼，今年也許就有20萬(wàn)行。去年2G 內(nèi)存的機(jī)器能夠正常開(kāi)發(fā)，今年似乎得加倍才行。去年有15個(gè)開(kāi)發(fā)人員，今年就到30個(gè)了。去年構(gòu)建一次最多15–20分鐘，今年就得1個(gè)小時(shí)了，還得整個(gè)分布式的。
有人會(huì)注意到代碼的設(shè)計(jì)問(wèn)題，孜孜不倦地進(jìn)行著重構(gòu)；有人會(huì)注意到構(gòu)建變慢的問(wèn)題，不懈地改進(jìn)著構(gòu)建時(shí)間。然而很少有人注意到代碼庫(kù)的變大才是問(wèn)題的根源。很多常規(guī)的策略往往是針對(duì)組織的：例如將代碼庫(kù)按照功能模塊劃分（例如ABC功能之類(lèi)）或者按層次劃分（例如持久層、表現(xiàn)層），但這些拆分之后的項(xiàng)目依然存在于開(kāi)發(fā)人員的工作空間中。無(wú)論項(xiàng)目如何組織，開(kāi)發(fā)者都需要打開(kāi)所有的項(xiàng)目才能完成編譯和運(yùn)行過(guò)程。我曾經(jīng)見(jiàn)到一個(gè)團(tuán)隊(duì)需要在Visual Studio中打開(kāi)120個(gè)項(xiàng)目；我自己也經(jīng)歷過(guò)需要在Eclipse中打開(kāi)72個(gè)項(xiàng)目才能完成編譯。
解決方案是物理隔離這些組件。就像團(tuán)隊(duì)在使用Spring/Hibernate/Asp.NET MVC/ActiveRecord這些庫(kù)的時(shí)候，不用將它們對(duì)應(yīng)的源代碼放到工作空間進(jìn)行編譯一樣，團(tuán)隊(duì)也可以將穩(wěn)定工作的代碼單元整理出來(lái)形成對(duì)應(yīng)的庫(kù)，標(biāo)記版本然后直接引用二進(jìn)制文件。
在不同的技術(shù)平臺(tái)上有著不同的方案。Java世界有歷史悠久的Maven庫(kù)，能夠良好的將不同版本的JAR以及他們的依賴(lài)進(jìn)行管理；.NET比較遺憾，這方面真正成熟的什么也沒(méi)有（編者注：NuGet值得一試） —— 但參考Maven的實(shí)現(xiàn)，團(tuán)隊(duì)自己造一個(gè)也不是難事（可能比較困難的是與MSBuild的集成）；Ruby/Rails世界則有著名的gem/bundler系統(tǒng)。將自己整理出來(lái)的比較獨(dú)立的模塊不要放到rails/lib /中，整理出來(lái)，形成一個(gè)新的gem，對(duì)其進(jìn)行依賴(lài)引用（團(tuán)隊(duì)內(nèi)需要搭建自己的gems庫(kù)）。
同時(shí)，代碼庫(kù)也需要進(jìn)行大刀闊斧的整改。之前的代碼結(jié)構(gòu)可能如下，（這里以SVN為例，因?yàn)镾VN有明確的trunk/branches/tags目錄結(jié)構(gòu)。git/hg類(lèi)似）
原來(lái)的庫(kù)結(jié)構(gòu)
改進(jìn)之后，將會(huì)如下圖所示：
改進(jìn)的庫(kù)結(jié)構(gòu)
每個(gè)模塊都有屬于自己的代碼庫(kù)，擁有自己的獨(dú)立的升級(jí)和發(fā)布周期，甚至有自己的文檔。
這一方案看起來(lái)很容易理解，但在實(shí)際操作過(guò)程中則困難重重。團(tuán)隊(duì)運(yùn)轉(zhuǎn)很長(zhǎng)一段時(shí)間之后，很少有人去關(guān)心模塊之間的依賴(lài)。一旦要拆分出來(lái)，去分析幾十上百個(gè)現(xiàn)存項(xiàng)目之間的依賴(lài)相當(dāng)費(fèi)勁。最簡(jiǎn)單的處理辦法是，檢查代碼庫(kù)的提交記錄，例如最近3個(gè)月之內(nèi)某個(gè)模塊就沒(méi)有人提交過(guò)，那么這個(gè)模塊基本上就可以拿出來(lái)形成二進(jìn)制依賴(lài)了。
很多開(kāi)源產(chǎn)品都是通過(guò)這個(gè)過(guò)程形成的，例如Spring（請(qǐng)參考閱讀《J2EE設(shè)計(jì)開(kāi)發(fā)編程指南》，Rod Johnson基本上闡述了整個(gè)Spring的設(shè)計(jì)思路來(lái)源）。一旦團(tuán)隊(duì)開(kāi)始這樣去思考，每隔一段時(shí)間重新審視代碼庫(kù)，你會(huì)發(fā)現(xiàn)核心代碼庫(kù)不可能失控，同時(shí)也獲得了一組設(shè)計(jì)良好、工作穩(wěn)定的組件。
2. 將獨(dú)立的模塊放入獨(dú)立的進(jìn)程
上面的解決方案核心原則只有一條：始終將核心代碼庫(kù)控制在團(tuán)隊(duì)可以理解的范圍內(nèi)。如果運(yùn)轉(zhuǎn)良好，能夠很大程度上解決架構(gòu)因?yàn)榇a規(guī)模變大而腐化的問(wèn)題。然而該解決方案只解決了系統(tǒng)在靜態(tài)層面的隔離。當(dāng)隔離出的模塊越來(lái)越多，系統(tǒng)因此也需要越來(lái)越多的依賴(lài)來(lái)運(yùn)行。這部分依賴(lài)在運(yùn)行期分為兩類(lèi)：一類(lèi)是類(lèi)似于Spring/Hibernate/Apache Commons之類(lèi)的，系統(tǒng)運(yùn)行的基礎(chǔ)，運(yùn)行期這些必須存在；另外一類(lèi)是相對(duì)獨(dú)立的業(yè)務(wù)功能，例如緩存的讀取，電子商城的支付模塊等。
第二類(lèi)依賴(lài)則可以更進(jìn)一步：將其放到獨(dú)立的進(jìn)程中。現(xiàn)在稍具規(guī)模的系統(tǒng)，登錄、注銷(xiāo)功能已經(jīng)從應(yīng)用中脫離而出，要么采用SSO的方案來(lái)進(jìn)行登陸，要么則干脆代理給別的登陸系統(tǒng)。LiveJournal團(tuán)隊(duì)在開(kāi)發(fā)過(guò)程中，發(fā)現(xiàn)緩存的讀寫(xiě)實(shí)際上可以放到獨(dú)立的進(jìn)程中進(jìn)行（而不是類(lèi)似EhCache的方案，直接運(yùn)行于所在的運(yùn)行環(huán)境中），于是發(fā)明了現(xiàn)在鼎鼎有名的memcached. 我們之前進(jìn)行的一個(gè)項(xiàng)目中，發(fā)現(xiàn)支付模塊完全能夠獨(dú)立出來(lái)，于是將其進(jìn)行隔離，形成了一個(gè)新的、沒(méi)有界面的、永遠(yuǎn)在運(yùn)行的系統(tǒng)，通過(guò)REST處理支付請(qǐng)求。在另外一個(gè)出版項(xiàng)目中，我們發(fā)現(xiàn)編輯編寫(xiě)報(bào)告的過(guò)程實(shí)際上與報(bào)告發(fā)行過(guò)程雖然存在類(lèi)級(jí)別的重用，但在業(yè)務(wù)層面是獨(dú)立的。最終我們將報(bào)告發(fā)行過(guò)程做成了一個(gè)常駐服務(wù)，系統(tǒng)其他的模塊通過(guò)MQ消息與其進(jìn)行交互。
這一解決方案應(yīng)該不難理解。與解決方案1不同的是，這一方案更多的是要對(duì)系統(tǒng)進(jìn)行面向業(yè)務(wù)層面的思考。由于系統(tǒng)將會(huì)以獨(dú)立的進(jìn)程來(lái)運(yùn)行這一模塊，在不同的進(jìn)程中可能存在一定的代碼重復(fù)。例如Spring同時(shí)存在兩個(gè)不相關(guān)的項(xiàng)目中，大家覺(jué)得沒(méi)什么大不了的；但如果是自己的某個(gè)業(yè)務(wù)組件同時(shí)在同一個(gè)項(xiàng)目的兩個(gè)進(jìn)程中重復(fù)，許多人就有些潔癖不可接受了。（題外話(huà)：這種潔癖在OSGi環(huán)境中也存在）這里需要提醒的是：當(dāng)處于不同的進(jìn)程時(shí)，它們?cè)谖锢砩稀⑦\(yùn)行時(shí)上已經(jīng)徹底隔離了。必須以進(jìn)程的觀點(diǎn)去思考整個(gè)架構(gòu)，而不是簡(jiǎn)單的物理結(jié)構(gòu)。
從單進(jìn)程模型到多進(jìn)程模型的架構(gòu)思維轉(zhuǎn)變也不太容易 —— 需要架構(gòu)師有意識(shí)的加強(qiáng)這方面的練習(xí)。流行的.NET和Java世界傾向于把什么都放到一起。而Linux世界Rails/Django則能更好的平衡優(yōu)秀產(chǎn)品之間的進(jìn)程協(xié)調(diào)。例如memcached的使用。另外，現(xiàn)在多核環(huán)境越來(lái)越多，與其費(fèi)盡心思在編程語(yǔ)言層面上不如享受多核的好處，多進(jìn)程能夠簡(jiǎn)單并且顯著地利用多核能力。
3. 形成高度松散耦合的平臺(tái)+應(yīng)用
現(xiàn)在將眼光看更遠(yuǎn)一些。想象一下我們?cè)谧鲆粋€(gè)類(lèi)似于開(kāi)心網(wǎng)、Facebook、人人網(wǎng)的系統(tǒng)。它們的共同特點(diǎn)是能夠接入幾乎無(wú)限的第三方應(yīng)用，無(wú)論是買(mǎi)賣(mài)朋友這類(lèi)簡(jiǎn)單的應(yīng)用，還是絢麗無(wú)比的各種社交游戲。神奇的是，實(shí)現(xiàn)這一點(diǎn)并不需要第三方應(yīng)用的開(kāi)發(fā)者采用跟它們一樣的技術(shù)平臺(tái)，也不需要服務(wù)端提供無(wú)限的運(yùn)算能力 —— 大部分的架構(gòu)由開(kāi)發(fā)方來(lái)控制。
在企業(yè)應(yīng)用中實(shí)現(xiàn)這個(gè)并不難。這其中的秘訣在于：當(dāng)用戶(hù)通過(guò)Facebook訪問(wèn)某個(gè)第三方應(yīng)用的時(shí)候，F(xiàn)acebook實(shí)際上通過(guò)后臺(tái)去訪問(wèn)了第三方應(yīng)用，將當(dāng)前用戶(hù)的信息（以及好友信息）通過(guò)HTTP POST送到第三方應(yīng)用指定的服務(wù)網(wǎng)址，然后將應(yīng)用的HTML結(jié)果渲染到當(dāng)前頁(yè)面中。某種意義上說(shuō)，這種技術(shù)本質(zhì)上是一種服務(wù)器端的mashup. （詳情參考InfoQ 文章）
Facebook App架構(gòu)
這種架構(gòu)的優(yōu)點(diǎn)在于極度的分布式。從外觀上看起來(lái)一致的系統(tǒng)，實(shí)際由若干個(gè)耦合極低、技術(shù)架構(gòu)完全不同的小應(yīng)用組成。它們不需要被部署在同一臺(tái)機(jī)器上，可以單獨(dú)地開(kāi)發(fā)、升級(jí)、優(yōu)化。一個(gè)應(yīng)用的癱瘓不影響整個(gè)系統(tǒng)的運(yùn)行；每個(gè)應(yīng)用的自行升級(jí)對(duì)整個(gè)系統(tǒng)也完全沒(méi)有影響。
這并非是終極的解決方案，只在某些特定的條件下有效。當(dāng)系統(tǒng)規(guī)模上非常龐大，例如由若干個(gè)子系統(tǒng)組成；界面基本一致；子系統(tǒng)之間關(guān)聯(lián)較少。針對(duì)這個(gè)前提，可以考慮采用這種架構(gòu)。抽象出極少的、真正有效公用的信息，在系統(tǒng)之間通過(guò)HTTP POST. 其他的系統(tǒng)完全可以獨(dú)立開(kāi)發(fā)、部署，甚至針對(duì)應(yīng)用訪問(wèn)的情況進(jìn)行特定的部署優(yōu)化。如果不這么做，動(dòng)輒上百萬(wàn)千萬(wàn)行的代碼堆在一個(gè)系統(tǒng)中，隨著時(shí)間的推移，開(kāi)發(fā)者逐漸對(duì)代碼失控，架構(gòu)的腐化是遲早的事情。
例如，銀行的財(cái)務(wù)系統(tǒng)，包括了十多個(gè)子系統(tǒng)，包括薪資、資產(chǎn)、報(bào)表等等模塊，每一部分功能都相對(duì)獨(dú)立并且復(fù)雜。整個(gè)系統(tǒng)如果按照這種方式拆分，就能夠?qū)崿F(xiàn)單點(diǎn)優(yōu)化而無(wú)需重新啟動(dòng)整個(gè)應(yīng)用。針對(duì)每個(gè)應(yīng)用，開(kāi)發(fā)者能夠在更小的代碼內(nèi)采用自己熟悉的技術(shù)方案，從而減少架構(gòu)腐化的可能。
結(jié)語(yǔ)
沒(méi)有糟糕的架構(gòu)，變化使之
我訪問(wèn)過(guò)很多團(tuán)隊(duì)。在很多項(xiàng)目開(kāi)始的時(shí)候，他們花很多時(shí)間在選擇用何種技術(shù)體系，何種架構(gòu)，乃至何種IDE。就像小孩子選擇自己鐘愛(ài)的玩具，我相信無(wú)論過(guò)程如何，團(tuán)隊(duì)最終都會(huì)欣然選擇他們所選擇的，并且堅(jiān)信他們的選擇沒(méi)有錯(cuò)誤。事實(shí)也確實(shí)如此。在項(xiàng)目的開(kāi)始階段很難有真正的架構(gòu)挑戰(zhàn)。困難的地方在于，隨著時(shí)間的增長(zhǎng)，人們會(huì)忘記；有很多的人加入，他們需要理解舊代碼的同時(shí)完成新功能；每一次代碼量的突破，都會(huì)引起架構(gòu)的不適應(yīng)；這些不適應(yīng)包括：新功能引入變得困難，新人難以迅速上手；構(gòu)建時(shí)間變長(zhǎng)等等。這些能否引起團(tuán)隊(duì)的警覺(jué)，并且采取結(jié)構(gòu)性的解決方案而不是臨時(shí)性的。
關(guān)于文檔
很多人說(shuō)敏捷不提倡文檔。他們說(shuō)文檔很難寫(xiě)。他們說(shuō)開(kāi)發(fā)人員寫(xiě)不了文檔。于是就沒(méi)有文檔。
奇怪的是我看到的情況卻不是這樣。程序?qū)懙脙?yōu)秀的人，寫(xiě)起文字來(lái)也很不錯(cuò)。ThoughtBlogs上絕大多數(shù)都是程序員，很多人的文字寫(xiě)得都很贊。
而項(xiàng)目中的文檔往往少得可憐。新人來(lái)了總是一頭霧水。令人奇怪的是，新人能夠一天或者兩天之內(nèi)通過(guò)閱讀RSpec或者JBehave迅速了解這些工具的使用，到了團(tuán)隊(duì)里面卻沒(méi)有了文檔。
拋開(kāi)項(xiàng)目持續(xù)運(yùn)轉(zhuǎn)并交付的特性不談，我認(rèn)為巨大的、不穩(wěn)定的代碼庫(kù)是文檔迅速失效的根源。如果我們能夠按照上述的解決方案，將代碼庫(kù)縮小，那么獨(dú)立出來(lái)的模塊或者應(yīng)用就有機(jī)會(huì)在更小的范圍內(nèi)具備更獨(dú)特的價(jià)值。想象一下現(xiàn)在的Rails3/Spring框架，他們往往有超過(guò)20個(gè)第三方依賴(lài)，我們卻沒(méi)有覺(jué)得理解困難，最重要的原因是依賴(lài)隔離之后，這些模塊有了獨(dú)立的文檔可以學(xué)習(xí)。
企業(yè)級(jí)項(xiàng)目也可以如此。
創(chuàng)建應(yīng)用程序的生態(tài)環(huán)境，而非單一的項(xiàng)目
功能總是不斷的、不斷的加到同一個(gè)產(chǎn)品中。這毫不奇怪。然而通過(guò)我們前面的分析，我們應(yīng)當(dāng)重新思考這個(gè)常識(shí)。是創(chuàng)建一個(gè)日益龐大的、緩慢的、毫無(wú)生機(jī)的產(chǎn)品，還是將其有機(jī)分解，成為一個(gè)生機(jī)勃勃的具有不同依賴(lài)的生態(tài)系統(tǒng)？項(xiàng)目的各方人員（包括業(yè)務(wù)用戶(hù)、架構(gòu)師、開(kāi)發(fā)者）應(yīng)當(dāng)從短視的眼光中走出來(lái)，著眼于創(chuàng)建可持續(xù)的應(yīng)用程序生態(tài)系統(tǒng)。