架構師應該扮演的角色是一個引導者、討論發起者、花草修剪者，而不是定義者和構建者。
- KISS(Keep it simple,sutpid) 和保持每件事情都儘可能的簡單
- YAGNI(You aren’t gonna need it)-不要去搞一些不需要的東西
- 爬，走，跑
- 時刻要想投入產出比（ROI）
- 瞭解你的用戶，然後基於此來平衡你需要做哪些事情
- 設計和測試一個功能得儘可能的獨立
- 不可能預測到用戶將會如何使用我們的產品。要擁抱MVP（Minimal Viable Product），最小可運行版本。挑幾個很少的使用場景，然後把它搞出來，然後發佈上線讓用戶使用，然後基於體驗和用戶反饋再決定下一步要做什麼
- 有時候你要有勇氣和客戶說不。這時候你需要找到一個更好的解決方案來去解決。記住亨利福特曾經說過的 ：”如果我問人們他們需要什麼，他們會說我需要一匹速度更快的馬”。記住：你是那個專家，你要去引導和領導。要去做正確的事情，而不是流行的事情。最終用戶會感謝你爲他們提供了汽車。
- 知道CAP理論。可擴展的事務（分佈式事務）是很難的。如果可能的的話，儘可能的使用補償機制。RDBMS事務是無法擴展的。
- 最好的產品是不需要產品手冊的。
- 當你無法在兩個選擇中做決定的時候，請不要直接把這個問題通過提供配置選項的方式傳遞給用戶。這樣只能讓用戶更加的發懵。如果連你這個專家都無法選擇的情況下，交給一個比你瞭解的還少的人這樣合適嗎？最好的做法的是每次都找到一個可行的選項；次好的做法是自動的給出選項，第三好的做法是增加一個配置參數，然後設置一個合理的默認值。
- 總是要爲配置設置一個合理的默認值。
- 設計不良的配置會造成一些困擾。應該總是爲配置提供一些示例值。