【轉】架構師的自我修養(一)

1. 架構師既是技術專家，同時也是業務領域的專家，可以預見業務領域風險，並提供解決的辦法。技術上經驗豐富的人會有不少，只要在技術的道路上，老是會沉澱各類各樣的技術。而對於業務的把握，則是一個緣分。須要有額外的興趣，額外的時間投入，纔可以有機會在相關的業務領域深刻下去。

 

2. 架構師在選擇技術的時候，要爲客戶着想，而不是爲本身的簡歷着想，添上光輝一筆。

 

3. 選取框架技術的時候，量體裁衣，不要引入複雜性。衡量框架複雜性的指標： 代碼中解決業務問題的代碼所佔的比例。

 

4. 項目中人才是關鍵，對於拖後腿的成員，要引入對話。首先，看到這我的的優勢，設定一個共同的目標（最好是幫助別人）順帶可以彌補他的缺點，控制好情緒去溝通。（憤怒，沮喪，煩惱，慌張等都不可取）

 

5. 架構師可以言簡意賅地表達本身的命令和技術決策很是重要，這能提升溝通效率，沒有人願意閱讀冗長的架構決策文檔。簡便的白板，圖表，加相

 

6. 架構師是團隊的領導，必需要以身做則，得到同伴的尊敬，創建團結的工做環境

 

7. 架構決定性能，遵循分佈式計算，物理學的基本原理來提升性能。架構性能是一個複雜的主題，從需求，到應用實現層，最後到數據庫層，均可以作不少工做。不能輕信廠商，簡單的更換硬件，或者底層軟件架構WLS,JBOSS。

 

8. 分析客戶需求背後的意義，極其更深層次的緣由。好比，戰鬥機的速度需求是2.5馬赫(2倍音速)，  但這個需求背後的意義是「迅速撤離戰場」，設計團隊其實可以提出更好的建議，而不只僅是2倍音速。因此架構師須要理解用戶需求背後的意義，站在同一個層面去思考問題，提出更有效的解決方案,，而且把最有價值的需求擺在第一位。 瞭解背後的需求一般都不那麼容易，由於客戶常常認爲那是不言而喻的，而技術團隊則很難理解。

 

9. 增長本身的影響力，表現力，讓開發人員，或者管理層接受本身的意見。任什麼時候候都要以積極有效的狀態去銷售觀點。好比，起立發言，眼神交流，語速等

 

10. 認可任何系統都有缺陷，因此要事先設計好防範故障的模型，應對威脅系統安全的意外狀況

 

11. 架構師應該謹慎地站在業務團隊的一邊，把投資回報率看成項目的目標。

 

12. 架構師在面對需求時，要有足夠的敏銳，讓需求得以量化。而不是模棱兩可的「要快」，「要可伸縮」，「要靈活」。 面對沒法量化，至少要給一個範圍

 

13. 項目開始時候就關注性能的設計，進行相關的性能測試。

 

14. 架構師要兼顧平衡，不只創造優質軟件，同時兼顧不一樣Stakeholder的目標。CEO要控制成本，運營要易於管理，開發要代碼方便維護。有時緊急任務會打破平衡，讓一些不易於維護的代碼實現緊急需求，可是長期看，仍是要維持一個穩定的平衡。

 

15. 想盡一切辦法，讓團隊杜絕草率提交代碼的行爲。避免把有缺陷的代碼丟給同事。因此自動化構建，自動化測試框架尤其重要。

 

16. 不少架構師都很是看重通用性和複用性，並以此做爲炫耀的資本，最後形成過分的設計。追求所謂的靈活性，每每會錯失一些簡單的設計，以及更有價值的特性。 因此原則上，先確保解決方案的簡單可用，再考慮通用性和複用性。

 

17. 架構師是技術團隊和業務團隊的接口人，能勝任全部的技術，才能表明技術團隊發言。同時又要懂得業務，督促技術知足業務的需求。 要展現本身的實踐能力，創建威信並贏得你們的尊重，成爲你們的榜樣。

 

18. 謹記MF的名言「儘早構建，持續構建」

 

19. 架構師要有談判的技巧來應付突如其來的時間縮短，功能增多等要求來改變計劃。迅速代表立場，質量爲上，若是加快進度，那麼就去掉部分不那麼重要的功能，可是要確保核心功能的質量。 (取捨的藝術，經過講故事來談判，「瓦納號」: 波蘭國王提需求，既運兵又做戰，結果起航禮炮結束後就馬上沉沒了)

 

20. 架構師要很是很是重視數據的建模，嚴格遵照完整性，儘量使用約束，恰當的Key，同時名稱的定義也要不言而喻。

 

原文連接：

https://zzhonghe.iteye.com/blog/2032491