如果創(chuàng )建的架構允許你以面向服務(wù)或者面向資源的方式劃分代碼，那么你就有了關(guān)注的靈活性，能夠給這些服務(wù)專(zhuān)門(mén)指派工程師了。當你還是一家小公司時(shí)，這樣做可能意義不大。但是隨著(zhù)你的公司發(fā)展，代碼數量、服務(wù)器數量和系統的整體復雜度都在增長(cháng)。要處理這種復雜度的增長(cháng)，你就需要集中你的工程師。如果不能讓你的員工專(zhuān)注于自己特定的領(lǐng)域，那么就會(huì )造成太多的工程師了解太少的整個(gè)系統的信息，以致效率低下。


 
如果你運營(yíng)的是一個(gè)電子商務(wù)站點(diǎn)，那么你可能有代碼、對象、方法、模塊、服務(wù)器和數據庫，專(zhuān)門(mén)用于登出、搜索、對比、瀏覽、物流、存貨管理等。通過(guò)給這些領(lǐng)域專(zhuān)門(mén)分配團隊，即使這個(gè)領(lǐng)域的代碼庫復雜、有難度而且在不斷擴大，這個(gè)團隊也會(huì )成為該代碼庫的專(zhuān)家。有了這種專(zhuān)業(yè)性，就能更快地開(kāi)發(fā)出新功能，更快地解決已知的或已有的故障和問(wèn)題。由于這些交付的速度加快了，那么修復bug、故障的解決方案以及新開(kāi)發(fā)的功能的上市時(shí)間也就縮短了，此外，開(kāi)發(fā)的隔離以及理想狀況下的系統或服務(wù)的隔離，會(huì )減少單- 系統開(kāi)發(fā)中可能發(fā)生的合并沖突。這里，我們采用的術(shù)語(yǔ)“單一系統開(kāi)發(fā)”，指的是一個(gè)特定產(chǎn)品中的所有函數、對象、過(guò)程和方法共享資源。多個(gè)工程師都簽出同一個(gè)復雜系統的代碼，可能會(huì )在代碼合并時(shí)增加沖突或出錯的可能性。讓專(zhuān)門(mén)的軟件開(kāi)發(fā)團隊負責專(zhuān)門(mén)的代碼，會(huì )減少這種沖突。
 
當然，這并不是說(shuō)代碼復用不應該是組織關(guān)注的重點(diǎn)，它絕對應該是。你應該開(kāi)發(fā)一個(gè)共享的代碼庫，還應該考慮專(zhuān)門(mén)指派一個(gè)團隊負責開(kāi)發(fā)和監管這個(gè)共享代碼庫?？梢杂梅?wù)到服務(wù)、共享的可動(dòng)態(tài)加載的代碼庫或者在編譯產(chǎn)品時(shí)加以編譯或鏈接的代碼庫的形式，來(lái)實(shí)現這些代碼庫。我們常用的方法是采用團隊專(zhuān)用的共享代碼庫，如果一個(gè)負責不共享代碼庫的團隊開(kāi)發(fā)了一個(gè)有用的、能共享的組件，那么應該把這個(gè)組件加人團隊共享的代碼庫。
 
由于工程師總是喜歡不斷面對挑戰，所以你可能擔心工程師不會(huì )愿意在某個(gè)特定領(lǐng)域花費很多時(shí)間。這時(shí)你可以讓工程師輪換地在不同的領(lǐng)域工作，以使他們更好地了解整個(gè)系統，久而久之，這樣做能發(fā)揮他們的才能，幫助他們發(fā)展。此外，這樣做還會(huì )為你培養-位對系統有著(zhù)廣泛認識的未來(lái)架構師，或者會(huì )為你打造一個(gè)快速反應的SWAT團隊，其中的成員可以迅速集結，解決故障和問(wèn)題。
 
故障隔離不僅能縮短 上市時(shí)間，基于同樣的方式和理由它還能降低成本。對此一個(gè)視角是，每個(gè)工程師每小時(shí)或每天的生產(chǎn)力越高，那么你的單位成本就會(huì )下降。例如，在一個(gè)復 雜的單一 系統中，如果要生成普通的故事或用例，通常需要5個(gè)軟件開(kāi)發(fā)人日；而在一個(gè)用泳道分隔的系本就被減少了10%。統中，生成普通的故事或用例，則只需要4.5個(gè)軟件開(kāi)發(fā)人日。這樣軟件開(kāi)發(fā)工作的平均單位成交量?jì)r(jià)值。你可以決定把軟件開(kāi)發(fā)人員減少10%，也可以用較低的成本實(shí)現等量的產(chǎn)品提開(kāi)、單位成本降低了，你可以用它來(lái)做兩件事中的一件，這兩件事都會(huì )影響凈收人， 從而影響此外，你還可以決定保持當前的成本結構不變，而用相同的成本開(kāi)發(fā)出更多的產(chǎn)品。這里的關(guān)鍵是你要選對產(chǎn)品，選擇會(huì )增加你收人的產(chǎn)品。如果你成功了，那么你不僅會(huì )提高凈收人，還會(huì )使你的股東變得更富有。
 
你也許會(huì )認為額外的站點(diǎn)通常會(huì )比-個(gè)站點(diǎn)花 費的資本多，而目運營(yíng)成本也會(huì )增加。雖然事實(shí)的確如此，但大多數公司還是希望自己的產(chǎn)品能經(jīng)受得住地理上相互隔離的種種災難，他們會(huì )投資打造各種級別的災難恢復方案，以便能夠減少這些災難帶來(lái)的影響。假設你具備了正確的故障隔離的架構，運行三個(gè)或四個(gè)故障隔離的數據中心的資本和花費，可能比運行兩個(gè)完全-致的數據中心的成本小得多。
 
證明故障隔離有效性的另一個(gè)視角是看它對收人的影響。你可以計算在某段時(shí)間中失去的機會(huì )(失去的收入)。通?？梢杂?a href="http://havencoinwallet.com">深圳網(wǎng)站建設系統失去的交易量以及未來(lái)比預計要高的客戶(hù)離開(kāi)率來(lái)衡量失去的收人。比較當前損失的收人與將來(lái)?yè)p失的收人，可以決定實(shí)現故障隔離的架構的成本是否合理。根據我們的經(jīng)驗，通過(guò)提高可用性和減少失去的機會(huì )，就可以證明故障隔離的架構是有效的。和bug修復。這種成本的降低會(huì )提高凈收人，但不會(huì )增加收人。