另外一個角度的架構師

架構師要作什麼？

ADMEMS矩陣，明確介紹了架構師須要思考的問題，而在這個矩陣中，作爲一個架構師最須要了解的什麼呢？技術？業務？都不是，最須要了解的是你的領導，其次是你的團隊成員。

若是你的領導是不懂且不放權的類型，那你的好架構要如何實現呢。若是你的團隊技術爛的一塌糊塗，又如何開發出成熟的產品？看看ADMEMS矩陣，理論上是先上後下，先左後右。而現實中，應該是先右後左，先下後上。

 

看了ADMEMS矩陣，最重要的就是約束，最最重要的就是開發需求對應的約束。那麼架構師要如何分析這些呢。

首先分析你的領導

1，  肯定他是否能清晰的分辨出團隊成員技術的高下，這個清晰很重要，要十分清晰。

2，  肯定他支持你架構設計的力度，（強烈支持，仍是設計的好就用不行就不用）

3，  肯定他是否真的理解了架構的重要性，仍是他只是爲了給工做計劃戴個好看的帽子，仍是二者都有。

以上三點只要有一點不知足你的架構基本上就很難實現，爲何是很難而不是不能呢？由於團隊成員足以彌補一些領導的能力不足。

接着分析你的團隊成員

1，  你的團隊成員能力差距是否過大。

2，  你的團隊成員能力高的和低的比例是多少。

正所謂巧婦難爲無米之炊，即便你再棒，也沒辦法一我的作項目。團隊成員固然都是高手最好，若是是2：1也能夠接受，若是是能力低的多，那就要看領導了，若是他不符合上面三點，那軟件開發流程就只會是和稀泥式的前進。架構與否就不那麼重要了。當成員和領導都是優秀的時候，那麼在分析其餘需求又有何難呢?

 

架構設計要思考的問題

一個軟件架構師最重要的問題，就是他所設計的產品必須是知足客戶戰略規劃的需求，可以幫助客戶解決實際問題的。

這是理論上，或者說是書本上的知識點，現實中的變數太多。首先要考慮這三個問題，who,what,why。

Who：爲誰設計？

你設計的架構是爲客戶設計的嗎？你的客戶理解你的架構的重要性嗎，也許連什麼是架構都不懂吧。若是你的客戶理解，那麼恭喜你，你是在爲客戶設計一套理想的架構。若是不理解，那麼很遺憾，你並非爲你的客戶在設計，你是在爲你公司的領導在設計。那麼你設計的東西就須要爲他們講解。記得，有時候領導比客戶更笨拙。而且他們會要求不斷解釋那些1+1=2的問題。有些架構師過久不去溫習那些基礎，只是記得1+1=2，卻忘記了如何解釋，那麼很遺憾你的架構將遭到懷疑。我記得之前帶個人前行一位架構師和我說過這麼一句話，「信則靈，不信則不靈」，這不是迷信，爲何呢?由於架構師要能把全部的東西都給領導和團隊成員講明白，那你們就都是架構師啦，不是架構師講不明白，是對手聽不懂啊。

What：要解決用戶的什麼問題？

性能低下?結構轉換？可維護性差？領導面子？（一點很差笑，真的有公司這麼作的）。

我見過一個公司，他們的產品還能運行，但改起來很難受，程序員每天抱怨。因而就請了一個架構師，目的有二，（1）修改產品結構，下降維護成本（2）使員工不要抱怨。結果固然是無疾而終了，新架構上不去，又折騰了很久。最後不愉快的離開。緣由是什麼呢？首先領導並非全力支持他，這會致使什麼結果呢？他必須設計出天衣無縫的架構，而且擁有神同樣的講解能力，不然新架構永遠是有風險的。而如今的程序還能運行，不可能去冒這麼大的風險。因爲這個強力矛盾的存在，那麼其餘問題也就應運而生了。至於性能低下，結構轉換，可維護性差等等，這些技術層面能解決的問題就顯得不那麼重要了。

Why：爲何要解決這些用戶問題？

提升用戶體驗？用戶強制要求？合理化軟件程序？爲業務拓展作基礎？首先要肯定，這些真的是用戶需求嗎？仍是程序員們和業務們總結出來的理想建議。若是真的是從用戶那裏獲得的，那麼恭喜你，對症下藥，功德無量。若是不是，那就是事倍功半，褒貶不一。抑或在根本沒法獲得客戶需求，那麼你就只能摸着石頭過河了，至於成敗，就只能謀事在人成事在天了。

 

總結

其實業界不少架構師都是摸着石頭過河的。又有許多架構師失敗並非由於架構和技術，只是沒讀懂領導的心。架構師首先要分析公司的現狀，而後再設計，固然發現公司現狀根本不可能完成架構時，那就要早作準備，不要等到最後背個黑鍋離開。若是公司問題太多，新就架構根本是無稽之談，那就着手於小分區的修改，這也是個長存之道。

 

----------------------------------------------------------------------------------------------------

注：此文章爲原創，任何形式的轉載都請聯繫做者得到受權並註明出處！
若您以爲這篇文章還不錯，請點擊下右下角的推薦，很是感謝！本文已獨家受權給腳本之家（ID:jb51net）公衆號發佈！