[[142999]]

1. 節(jié)約成本

開(kāi)源基礎(chǔ)架構(gòu)有大量的開(kāi)發(fā)者來(lái)維護(hù)，討論改進(jìn)，反饋。假如軟件的質(zhì)量用人年工作量來(lái)衡量，開(kāi)源的軟件積累了很多開(kāi)發(fā)者的工作，必然比一個(gè)小組獨(dú)立完成的軟件質(zhì)量好。很多東西可以直接復(fù)用。并且有大量的用戶(hù)來(lái)測(cè)試同一套基礎(chǔ)框架，節(jié)約了測(cè)試成本。

2. 迭代更快

由于有大量的用戶(hù)反饋，***的技術(shù)趨勢(shì)往往在開(kāi)源軟件里被迅速加上。而獨(dú)立軟件開(kāi)發(fā)者可能沒(méi)有這樣的動(dòng)力。比如，Rails 中增加的 CoffeeScript 支持，asserts 聚合支持。

3. 架構(gòu)完整

每個(gè)開(kāi)發(fā)者或者架構(gòu)師都有自己的盲點(diǎn)。因?yàn)榇笮蛙浖莻€(gè)系統(tǒng)工程，少量的人難以覆蓋所有的點(diǎn)。象很多國(guó)內(nèi)大型網(wǎng)站暴出的 XSS 漏洞。可能僅僅是知識(shí)面的問(wèn)題和重視程度的問(wèn)題。開(kāi)源軟件則有擅長(zhǎng)各個(gè)方向的開(kāi)發(fā)者共同決策，改進(jìn)。

4. 技術(shù)支持

文檔維護(hù)和后期的技術(shù)支持可能是比開(kāi)發(fā)本身更耗費(fèi)成本的工作。開(kāi)源軟件往往有大量的人分享文檔和寫(xiě)博客。同樣的需求和問(wèn)題，大部分情況下別人已經(jīng)遇到過(guò)，并且有解決方案。而內(nèi)部開(kāi)發(fā)文檔維護(hù)極難，培訓(xùn)和溝通也非常耗費(fèi)時(shí)間。

5. 架構(gòu)于開(kāi)源的”弊端”

開(kāi)源基礎(chǔ)框架的弊端是它過(guò)于龐大，弄清楚所有細(xì)節(jié)是非常耗費(fèi)時(shí)間的。所以經(jīng)常會(huì)遇到問(wèn)題，而且需要重新研究如何處理。相對(duì)于從零架構(gòu)我們了解所有細(xì)節(jié)，開(kāi)源產(chǎn)品更像面對(duì)和使用一個(gè)黑盒。不過(guò)好在很多人在用就已經(jīng)證明了它的正確性。

6. 選擇架構(gòu)于零和架構(gòu)于開(kāi)源

假如團(tuán)隊(duì)時(shí)間和資源相對(duì)缺乏，相關(guān)經(jīng)驗(yàn)比較少，架構(gòu)于開(kāi)源可能是***的選擇。節(jié)約了開(kāi)發(fā)成本，就可以將更多精力放到其他方面。

如果架構(gòu)師有足夠經(jīng)驗(yàn)熟悉整個(gè)系統(tǒng)的各個(gè)方面，有足夠精力追蹤所有技術(shù)趨勢(shì)，而且所建系統(tǒng)很簡(jiǎn)單，或者所建系統(tǒng)跟現(xiàn)有開(kāi)源產(chǎn)品差別很大，則可以選擇從零架構(gòu)。不過(guò)這”很難”。有時(shí)候群策群力的結(jié)果比一個(gè)專(zhuān)家更好。

來(lái)源：http://blog.eood.cn/why_based_on_open