軟件架構(gòu)師的定義乃至所需要的特質(zhì)歷來(lái)眾說(shuō)紛紜。下面從一些另類(lèi)的角度來(lái)做點(diǎn)分析。

從產(chǎn)生根源來(lái)看，程序規(guī)模越大，參與人員越多，越需要架構(gòu)師；

程序越小，參與人員越精英化，架構(gòu)師存在價(jià)值越小。

這不難理解，大軍團(tuán)作戰(zhàn)，總不好一窩蜂就上去了，總要有些規(guī)則，總要有人把我全局。

架構(gòu)師就是在比較高的層面上把握全局的這個(gè)人。

從這個(gè)角度來(lái)看，對(duì)架構(gòu)師而言選擇最重要，因?yàn)檎镜母?，所以選擇具有非常大的價(jià)值。

注意不是UML，也不是對(duì)業(yè)務(wù)的理解，不是編碼能力而是做出正確選擇的能力。

當(dāng)下的開(kāi)發(fā)環(huán)境下，考慮解決方案時(shí)，所面臨的選擇不是太少，而是太多。

舉個(gè)最簡(jiǎn)單的例子，我們要開(kāi)發(fā)一個(gè)基于Web的項(xiàng)目管理程序，那么你面臨的選擇是：

• 自己從頭造，還是用現(xiàn)成的做二次開(kāi)發(fā)？
• 用現(xiàn)成的，是用開(kāi)源產(chǎn)品還是微軟的？
• 用微軟的話，是用MS Project還是基于SharePoint?
• 用開(kāi)源產(chǎn)品，有這么多選項(xiàng)究竟導(dǎo)入那一個(gè)?
• 如果自己從頭造，那么是基于微軟的技術(shù)，還是基于Linux?
• 使用什么框架么?
• 如果要做，用什么語(yǔ)言?

每一個(gè)這類(lèi)選擇的背后都是赤裸裸的利益---在商業(yè)環(huán)境下永遠(yuǎn)不要忘了這個(gè)。

做選擇其實(shí)可以很容易，所以是個(gè)人就可以干這活，并不具備很高的門(mén)檻。

關(guān)鍵差異是有無(wú)根據(jù)和正確程度。

如果說(shuō)程序員的生產(chǎn)效能可以差10倍的話，架構(gòu)師的價(jià)值可以差無(wú)數(shù)倍。

想選擇正確，最關(guān)鍵的前提是理解待選擇的選項(xiàng)和外部的切實(shí)要求。

前一點(diǎn)很難，這往往要求一個(gè)人涉獵廣泛，在很多的領(lǐng)域中具有經(jīng)驗(yàn)。

不只要知道LAMP，還要知道asp，不只要知道軟件還是知道些硬件，不只要了解Java，可能還要了解C#。

理解程度倒未必一定要很精通，關(guān)鍵是要抓住差異以及其適用場(chǎng)景。

但這恰恰與這個(gè)時(shí)代的特征相反，在這個(gè)時(shí)代里，技術(shù)日趨繁雜，專(zhuān)家越來(lái)越多，通才越來(lái)越少，諸神隕落啊。

走極端的人可能會(huì)說(shuō)，那么多人，沒(méi)懂什么，去做網(wǎng)站也成功了。

這也可能，運(yùn)氣很好的話，什么也不懂，一樣可以做很對(duì)的選擇。

但能力這種事，本來(lái)最主要的就是盡可能去除運(yùn)氣成分。

從編碼的角度看，架構(gòu)師不懂編碼是不行，但卻不需要是最精通編碼的人。

一者謀的一隅，一者謀的是全局，因此也就導(dǎo)致對(duì)技能的要求不同。

原文鏈接：http://www.cnblogs.com/daoshi/archive/2012/08/13/2635664.html