根本復雜性（essential complexity）指的是問題與生俱來的、無法避免的困難。...與之相反，偶發復雜性（addidental complexity）是人們解決根本復雜性的過程中衍生的。...架構師的責任在于解決問題的根本復雜性，同時避免引入偶發復雜性。
《簡化根本復雜性，消除偶發復雜性》Neal Ford
大多數項目是由人完成的，人才是項目成敗與否的基礎。如何幫助團隊成員完成項目，這個問題很值得靜下心來好好思考。
關于對話的技巧非常多，但有幾個簡單的技巧可以顯著改善對話的效果：
1.不要把對話當成對抗。如果你能看到他人的優點，并把溝通視為請教問題的機會，就會有所收獲，同時也能避免引起對方的戒備之心。
2.不要帶著情緒與人溝通。當你處于憤怒、沮喪、煩惱，或者慌張的情緒中時，對方很可能會誤認為你的舉動不懷好意。
3.嘗試通過溝通設定共同的目標。有些人開會時喋喋不休影響別人發言，與其命令他閉嘴，不如請他協助你提高其他人的參與度。告訴他有些同事比較內向，發言前需要安靜地理清思路。請他在每次發言之前稍作等待，讓同事有機會表達意見。
首先與同事達成一致的目標，把處理沖突和矛盾的過程視為學習的機會，控制住自己的情緒，那么每次溝通都會有所收獲，你會做得越來越好。
《關鍵問題可能不是出在技術上》Mark Ramm
以溝通為中心，堅持簡明清晰的表達方式和開明的領導風格。Mark Richards
讓溝通事半功倍，起立發言是最簡單、有效的方法！《起立發言》Udi Dahan
工程師總是想盡辦法尋求合作，談判者則絞盡腦汁占得先機。談判時，絕不能在對方的第一個要求上妥協讓步。《我們常常忽略了自己在談判》Michael Nygard
眾所周知，堅持技術測試是需要耐心和毅力的，無論是搭建合適的測試環境，采集適當的數據集，還是編寫必要的測試用例，都須要投入大量的時間。提前開展性能測試，能讓你有條不紊地逐步完善測試環境，為解決性能問題節省下大量的時間和精力。《提前關注性能問題》Rebecca Parsons
以維護流程通暢為重，以浪費他人時間為恥。《草率提交任務是不負責任的行為》Niclas Nilsson
如果存在多個可實施方案難以取舍，“先簡單后通用”原則可以成為最終的評判標準。挑選基于具體需求的簡單方案，放棄鼓吹通用性的負責方案。而且簡單的方案在實踐中完全有可能表現出更好的通用性。退一步來說，修改簡單方案滿足需求，也比修改通用方案容易，因為通用方案常常在最關鍵的地方使不上勁兒。
追求隨心所欲的靈活性，會使人們在無意中錯失（有些人甚至故意忽略）更簡單的設計和更有價值的特性。《先確保解決方案簡單可用，再考慮通用性和復用性》Kelin Henney
稱職的架構師應該通過示范領導團隊。他能勝任團隊的所有工作，從網絡布線到配置構建流程，從編寫單元測試到擔任測試工作。對技術缺乏全面理解的架構師，充其量只是個項目經理。《架構師應該親力親為》John Davies
架構師應該明白魚和熊掌不可兼得的道理。世上不存在十全十美的設計——既具有高性能，又具有高可用性；既高度安全，又高度抽象；有一個真實的歷史事件，軟件架構師應該爛熟于心，在與客戶或同事溝通時能派上用場。這就是瓦薩號戰艦的故事。
17世紀20年代，瑞典和波蘭之間爆發戰爭。瑞典國王迫于戰爭經費的壓力，急欲速戰速決，他下令建造一艘名為瓦薩號的戰艦。這可不是一艘普通的戰艦，其設計要求絕非同時代戰艦可比：戰艦長60米，兩個炮臺上配備64門艦炮，可以將300名士兵從水路安全運送到波蘭。時間緊迫，資金緊張，而且設計師從未設計過這種規模的戰艦，只能憑經驗和猜測著手設計。最終，工匠們按照設計說明建造了戰艦。下水那天，瓦薩號在隆重的儀式中駛入海港，鳴完禮炮后，徑直沉入了海底。
瓦薩號的問題很明顯。參觀過17、18世界大型戰艦的人都知道，甲板上空間有限而危險，作戰時情況更糟。建造一艘既能作戰又能運兵的戰艦是一個巨大的錯誤。設計師為了滿足國王的心愿，設計了一艘性能失衡、不堪一擊的戰艦。《取舍的藝術》Mark Richards
《不要輕易放過不起眼的問題》全文 Dave Quick
即便是最精美的架構，最優雅的框架，可復用性最高的系統，也必須滿足下面的條件才可能被復用。
大家知道他們存在；
大家知道如何使用他們；
大家認識到利用已有資源好過自己動手。
《讓大家學會復用》Jeremy Meyer
《架構里沒有大寫的“I”》全文 Dave Quick
兩條公認的軟件開發的真理：
復制是魔鬼；
重復性的工作拖累開發進度。
消滅重復的內容是你的責任，為此，應該重新研究框架，創造更完善的抽象機制，請專門制作工具的程序員幫你完成切面框架，或者使用代碼生成器。要想消滅重復內容必須有人采取行動。
這個人就是你。
《避免重復》Niclas Nilsson
計算機科學家設想的完美世界正在崩潰，我們該怎么辦？克服所有困難的步驟都一樣，首先要接受現實。向令人懷念的調用堆棧架構告別吧，忘掉那些程序員決定程序流程的日子，準備好應付隨時出現的亂序事件，不斷根據具體情境調整策略。用異步的、并發的請求代替一個接一個的方法調用。設計應用時，借助事件驅動的過程鏈模型或狀態模型控制無序的狀況，通過調整、重發，甚至試探的辦法糾正錯誤。
《歡迎來到現實世界》Gregor Hohpe
架構師會從主觀的判斷或潛在不確定需求出發，產生調整解決方案的強烈沖動。請記住一點：試圖猜測未來的需求時，錯的概率是50%，錯得很離譜的概率是49%。今天只需要解決今天的問題就好。《確保簡單的問題有簡單的解》Chad La Cigne
長遠看來，系統維護將比項目初期的開發消耗更多的資源。進行系統架構設計時，牢記這點非常重要。在項目開發初期走捷徑，可能會以日后付出高昂的維護費用為代價。
碰到架構問題或設計缺陷，作為架構師，一定要堅持成本還很低廉時就動手。擱置越久，為之付出的利息也將越高。《現在走捷徑，將來付利息》Scot ZMcphee
我的建議是：不要屈服于企圖使設計或實現達到完美的誘惑！把目標設定在“足夠好”就行，當已經達成目標時，就停下來。
你可能會問，究竟什么是“足夠好”？“足夠好”指得是，剩余的不完美之處，對系統的功能、可維護性或性能不會產生任何有深遠意義的影響。架構和設計協調一致；系統的實現正確可用，并符合性能需求；代碼整合簡潔，文檔化良好。還可以做得更好嗎？當然可以，但這樣已經足夠好，所以就到此為止了吧。可以宣布設計勝利完成，然后轉入下一個任務了。
在我看來，再設計和實現上追求完美，會導致過度設計和模糊混亂的解決方案，最終使系統難以維護。
《不要追求完美，足夠好就行》Greg Nyberg
如果出現下面這些關鍵詞，要小心了：
“如果。。。，會更酷。”實際上，任何語句如果帶有“酷”字，都是危險信號。
“嘿，他們剛剛發布了YYY框架的XXX版本。我們應該馬上升級！”
“由于我們在使用ZZZ，你知道，我們確實應該重構XXX。。。”
“XXX技術真的很強大！也許我們可以把它用于。。。”
《小心“好主意”》Greg Nyberg
如果都不知道一個東西應該叫什么，那你肯定不知道它究竟是什么。如果你不知道它究竟是什么，那么你也肯定不能坐下來為它編寫代碼。
如果無法給出合適的命名，那也就無法繼續編程。如果發現自己需要多次更改命名，那么最好停下來，直到弄清楚要做的究竟是什么。
《命名要恰如其分》Sam Gardiner
聰明的軟件價格昂貴，不易維護，僵脆易折。所以，不要追求聰明，盡量用最淺顯易懂的質樸方法，恰如其分的進行設計。
《棄聰明，求質樸》Eben Hewitt
軟件架構師工作很大的一部分，是要選擇用以攻克難題的合適技術。精心選擇熟悉的武器，不到萬不得已絕不輕易拋棄它們。這些技術在過去給你帶來了成功，盡量讓它們在未來也能為你帶來勝利，同時，以審慎的態度更新你的技術武器庫。
《精心選擇有效技術，絕不輕易拋棄》Chad La Vigne
沒錯，你的客戶確實不是你的客戶。你的客戶的客戶，才是你的客戶。如果你的客戶的客戶贏了，你的客戶也就贏了。這意味著，你也贏了。
我們也不配稱得上真正關愛我們的客戶，如果不能更為關愛他們的客戶。
《客戶的客戶才是你的客戶》Eben Hewitt
《著重強調項目的商業價值》全文 周異
設計盡可能小的系統，幫助成功交付，并推動它向宏偉的遠景目標不斷演化。雖然聽起來似乎是放棄了控制權，甚至是在逃避責任，但是最終，利益相關者會感謝你。
《優秀軟件不是構建出來的，而是培育起來的》Bill de Hora