1樓：大魔頭-諾鐵
敏捷裡的簡單設計源自kent beck的極限程式設計。 kent beck自己是解釋過這個實踐的含義的：
Passes the tests
Reveals intention
No duplication
Fewest elements
通得過測試、揭示意圖、沒有重複、沒有不必要的元素。
martin fowler有一篇文章解釋這個概念，你可以參考一下：
BeckDesignRules
2樓：紅綃楓葉
我們最終的目的都是怎樣最省力的解決乙個問題。
在軟體工程裡面，為了達到我們的目的，湧現出了很多理論方法。編碼方面，有軟體設計模式提高復用和應變能力;工程上從傳統過程模型到現代敏捷開發模型，期望實現高效的管理與控制。
工業生產更是如此。
對現有的理論方法成果進行思考，怎麼樣才能達到我們最終的目的，然後繼續推進現有理論方法，改進，以變的更好。我們應該始終記住的是現實情況往往沒有想的那麼簡單，現有的理論方法一定會有不適合的地方，我們要抱著始終改進的思想，才能走的更遠。
3樓：黃兢成
很多人將簡單理解成，直觀，一看就會。但這並非是簡單。
簡單，更應該指一致性，絕少甚至無例外。簡單的東西可以是不直觀的，甚至需要學習，但一旦學會了，就可以無差別地處理一大堆問題。
當乙個設計或做法，既是直觀也是一致的，當然是最好。但當直觀和一致，兩者不可兼得，我會優先選擇一致性而捨棄直觀，這樣做會更簡單的。而有些人正好相反，他們會優先選擇直觀。
如何評價《守望先鋒》架構設計？
a阿拉 哈哈 這個跟前端開發中的redux 叫好不叫座如出一轍啊，看來深刻體會了每種架構設計都有其自身設計的適用場景和運用範圍，比如redux 適用於時間旅行 記錄 回放，集中式資料來源的場景，比如編輯器 很抱歉，實在沒做過其他更適合的場景 ECS 適合有延遲的公網多人聯機網遊，跟傳統開發模式比起來...
「微服務」架構設計中如何把握「微」度，需要考慮哪幾方面因素？
kimmking 實際上服務劃分的本質是對系統進行架構設計，服務的劃分粒度沒有絕對的過大或過小之說，不同階段的側重點和思考的角度也不盡相同。創業初期的團隊，過分的追求微服務，為了 微 而微，反而會導致業務邏輯過於分散，技術架構過於複雜，團隊基礎設施搭建能力弱，進而導致忽略了快速迭代交付產品的重要性，...
你們是如何通過軟考的高階系統架構設計師的？
派大星yo 軟考包含三個考試級別 高階 中級和初級 系統架構設計師考試作為一項高階資格考試，且比較偏技術，有一定的考試難度。系統架構設計師是乙個最終確認和評估系統需求，給出開發規範，搭建系統實現的核心構架，並澄清技術細節 掃清主要難點的技術人員。通常一年只有一次考試，考試時間安排在下半年，報名時間是...