在長期運轉的項目中，架構的腐化是怎么產生的？為什么常見的面向對象技術無法解決這類問題？如何延緩架構的腐化？

　　本文將嘗試解釋這一切，并提出相應的解決方案。讀者需要具備相當的開發(fā)經驗——至少在同一個項目的開發(fā)上一年以上；公司負責架構演進、產品演進的角色會從本文找到靈感。

　　網站架構

　　架構這個詞在各種場合不斷地以各種面目表現出來。從維基百科的詞條看來，我們經常聽到的有插件架構（Plugin），以數據庫為中心的架構（Database Centric），模型-視圖-控制器架構（MVC），面向服務的架構（SOA），三層模型(Three-Tier model)，模型驅動架構（MDA）等等等等。奇妙的是，這些詞越大，實際的開發(fā)者就越痛苦。SOA很好——但在它提出的那個年代，帶給開發(fā)者的只是面向廠商虛無縹緲的“公共數據類型”；MDA甚至都沒有機會淪為新一輪令人笑話的CASE工具。

　　在繼續(xù)閱讀之前，讀者不妨問自己一個問題：在長期的項目中，這些大詞是否真的切實給你帶來過好處？更為功利的問題是：你，作為戰(zhàn)斗在一線的開發(fā)者，在長期項目中可曾有過美好的體驗？

　　網站建設程序開發(fā)技術的演變與揮之不去的痛

　　企業(yè)應用的發(fā)展似乎從十年前開始騰飛。從Microsoft ASP/LAMP(Linux、Apache、MySQL、PHP)年代開始，各種企業(yè)應用紛紛向瀏覽器遷移。經過十年的發(fā)展，目前陣營已經百花齊放。與過去不同，現在的技術不僅僅在編程語言方面，常見的編程套路、最佳實踐、方法學、社區(qū)，都是各種技術獨特擁有的。目前占據主流的陣營有：

·        Rails

·        Java EE平臺。值得一提的是Java VM已經成為一種新的宿主平臺，Scala、JRuby更為活躍并引人矚目

·        LAMP平臺。Linux/MySQL/Apache并沒有多少變化，PHP社區(qū)從Rails社區(qū)獲得了不少養(yǎng)分，出現了許多更加優(yōu)秀的開發(fā)框架

·        Microsoft .NET平臺

·        Django

　　沒有理由對這些新技術不感到振奮。它們解決了許多它們出現之前的問題。在它們的網站上都宣稱各種生產效率如何之高的廣告語，類似于15分鐘創(chuàng)建一個博客應用；2分鐘快速教程等等。比起過去21天才能學會XXX，現在它們在上手難度上早已大幅度降低。

