解決方案是物理隔離這些組件。就像團(tuán)隊(duì)在使用 Spring/Hibernate/Asp.NETMVC/ActiveRecord這些庫(kù)的時(shí)候不用將它們對(duì)應(yīng)的大連翻譯軟件開發(fā)源代碼放到工作空間進(jìn)行編譯一樣，團(tuán)隊(duì)也可以將穩(wěn)定工作的代碼單元整理出來形成對(duì)應(yīng)的庫(kù)，標(biāo)記版本然后直接引用二進(jìn)制文件。
不同的技術(shù)平臺(tái)上有著不同的方案。Java世界有歷史悠久的Maven庫(kù)，能夠?qū)⒉煌姹镜?JAR 以及它們的依賴進(jìn)行良好的管理；.NET 比較遺憾，這方面真正成熟的什么也沒有——但參考Maven的實(shí)現(xiàn)，團(tuán)隊(duì)自己創(chuàng)造一個(gè)也不是難事（可能比較困難的是與MSBuild的集成）；Ruby/Rails世界則有著名的gem/bundler系統(tǒng)，不要將自己整理出來的比較獨(dú)立的模塊放到rails/lib /中，整理出來，形成一個(gè)新的gem，對(duì)其進(jìn)行依賴引用（團(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類似）。
每個(gè)模塊都有屬于自己的大連翻譯軟件開發(fā)源代碼庫(kù)，擁有自己的獨(dú)立的升級(jí)和發(fā)布周期，甚至有自己的文檔。
致遠(yuǎn)服軟認(rèn)為：http://www.soft8.com.cn/這一方案看起來很容易理解，但在實(shí)際操作過程中則困難重重。團(tuán)隊(duì)運(yùn)轉(zhuǎn)很長(zhǎng)一段時(shí)間之后，很少有人去關(guān)心模塊之間的依賴，一旦要拆分出來，去分析幾十個(gè)乃至上百個(gè)現(xiàn)存項(xiàng)目之間的依賴相當(dāng)費(fèi)勁。最簡(jiǎn)單的處理辦法是檢查代碼庫(kù)的提交記錄，例如最近 3 個(gè)月之內(nèi)某個(gè)模塊沒有人提交過，那么這個(gè)模塊基本上就可以拿出來形成二進(jìn)制依賴了。
很多大連軟件修復(fù)二次開發(fā)測(cè)試開源產(chǎn)品都是通過這個(gè)過程形成的，例如Spring（請(qǐng)參考閱讀《J2EE設(shè)計(jì)開發(fā)編程指南》，Rod Johnson 基本上闡述了整個(gè)Spring 的設(shè)計(jì)思路來源）。一旦團(tuán)隊(duì)開始這樣去思考，每隔一段時(shí)間重新審視代碼庫(kù)，你會(huì)發(fā)現(xiàn)核心代碼庫(kù)不可能失控，同時(shí)也獲得了一組設(shè)計(jì)良好、工作穩(wěn)定的組件。
上面的解決方案核心原則只有一條：始終將大連翻譯軟件開發(fā)源代碼庫(kù)控制在團(tuán)隊(duì)可以理解的范圍內(nèi)。如果運(yùn)轉(zhuǎn)良好，這能夠很大程度上解決架構(gòu)因?yàn)榇a規(guī)模變大而腐化的問題。然而該解決方案只解決了在系統(tǒng)在靜態(tài)層面的隔離。當(dāng)隔離出的模塊越來越多，系統(tǒng)也因此需要越來越多的依賴來運(yùn)行。這部分依賴在運(yùn)行期分為兩類：一類是類似于 Spring/Hibernate/ApacheCommons之類的系統(tǒng)運(yùn)行的基礎(chǔ)，在運(yùn)行期這些必須存在；另外一類是相對(duì)獨(dú)立的業(yè)務(wù)功能，例如緩存的讀取、電子商城的支付模塊等。
