無論是分析問題還是學習知識，都是有規律可循的，遵循這個規律會事半功倍。這個規律，我們就可以稱之爲方法論。總結起來就是三個關鍵詞：What、How、Why。但是二者不同之處在於三個關鍵點的組織順序不一樣。
分析問題
方法論：Why -> What -> How
舉例來說，現在我們要解決這樣一個問題（需求）：設計一個消息中間件的主備方案。
問題很明確，但是我們要怎麼快速、清晰的分析，並最終解決這個問題呢？讓我們根據方法論來一步一步分析。
Why
我們爲什麼要做主備方案呢？因爲想避免在A主機宕機的場景下，客戶端程序依然可以正常的發佈和拉取消息。其實Why很簡單，但是其卻很重要。不分析清楚Why，就失去了驅動力；沒有驅動力，你的上級會提供資源支持你解決這個問題嗎？下級能夠更合理的設計和開發嗎？顯然不能！
What
主備方案是爲了提升應用的高可用。可是這是比較籠統的一個目標，並不是很清晰，比如究竟要達到什麼程度的高可用呢？是要所有功能都要高可用？還是某些功能高可用？確定了這些細節，那麼我們就搞清楚了What，也就是我們最終會把這個問題解決到什麼程度？是全部解決？還是部分解決？總結起來What的關鍵如下：
1. 我們在什麼場景下，保證（或提供）什麼； 2. 我們在什麼場景下，不保證（或不提供）什麼。假設最終我們分析後，確定我們是要保證在任何一臺主機宕機的情況下，依然能夠正常提供消息的發佈和拉取。繼續分析，假設本身是集羣部署，那麼對於發佈消息來說，本身就是高可用的，因爲A主機不能發佈消息，我發佈到B、C…主機就可以了。但是對於拉取消息來說，如果底層不是共用存儲，一旦A主機宕機，那麼其消息就無法拉取，很明顯不具備高可用。
經過上邊的分析，那麼其實我們就明白了，我們的核心目標是要實現消息拉取功能的高可用性。
How
搞清楚了What，就要開始動手了。動手之前，需要考慮清楚怎麼做。通常來講，主備方案需要解決兩個核心問題：
故障檢測
狀態和決策
具體到每一個核心問題究竟要怎麼解決？採用什麼技術解決？這些都是How要解決的問題。關於主備方案的詳細設計過程，參見博文：
學習知識
方法論：What -> How -> Why
人類學習一個技能或者一個知識，總是遵循由淺入深的規律，What -> How -> Why。下邊拿我們學習Spring框架的來說。
What
Spring是什麼？它的主要特點是什麼？它能幫助我們幹什麼？知道了這些，你就可以在可以說：我瞭解Spring。如果你先工作中暫時用不到，認爲沒必要深入學習，那知道What就夠了。將來在做方案決策的時候，就可以進行簡單的方案對比。
How
Spring怎麼用於開發？功能怎麼搭建？依賴怎麼管理？知道了這些，你就可以說：我熟悉Spring，能夠獨立的應用Spring進行應用開發。
Why
Spring爲什麼要採用依賴注入？爲什麼要採用插件式設計？爲什麼要配置優先？更深一點，爲什麼某段代碼是這麼設計？知道了這些，那麼你就可以說：我精通Spring，甚至可以編寫類似的MVC框架。