　　需要潑冷水的是，本文開篇提出的問題，在上述任何一種技術下，都如幽靈般揮之不去。采用Ruby on Rails的某高效團隊在10人團隊工作半年之后，構建時間從當初的2分鐘變成2小時；我們之前采用Microsoft .NET 3.5 (C# 3.0)的一個項目，在產生2萬行代碼的時候，構建時間已經超過半小時；我們的一些客戶，工作在10年的Java代碼庫上——他們竭盡全力，保持技術棧與時俱進：Spring、Hibernate、Struts等，面對的困境是他們需要同時打開72個項目才能在Eclipse中獲得編譯；由于編譯打包時間過長，他們去掉了大部分的單元測試——帶來巨大的質量風險。

　　如果你真的在一個長期的項目工作過，你應該清楚地了解到，這種痛苦，似乎不是任何一種框架能夠根本性解決的。這些新時代的框架解決了大部分顯而易見的問題，然而在一個長期項目中所面對的問題，它們無能為力。

　　一步一步：網站建設架構是如何腐化的

　　無論架構師在任何時代以何種絢麗的方式描述架構，開發(fā)中的項目不會超出下圖所示：

　　基本架構示意

　　一些基本的準則：

·        為了降低耦合，系統(tǒng)應當以恰當的方式進行分層。目前最經考驗的分層是MVC+Service。

·        為了提供基礎的訪問，一些基本的、平臺級別的API應該被引入。用Spring之類的框架來做這件事情。

·        用AOP進行橫向切分業(yè)務層面共性的操作，例如日志、權限等。

·        為了保證項目正常構建，你還需要數據庫、持續(xù)集成服務器，以及對應的與環(huán)境無關的構建腳本和數據庫遷移腳本。

　　做網站階段1

　　滿足這個條件的架構在初期是非常令人愉悅的。上一部分我們描述的框架都符合這種架構。這個階段開發(fā)非常快：IDE打開很快，開發(fā)功能完成很快，團隊這個時候往往規(guī)模較小，交流也沒有問題。所有人都很高興——因為用了新技術，因為這個架構是如此的簡單、清晰、有效。

　　做網站階段2

　　好日子不算太長。

　　很快你的老板（或者客戶，隨便什么）有一攬子的想法要在這個團隊實現。工作有條不紊的展開。更多的功能加入進來，更多的團隊成員也加入了進來。新加入的功能也按照之前的架構方式開發(fā)著；新加入的團隊成員也對清晰的架構表示欣喜，也一絲不茍的遵循著。用不了多久——也許是三個月，或者更短，你會發(fā)現代碼庫變成下面的樣子：

　　正常開發(fā)之后

　　你也許很快會意識到這其中有什么問題。但你很難意識到這到底意味著什么。常見的動作往往圍繞著重構——將縱向相關的抽取出來，形成一個新的項目；橫向相關的抽取出來，形成一個名叫common或者base的項目。

　　無論你做什么類型的重構，一些變化在悄悄產生（也許只是快慢的不同）。構建過程不可避免的變長。從剛開始的一兩分鐘變成好幾分鐘，到十幾分鐘。通過重構構建腳本，去掉那些不需要的部分，構建時間會降到幾分鐘，你滿意了，于是繼續(xù)。

　　做網站階段3

　　更多的功能、更多的成員加入了。構建時間又變長了。隨著加載代碼的增多，IDE也慢了下來；交流也多了起來——不是所有人能夠了解所有代碼了。在某些時候，一個很有道德的程序員嘗試重構一部分重復邏輯，發(fā)現牽涉的代碼太多了，好多都是他看不懂的業(yè)務，于是他放棄了。更多的人這么做了，代碼庫越來越臃腫，最終沒有一個人能夠搞清楚系統(tǒng)具體是怎么工作的了。

　　系統(tǒng)在混亂的狀態(tài)下繼續(xù)緩慢地混亂——這個過程遠比本文寫作的時間要長很多，之間會有反復，但據我觀察，在不超過1年的時間內，無論采用何種技術框架，應用何種架構，這個過程似乎是不可抗拒的宿命。

　　網站建設常見的解決方案

　　我們并非是坐以待斃的。身邊優(yōu)秀的同事們在問題發(fā)現之前采取了各種解決方案。常見的解決方案如下：

　　網站建設升級工作環(huán)境

　　沒有什么比一臺與時俱進的電腦更能激勵開發(fā)人員了。最多每隔三年，升級一次開發(fā)人員的電腦——升級到當時最好的配置，能夠大幅度的提升生產效率，激勵開發(fā)人員。反過來，利用過時的電腦，在慢速的機器上進行開發(fā)，帶來的不僅僅是客觀上開發(fā)效率的降低，更大程度上帶來的是開發(fā)人員心理上的懈怠。

　　升級的工作環(huán)境不僅僅是電腦，還包括工作的空間。良好的，促進溝通的空間（以及工作方式）能夠促進問題的發(fā)現從而減少問題的產生。隔斷不適合開發(fā)。

　　APP建設開發(fā)分階段的構建

　　一般而言，構建的順序是：本地構建確保所有的功能運行正常，然后提交等待持續(xù)集成工作正常。本地構建超過5分鐘的時候就變得難以忍受；大多數情況下你希望這個反饋時間越短越好。項目的初期往往會運行所有的步驟：編譯所有代碼，運行所有測試。隨著項目周期的變長，代碼的增多，時間會越來越長。在嘗試若干次重構構建腳本再也沒辦法優(yōu)化之后，“分階段構建”成為絕大多數的選擇。通過合理的拆分、分層，每次運行特定的步驟，例如只運行特定的測試、只構建必要的部分；然后提交，讓持續(xù)集成服務器運行所有的步驟。這樣開發(fā)者能夠繼續(xù)進行后續(xù)的工作。

　　分布式構建

　　即便本地快了起來，采用分階段構建的團隊很快發(fā)現，CI服務器的構建時間也越來越讓人不滿意。每次提交半小時之后才能得到構建結果太不可接受了。各種各樣的分布式技術被創(chuàng)建出來。除了常見的CI服務器本身提供的能力，許多團隊也發(fā)明了自己的分布式技術，他們往往能夠將代碼分布到多臺機器進行編譯和運行測試。這種解決方案能夠在比較長的一段時間內生效——當構建變慢的時候，只需要調整分布策略，讓構建過程運行在更多的集群機器上，就可以顯著的減少構建時間。

　　網站建設APP開發(fā)采用JRebel或者Spork

　　一些新的工具能夠顯著地提速開發(fā)人員的工作。JRebel能夠將需要編譯的Java語言變成修改、保存立即生效，減少了大量的修改、保存、重新編譯、部署的時間；Spork能夠啟動一個Server，將RSpec測試相關的代碼緩存于其中，這樣在運行RSpec測試的時候就不用重新進行加載，極大提升了效率。

　　到底是什么問題？

　　上述的解決方案在特定的時間域內很好地解決了一部分問題。然而，在項目運轉一年，兩年或者更久，它們最終依然無法避免構建時間變長、開發(fā)變慢、代碼變得混亂、架構晦澀難懂、新人難以上手等問題。到底問題的癥結是什么？

　　人們喜歡簡潔。但這更多的看起來是一個謊言——沒有多少團隊能夠自始至終保持簡潔。人們喜歡簡潔只是因為這個難以做到。并不是說人們不愿意如此。很多人都知道軟件開發(fā)不比其他的勞動力密集型的行業(yè)——人越多，產量越大?！度嗽律裨挕分幸呀浱岬剑椖吭黾痈嗟娜?，在提升工作產出的同時，也產生了混亂。短期內，這些混亂能夠被團隊通過各種形式消化；但從長期看來，隨著團隊人員的變動（新人加入，老人離開），以及人正常自然的遺忘曲線，代碼庫會逐漸失控，混亂無法被消化，而項目并不會停止，新功能不斷的加入，架構就在一天天的過程中被腐蝕。

　　人的理解總有一個邊界，而需求和功能不會——今天的功能總比昨天的多；這個版本的功能總比上個版本的多。而在長時間的開發(fā)中，忘記之前的代碼是正常的；忘記某些約定也是正常的。形成某些小而不經意的錯誤是正常的，在巨大的代碼庫中，這些小錯誤被忽視也是正常的。這些不斷積攢的小小的不一致、錯誤，隨著時間的積累，最終變得難以控制。

　　很少有人注意到，規(guī)模的變大才是導致架構腐化的根源——因果關系在時空上的不連續(xù)，使得人們并不能從其中獲得經驗，只是一再重復這個悲劇的循環(huán)。

　　網站設計制作解決方案

　　解決方案的終極目標是：在混亂發(fā)生之前，在我們的認知出現障礙之前，就將項目的規(guī)?？刂圃谝欢ǚ秶畠?。這并不容易。大多數團隊都有相當的交付壓力。大多數的業(yè)務用戶并沒有意識到，往一個項目/產品毫無節(jié)制地增加需求只會導致產品的崩潰?？纯?/span>Lotus Notes，你就知道產品最終會多么令人費解、難以使用。我們這里主要討論的是技術方案。業(yè)務上你也需要始終對需求的增長保持警惕。

　　0. 網站建設APP開發(fā)采用新技術

　　這可能是最廉價的、最容易采用的方案。新技術的產生往往為了解決某些特定的問題，它們往往是經驗的集合。學習，理解這些新技術能夠極大程度減少過去為了完成某些技術目標而進行的必要的經驗積累過程。就像武俠小說中經常有離奇遭遇的主人公突然獲得某個世外高人多年的內力一樣，這些新技術能夠迅速幫助團隊從某些特定的痛點中解脫出來。

　　已經有足夠多的例子來證明這一觀點。在Spring出現之前，開發(fā)者的基本上只能遵循J2EE模式文檔中的各種實踐，來構建自己的系統(tǒng)。有一些簡單的框架能夠幫助這一過程，但總體來說，在處理今天看起來很基礎的如數據庫連接，異常管理，系統(tǒng)分層等等方面，還有很多手工的工作要做。Spring出現之后，你不需要花費很多精力，很快就能得到一個系統(tǒng)分層良好、大部分設施已經準備就緒的基礎。這為減少代碼庫容量以及解決可能出現的低級Bug提供了幫助。

　　Rails則是另外一個極端的例子。Rails帶來的不僅僅是開發(fā)的便利，還帶來了人們在Linux世界多年的部署經驗。數據庫Migration， Apache + FastCGI或者nginx+passenger，這些過去看起來復雜異常的技術在Rails中變得無足輕重——稍懂命令行的人即可進行部署。

　　任何一個組織都無法全部擁有這些新技術。因此作為軟件從業(yè)者，需要不斷地保持對技術社區(qū)的關注。閉門造車只能加速架構的腐化——特別是這些自己的發(fā)明在開源社區(qū)早已有成熟的方案的時候。在那些貌似光鮮的產品背后，實際上有著無數的失敗的案例成功的經驗在支撐。

　　我們曾經有一個項目。在意識到需求可能轉向類似于key-value的文檔數據庫之后，團隊大膽的嘗試采用SQL Server 2008的XML能力，在SQL Server內部實現了類似于No-SQL的數據庫。這是一個新的發(fā)明，創(chuàng)造者初期很興奮，終于有機會做不同的事情了。然而隨著項目的進行，越來越多的需求出現了：Migration的支持、監(jiān)控、管理工具的支持、文檔、性能等等。隨著項目的進展，最終發(fā)現這些能力與時下流行的MongoDB是如此的相似 ——MongoDB已經解決了大多數的問題。這個時候，代碼庫已經有相當的規(guī)模了——而這部分的代碼，讓許多團隊成員費解；在一年之后，大約只有2個人能夠了解其實現過程。如果在早期采用MongoDB，團隊本有機會摒棄大部分相關的工作。

　　值得一提的是，高傲的開發(fā)者往往對新技術不夠耐心；或者說對新技術的能力或局限缺乏足夠耐心去了解。每一個產品都有其針對的問題域，對于問題域之外，新技術往往沒有成熟到能夠應對的地步。開發(fā)者需要不斷地閱讀、思考、參與，來驗證自己的問題域是否與其匹配。淺嘗輒止不是好的態(tài)度，也阻礙了新技術在團隊內的推廣。

　　新技術的選型往往發(fā)生在項目/產品特定的時期，如開始階段，某個特定的痛點時期。日常階段，開發(fā)者仍然需要保持對代碼庫的關注。下一條，重構到物理隔離的組件則是對不斷增大的代碼庫另一種解決方案。

　　1. 網站建設APP開發(fā)重構到物理隔離的組件

　　顯而易見的趨勢是，對于同一個產品而言，需求總是不斷增多的。去年有100個功能，今年就有200個。去年有10萬行代碼，今年也許就有20萬行。去年2G 內存的機器能夠正常開發(fā)，今年似乎得加倍才行。去年有15個開發(fā)人員，今年就到30個了。去年構建一次最多15–20分鐘，今年就得1個小時了，還得整個分布式的。

　　有人會注意到代碼的設計問題，孜孜不倦地進行著重構；有人會注意到構建變慢的問題，不懈地改進著構建時間。然而很少有人注意到代碼庫的變大才是問題的根源。很多常規(guī)的策略往往是針對組織的：例如將代碼庫按照功能模塊劃分（例如ABC功能之類）或者按層次劃分（例如持久層、表現層），但這些拆分之后的項目依然存在于開發(fā)人員的工作空間中。無論項目如何組織，開發(fā)者都需要打開所有的項目才能完成編譯和運行過程。我曾經見到一個團隊需要在Visual Studio中打開120個項目；我自己也經歷過需要在Eclipse中打開72個項目才能完成編譯。

　　解決方案是物理隔離這些組件。就像團隊在使用Spring/Hibernate/Asp.NET MVC/ActiveRecord這些庫的時候，不用將它們對應的源代碼放到工作空間進行編譯一樣，團隊也可以將穩(wěn)定工作的代碼單元整理出來形成對應的庫，標記版本然后直接引用二進制文件。

　　在不同的技術平臺上有著不同的方案。Java世界有歷史悠久的Maven庫，能夠良好的將不同版本的JAR以及他們的以來進行管理；.NET比較遺憾，這方面真正成熟的什么也沒有——但參考Maven的實現，團隊自己造一個也不是難事（可能比較困難的是與MSBuild的集成）；Ruby/Rails世界則有著名的gem/bundler系統(tǒng)。將自己整理出來的比較獨立的模塊不要放到rails/lib/中，整理出來，形成一個新的gem，對其進行依賴引用（團隊內需要搭建自己的gems庫）。

　　同時，代碼庫也需要進行大刀闊斧的整改。之前的代碼結構可能如下，（這里以SVN為例，因為SVN有明確的trunk/branches/tags目錄結構。git/hg類似）

　　原來的庫結構

　　網站建設框架改進之后，將會如下圖所示：

　　改進的庫結構

　　每個模塊都有屬于自己的代碼庫，擁有自己的獨立的升級和發(fā)布周期，甚至有自己的文檔。

　　這一方案看起來很容易理解，但在實際操作過程中則困難重重。團隊運轉很長一段時間之后，很少有人去關心模塊之間的依賴。一旦要拆分出來，去分析幾十上百個現存項目之間的依賴相當費勁。最簡單的處理辦法是，檢查代碼庫的提交記錄，例如最近3個月之內某個模塊就沒有人提交過，那么這個模塊基本上就可以拿出來形成二進制依賴了。

　　很多開源產品都是通過這個過程形成的，例如Spring（請參考閱讀《J2EE設計開發(fā)編程指南》，Rod Johnson基本上闡述了整個Spring的設計思路來源）。一旦團隊開始這樣去思考，每隔一段時間重新審視代碼庫，你會發(fā)現核心代碼庫不可能失控，同時也獲得了一組設計良好、工作穩(wěn)定的組件。

　　2. 網站建設將獨立的模塊放入獨立的進程

　　上面的解決方案核心原則只有一條：始終將核心代碼庫控制在團隊可以理解的范圍內。如果運轉良好，能夠很大程度上解決架構因為代碼規(guī)模變大而腐化的問題。然而該解決方案只解決了在系統(tǒng)在靜態(tài)層面的隔離。當隔離出的模塊越來越多，系統(tǒng)也因此也需要越來越多的依賴來運行。這部分依賴在運行期分為兩類：一類是類似于Spring/Hibernate/Apache Commons之類的，系統(tǒng)運行的基礎，運行期這些必須存在；另外一類是相對獨立的業(yè)務功能，例如緩存的讀取，電子商城的支付模塊等。

　　第二類依賴則可以更進一步：將其放到獨立的進程中?，F在稍具規(guī)模的系統(tǒng)，登錄、注銷功能已經從應用中脫離而出，要么采用SSO的方案來進行登陸，要么則干脆代理給別的登陸系統(tǒng)。LiveJournal團隊在開發(fā)過程中，發(fā)現緩存的讀寫實際上可以放到獨立的進程中進行（而不是類似EhCache的方案，直接運行于所在的運行環(huán)境中），于是發(fā)明了現在鼎鼎有名的memcached。我們之前進行的一個項目中，發(fā)現支付模塊完全能夠獨立出來，于是將其進行隔離，形成了一個新的、沒有界面的、永遠在運行的系統(tǒng)，通過REST處理支付請求。在另外一個出版項目中，我們發(fā)現編輯編寫報告的過程實際上與報告發(fā)行過程雖然存在類級別的重用，但在業(yè)務層面是獨立的。最終我們將報告發(fā)行過程做成了一個常駐服務，系統(tǒng)其他的模塊通過MQ消息與其進行交互。

　　這一解決方案應該不難理解。與解決方案1不同的是，這一方案更多的是要對系統(tǒng)進行面向業(yè)務層面的思考。由于系統(tǒng)將會以獨立的進程來運行這一模塊，在不同的進程中可能存在一定的代碼重復，例如Spring同時存在兩個不相關的項目中大家覺得沒什么大不了的；但如果是自己的某個業(yè)務組件同時在同一個項目的兩個進程中重復，許多人就有些潔癖不可接受了。（題外話：這種潔癖在OSGi環(huán)境中也存在）這里需要提醒的是：當處于不同的進程時，它們在物理上、運行時上已經徹底隔離了。必須以進程的觀點去思考整個架構，而不是簡單的物理結構。

　　從單進程模型到多進程模型的架構思維轉變也不太容易——需要架構師有意識的加強這方面的練習。流行的.NET和Java世界傾向于把什么都放到一起。而Linux世界Rails/Django則能更好的平衡優(yōu)秀產品之間的進程協(xié)調。例如memcached的使用。另外，現在多核環(huán)境越來越多，與其費盡心思在編程語言層面上不如享受多核的好處，多進程能夠簡單并且顯著地利用多核能力。

　　3. 網站制作編寫時形成高度松散耦合的平臺+應用

　　現在將眼光看更遠一些。想象一下我們在做一個類似于開心網、Facebook、人人網的系統(tǒng)。它們的共同特點是能夠接入幾乎無限的第三方應用，無論是買賣朋友這類簡單的應用，還是絢麗無比的各種社交游戲。神奇的是，實現這一點并不需要第三方應用的開發(fā)者采用跟它們一樣的技術平臺，也不需要服務端提供無限的運算能力——大部分的架構由開發(fā)方來控制。

　　在企業(yè)應用中實現這個并不難。這其中的秘訣在于：當用戶通過Facebook訪問某個第三方應用的時候，Facebook實際上通過后臺去訪問了第三方應用，將當前用戶的信息（以及好友信息）通過HTTP POST送到第三方應用指定的服務網址，然后將應用的HTML結果渲染到當前頁面中。某種意義上說，這種技術本質上是一種服務器端的mashup.

Facebook App架構

　　這種架構的優(yōu)點在于極度的分布式。從外觀上看起來一致的系統(tǒng)，實際由若干個耦合極低、技術架構完全不同的小應用組成。它們不需要被部署在同一臺機器上，可以單獨地開發(fā)、升級、優(yōu)化。一個應用的癱瘓不影響整個系統(tǒng)的運行；每個應用的自行升級對整個系統(tǒng)也完全沒有影響。

　　這并非是終極的解決方案，只在某些特定的條件下有效。當系統(tǒng)規(guī)模上非常龐大，例如由若干個子系統(tǒng)組成；界面基本一致；子系統(tǒng)之間關聯較少。針對這個前提，可以考慮采用這種架構。抽象出極少的、真正有效公用的信息，在系統(tǒng)之間通過HTTP POST。其他的系統(tǒng)完全可以獨立開發(fā)、部署，甚至針對應用訪問的情況進行特定的部署優(yōu)化。如果不這么做，動輒上百萬千萬行的代碼堆在一個系統(tǒng)中，隨著時間的推移，開發(fā)者逐漸對代碼失控，架構的腐化是遲早的事情。

　　例如，銀行的財務系統(tǒng)，包括了十多個個子系統(tǒng)，包括薪資、資產、報表等等模塊，每一部分功能都相對獨立并且復雜。整個系統(tǒng)如果按照這種方式拆分，就能夠實現單點優(yōu)化而無需重新啟動整個應用。針對每個應用，開發(fā)者能夠在更小的代碼內采用自己熟悉的技術方案，從而減少架構腐化的可能。

　　結語

　　沒有糟糕的網站架構，變化使之

　　我訪問過很多團隊。在很多項目開始的時候，他們花很多時間在選擇用何種技術體系，何種架構，乃至何種IDE。就像小孩子選擇自己鐘愛的玩具，我相信無論過程如何，團隊最終都會欣然選擇他們所選擇的，并且堅信他們的選擇沒有錯誤。事實也確實如此。在項目的開始階段很難有真正的架構挑戰(zhàn)。困難的地方在于，隨著時間的增長，人們會忘記；有很多的人加入，他們需要理解舊代碼的同時完成新功能；每一次代碼量的突破，都會引起架構的不適應；這些不適應包括：新功能引入變得困難，新人難以迅速上手；構建時間變長等等。這些能否引起團隊的警覺，并且采取結構性的解決方案而不是臨時性的。

　　網站建設之關于文檔

　　很多人說敏捷不提倡文檔。他們說文檔很難寫。他們說開發(fā)人員寫不了文檔。于是就沒有文檔。

　　奇怪的是我看到的情況卻不是這樣。程序寫得優(yōu)秀的人，寫起文字來也很不錯。ThoughtBlogs上絕大多數都是程序員，很多人的文字寫得都很贊。

　　而項目中的文檔往往少得可憐。新人來了總是一頭霧水。令人奇怪的是，新人能夠一天或者兩天之內通過閱讀RSpec或者JBehave迅速了解這些工具的使用，到了團隊里面卻沒有了文檔。

　　拋開項目持續(xù)運轉并交付的特性不談，我認為巨大的、不穩(wěn)定的代碼庫是文檔迅速失效的根源。如果我們能夠按照上述的解決方案，將代碼庫縮小，那么獨立出來的模塊或者應用就有機會在更小的范圍內具備更獨特的價值。想象一下現在的Rails3/Spring框架，他們往往有超過20個第三方依賴，我們卻沒有覺得理解困難，最重要的原因是依賴隔離之后，這些模塊有了獨立的文檔可以學習。

　　企業(yè)級項目也可以如此。

　　網站建設創(chuàng)建應用程序的生態(tài)環(huán)境，而非單一的項目

　　功能總是不斷的、不斷的加到同一個產品中。這毫不奇怪。然而通過我們前面的分析，我們應當重新思考這個常識。是創(chuàng)建一個日益龐大的、緩慢的、毫無生機的產品，還是將其有機分解，成為一個生機勃勃的具有不同依賴的生態(tài)系統(tǒng)？項目的各方人員（包括業(yè)務用戶、架構師、開發(fā)者）應當從短視的眼光中走出來，著眼于創(chuàng)建可持續(xù)的應用程序生態(tài)系統(tǒng)。深圳網站建設博納網絡編輯整理。