對架構師而言，什麼最重要？

軟體架構師的定義乃至所需要的特質曆來眾說紛紜。下面從一些另類的角度來做點分析。

 

從產生根源來看，程式規模越大，參與人員越多，越需要架構師；

程式越小，參與人員越精英化，架構師存在價值越小。

 

這不難理解，大軍團作戰，總不好一窩蜂就上去了，總要有些規則，總要有人把我全域。

架構師就是在比較高的層面上把握全域的這個人。

 

從這個角度來看，對架構師而言選擇最重要，因為站的高，所以選擇具有非常大的價值。

注意不是UML，也不是對業務的理解，不是編碼能力而是做出正確選擇的能力。

 

當下的開發環境下，考慮解決方案時，所面臨的選擇不是太少，而是太多。

舉個最簡單的例子，我們要開發一個基於Web的專案管理程式，那麼你面臨的選擇是：

• 自己從頭造，還是用現成的做二次開發？
• 用現成的，是用開源產品還是微軟的？
• 用微軟的話，是用MS Project還是基於SharePoint?
• 用開源產品，有這麼多選項究竟匯入那一個?
• 如果自己從頭造，那麼是基於微軟的技術，還是基於Linux?
• 使用什麼架構麼?
• 如果要做，用什麼語言?

每一個這類選擇的背後都是赤裸裸的利益---在商業環境下永遠不要忘了這個。

做選擇其實可以很容易，所以是個人就可以幹這活，並不具備很高的門檻。

關鍵差異是有無根據和正確程度。

如果說程式員的生產效能可以差10倍的話，架構師的價值可以差無數倍。

 

想選擇正確，最關鍵的前提是理解待選擇的選項和外部的切實要求。

 

前一點很難，這往往要求一個人涉獵廣泛，在很多的領域中具有經驗。

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

理解程度倒未必一定要很精通，關鍵是要抓住差異以及其適用情境。

 

但這恰恰與這個時代的特徵相反，在這個時代裡，技術日趨繁雜，專家越來越多，通才越來越少，諸神隕落啊。

 

 

走極端的人可能會說，那麼多人，沒懂什麼，去做網站也成功了。

這也可能，運氣很好的話，什麼也不懂，一樣可以做很對的選擇。

但能力這種事，本來最主要的就是儘可能去除運氣成分。

 

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

一者謀的一隅，一者謀的是全域，因此也就導致對技能的要求不同。