1. 客戶需求重於個人簡歷
不要為了學習新的知識或豐富自己的簡歷而選擇新技術解決問題，要盡量選擇切合實際的技術解決客戶的難題。
腳踏實地的為客戶著想，選擇正確的方案可以降低專案的壓力，團隊工作起來更開心，客戶也會更滿意，從而你也會有更充裕的時間學習新的知識。
2. 簡化根本複雜性，消除偶發複雜性
根本複雜性是問題本身就很複雜，所以它是無法避免的。偶發複雜性是在解決根本複雜性的過程中衍生的，即解決方案本身帶來的新問題。
如為了解決某個問題而設計的乙個軟體框架，設計該框架本身，就是引入的偶發複雜性。所以，如果原本問題比較簡單，但設計或引入乙個太過靈活的框架，可能得不償失。(避免過度設計)
3. 關鍵問題可能不是出在技術上
簡單的專案也可能會出現問題，這並不是因為我們選錯了某種語言或者系統，根本原因還是「人」
所以，要幫助團隊完成專案，多與專案成員溝通，及時改正團隊成員不正確的工作方式。
溝通的技巧：
a) 不要把對話看成對抗
改變心態，發現他人的優點，把溝通視為請教，就會有所收穫，並且能避免引入對方的戒備之心。
b) 不要帶著情緒與人溝通
當你處於憤怒、沮喪、煩惱等情緒中時，對方可能會誤認為你的舉動不懷好意。
c) 嘗試通過溝通設定共同的目標
4. 以溝通為中心，堅持簡明清晰的表達方式和開明的領導風格
架構師要避免只發號施令，讓開發人員執行的弊病。要讓開發人員了解專案的藍圖和決策過程，讓大家共同驗證你的架構，讓開發人員參與你的架構的制訂過程，這樣開發人員才能更心甘情願的去執行。
架構師應該提高自己的溝通技巧，幫助大家快速、精準的理解專案的目標。要言簡意賅的表達觀點，用簡單的圖表來表達自己的想法。
5. 架構決定效能
如果架構有問題，僅僅通過優化區域性，不足以獲得理想的效能的。找出效能瓶頸，優化瓶頸，如果需要的話，重新設計架構的內在邏輯和部署策略。
6. 分析客戶需求背後的意義
分析客戶提的需求，為什麼提這樣的需求。即要知道客戶要求的功能和需求的真正意義，這樣或許我們可以在達到客戶目的的情況下，採取更簡單的辦法。
7. 起立發言
在多人場合發表意見時，起立發言非常重要，尤其是其他人坐著的時候。站立時，無形中增添了一種權威和自信，容易控制了場面。聽眾不會輕易打斷你的發言。
站立時可以更好的利用肢體語言，且在十人以上的場合，起立發言方便與每位聽眾保持視線接觸。眼神交流和肢體語言等表達在溝通中的作用不可小覦。起立發言也更容易控制語氣、語調、語速和嗓門，讓聲音傳播的更遠。講到重點時，注意語速的減緩，發聲技巧也能改善溝通效果。
8. 故障終究會發生
為了防止a程式出錯，增加了監控程式b，但監控程式b本身就可能會出錯。所以故障及錯誤是無法避免的，即要做好錯誤的防範措施。
9. 我們常常忽略了自己在談判
專案投資人為了削減預算，可能會去掉一些「東西」。當投資人問「我們真的需要這東西嗎？」 很多任務程師把自己擺在了工程師的位置，會回答一些不使用這些東西的替代方案，但往往這些替代方案是極差的。在投資人看來，有其它方案可選，他不關心是什麼方案，他往往會讓你去掉這些「東西」。
我們這時應該把自己放到談判者的角度上，說明不使用該方案的壞處，以及使用該方案的好處。讓投資人清楚的認識到該方案的重要性。
10. 量化需求
「速度快」、「響應靈敏」都不能算需求，需求一定要可量化。比如響應時間在500ms以內。如果沒有這些具體數字，也要有乙個描述範圍，如上限、下限等。
11. 一行**比500行架構說明更有價值
要牢記我們的目標是可工作的**，設計只是手段。很多架構師往往被抽象的架構所吸引，沉迷於設計過程。沒有天生完美的設計，設計都是在實現過程中逐步完善的。如果有機會親自開發，珍惜這個機會。
12. 不存在放之四海皆準的解決方案
沒有通用的解決方案，遇到的問題也是千差萬別，架構師需要運用情境意識來解決問題（類似於常識）。情境意識需要培養和訓練，架構師要不斷的積累案例和經驗才能建立足夠的情境意識。要解決系統層次的問題，通常需要十年的磨練。
13. 提前關注效能問題
盡早進行效能測試，如果在某個時候效能表現大幅下滑，更容易找到效能下滑是由哪些變化引起的。如果以兩周為乙個迭代週期，效能測試的開始時間最遲不要晚於第三次迭代。尤其是對效能要求苛刻的系統，驗證的早晚直接關係到能否及時交付專案。
14. 架構設計要平衡兼顧多方需求
軟體架構不僅包含系統建模、定義介面、劃分功能模組、大勝模式、效能優化等，還包括系統的安全性、易用性、產品支援、發布管理、部署方式等問題。
架構師不僅要為使用者創造實用的軟體，還要平衡兼顧不同部門的目標，如ceo要求控制成本，運營部門要求易於管理，二次開發人員要求**易讀易維護等。
15. 草率提交任務是不負責任的行為
如果在提交**前，需要浪費很多時間進行測、驗證，則開發人員很可能會為了節省時間草率的提交了任務。一旦出現問題，就會浪費別人很多時間。所以架構師有必要改善這個過程，通過引入自動測試、持續整合等來糾正開發人員的行為。
架構師應沉下心來改善系統的生產效率，縮短流程，縮短開發時間，提公升開發體驗，減少構建**時間等，這樣也利於杜絕開發員草率提交任務的念頭。
軟體架構師應該知道的97件事 筆記 四
46.避免重複 如果開發人員複製救命 中的內容，說明這部分還可以簡化，甚至全部提取出來。消滅複製是架構師的責任，如果有重複，則應該重新研究框架，創造更完善的抽象機制。47.歡迎來到現實世界 現實世界是不可預知的，隨時都可能發生一些讓人預料不到的事情，如客戶撤消訂單，付款時間延誤等。如果現實世界帶來了...
讀《軟體架構師應該知道的97件事》有感
其實拿到博文視點 贈送的這本 軟體架構師應該知道的97件事 已經有一段時間了，可一直沒有時間去讀。在剛剛忙完乙個大專案之後，又有資料庫集群的架構需要調整。想想事情永遠是做不完的，再忙也不能把給自己充電的事情落下。還好，這是一本不需要有大段連續時間來讀的書，只要有一點點時間，就可以翻開書頁學幾件 應該...
軟體架構師應該知道的97件事之概括1 15
架構師是一種神秘的職位，據說每個架構師都有密不可傳的方法，當然我們不信，更多的是只可意會不可言傳。就是說了我們也不會懂，因為還每到 火候 所能做的就是，當我們到這種火候的時候我們能想起來曾經有過架構師這麼說過，然後我們就可以更自信的向前大步走.1 客戶需求重於個人簡歷 積累一批滿意的客戶，選擇切合實...