軟體架構師是我們很多學習軟體開發者的最初的夢想，於是拼命地學習各種程式語言，各種程式設計技巧、演算法、框架，迷戀時髦的新技術等，樂此不疲。但是，我們卻忽略了乙個很重要的東西，那就是業務領域，忽略了和人打交道的技巧。
架構師是個二面神，一方面要和客戶交流和談判，理解業務需求，另一方面還要向開發人員傳遞理解後的需求，並制定整個系統的架構。但是，有時候客戶都不知道他到底需要的是什麼，或者他想要的並不一定是最好的。這個時候，就需要架構師憑藉自己以往的經驗去推薦一些解決方案，並同時提出一些建設性的意見。這個時候，一定要以客戶的利益至上，要站在客戶的角度想問題（有時候客戶的客戶才是我們真正的客戶）。不要為了豐富自己的簡歷，推薦一些花哨的方案，要盡可能簡單、穩定、高效。kiss原則非常重要，不管是解決方案的選擇還是具體方案的實施，應該盡可能先保證其簡單可行，即得到可以執行的軟體，然後再考慮其通用性和移植性。現在大行其道的敏捷軟體開發方法，先搭建乙個可執行的骨架，然後不斷地迭代開發，每次迭代都得到乙個可以工作的軟體，讓使用者使用，得到反饋後再不斷調整需求和設計，這樣才能生產出客戶想要的軟體。在和客戶就一些軟硬體的選擇、是否購買伺服器，買幾台，哪些服務自己開發，**購買等方面，要注意自己是在談判，而不是求妥協。要善於用財務分析等量化手段來說服客戶。對於終端使用者而言，最終介面就是系統，所以系統的介面要友好，使用者體驗一定要好，同時還要考慮到使用者能夠接受的程度。從專案開始的時候，就要綜合考慮時間、成本、質量、風險，這些都是不可避免的話題。架構決定效能，一些實踐準則說說不要盡早優化，它指的是區域性**的問題。但是架構的關注的是整個系統的效能，至少要在第3次迭代的時候加以關注，不然等到專案快完成的時候來追究問題，已經悔之晚矣。
接下談談架構師作為技術人員，該扮演的是什麼角色呢？他應該助力開發團隊，扮演乙個管家而不是乙個演員。乙個好的架構師不應該在團隊在炫耀自己的才能，去搞一些很複雜的技巧和模式。相反，應該調動開發人員的主動性和創造性，在團隊裡面營造一種積極主動向上的氛圍。團隊裡每個人都可以自由地提出自己的問題而不用擔心被指責。軟體應該是培育起來的，而不是架構起來的。任何事前的設計都有可能隨著時間而改變，要防止過度設計和模式病。同時還要抑制開發過程中出現的「好點子」與「奇思妙想」。這些都會間接的影響專案的開發進度。scrum方法提出了非常好的敏捷方法實踐，他提出的每日站立會議和任務訂單，衝刺訂單（衝刺過程中凍結需求），不斷調整計畫，持續整合、交付等。非常適合小型團隊的軟體開發。軟體是由人開發出來的，因此對於乙個好的架構師來說，比聰明更重要的是靈動的心智，要善於在各種複雜因素之間做「折中」。懂得陰陽變化之道，方能游刃有餘啊。
架構師應該向建築師學習。
每次做架構設計時，提供兩種以上的解決方案。
先考慮一些公理、原則和最佳實踐，再考慮個人興趣和愛好。
注意談話的技巧。
記錄每一次決策過程.
讀《軟體架構師應該知道的97件事》有感
其實拿到博文視點 贈送的這本 軟體架構師應該知道的97件事 已經有一段時間了，可一直沒有時間去讀。在剛剛忙完乙個大專案之後，又有資料庫集群的架構需要調整。想想事情永遠是做不完的，再忙也不能把給自己充電的事情落下。還好，這是一本不需要有大段連續時間來讀的書，只要有一點點時間，就可以翻開書頁學幾件 應該...
軟體架構師應該知道的97件事 筆記 一
1.客戶需求重於個人簡歷 不要為了學習新的知識或豐富自己的簡歷而選擇新技術解決問題，要盡量選擇切合實際的技術解決客戶的難題。腳踏實地的為客戶著想，選擇正確的方案可以降低專案的壓力，團隊工作起來更開心，客戶也會更滿意，從而你也會有更充裕的時間學習新的知識。2.簡化根本複雜性，消除偶發複雜性 根本複雜性...
軟體架構師應該知道的97件事 筆記 四
46.避免重複 如果開發人員複製救命 中的內容，說明這部分還可以簡化，甚至全部提取出來。消滅複製是架構師的責任，如果有重複，則應該重新研究框架，創造更完善的抽象機制。47.歡迎來到現實世界 現實世界是不可預知的，隨時都可能發生一些讓人預料不到的事情，如客戶撤消訂單，付款時間延誤等。如果現實世界帶來了...