抽象

抽象是架構思維裡面的一個重點，其中包括兩個層面的內容：一個是常說的歸納方法，即各種類似場景的實現太多了，自然就歸納了一種規則或方法出來供以後的設計用；另一個是抽象，它更加重要，即將非類似場景中的共性內容也總結出來，進一步抽象為類似的東西，以更加方便地適應各種變化。

結構化

結構化是一種從框架到細節的思維方式，強調在分析問題的過程中，不先入為主，不馬上陷入細節。結構化也被稱為表格化的思維結構，強調結構和邏輯，透過結構的完整和邏輯的嚴密來保證結果的正確。結構化的核心在於對問題進行正確界定的基礎上（以終為始），對問題的構成要素進行合理分類，並對其中的重點環節進行分析（要事第一）。

結構化的原則結構化的原則如下。

◎ 以終為始。

◎ 知道做這件事情的目標是什麼。

◎ 根據這個目標倒推需要完成哪些工作和任務。

◎ 做任何一件事情都必須有一個目標，才能在分析論證過程中得到預期的結果。

◎ 不要先入為主，避免陷入細節。

◎ 必須對各種觀點進行分組，分組後的思想觀點在經過不同層次的抽象後構成金字塔。

◎ 分 類 原 則 MECE （ Mutually Exclusive CollectivelyExhaustive，相互獨立、完全窮盡）。

◎ 相互之間具有排他性，整體而言毫無遺漏。

簡單地說，結構化的原則就是不重疊、不遺漏。

結構化分析工具

結構化工具主要有如下幾種。

◎ 邏輯樹：又叫作問題樹、演繹樹或分解樹等，是將所有問題的子問題都分層羅列，從最高層開始逐步向下擴充套件。

◎ 議題樹：將問題分解成多個利於操作的小塊並分別進行處理，

在解決問題的早期還沒有足夠形成假設的基礎。◎ 假設樹：先給出解決問題的假設方案，再舉出所需的充足原因來驗證或推翻該假設，較早集中於潛在的問題，加快解決問題的程序，對情況有足夠的瞭解，能提出合理的假設方案。

◎ 是否樹：列出關鍵問題，使用“是”和“否”來回答，按照需要採取相應行動的邏輯順序來排列，確認對目前要做的決定有關鍵意義的問題，應該對事務及其結構有良好的理解，並可作為溝通工具。

◎ 二維表格。

◎ 80/20法則：80/20法則是分析式的方法。80/20分析法用於讓人注意到造成某種狀況的關鍵原因，也就是找到那些導致80%產出的20%投入。

結構化思維的7個環節

結構化思維的7個環節如下。

◎ Who：誰來做？

◎ What：內容是什麼、做什麼？

◎ When：什麼時候做？

◎ Where：在哪裡做？

◎ Why：為什麼做這件事情？

◎ How：怎麼做？

◎ How Much：用多少時間和其他資源？

迭代

迭代思維是我們在架構思考中需要考慮的另一個內容。沒有最優的架構，只有不斷進化的架構和最適合的架構，因此架構本身也在隨著業務需求的變化不斷迭代和演化，而不是追求用最新的技術一步到位。

架構設計往往發生在需求的細節尚未完成時。因此，隨著專案的進行，需求還可能細化、變更。原先的架構肯定會有不足或錯誤的地方。

借用一句名言，“凡事預則立，不預則廢”，在軟體設計初期，投入精力進行架構設計是很有必要的，這個架構是我們在後續的設計、編碼過程中依賴的基礎。我們應用迭代方法的最大目的就是穩步地改進軟體架構。

軟體架構的改進在軟體開發過程中會經歷一個振盪期，這個振盪期可能橫跨了數個迭代週期，其間的架構設計將會經歷劇烈的變化，但最後一定會趨向於平穩。

勿做過度設計

如果架構師創造的功能無法正好迎合需求或實現業務目標或不必要的特徵，則會出現過度設計的現象，這一般是因為不清楚專案需求或不確定架構的效能。為了避免出現過度設計的現象，我們需要使需求透明化。過度設計的跡象並不總是顯而易見的，但識別這些跡象對節省時間和降低成本非常重要。不需要做超出需求的設計，不需要假設不存在的極端條件做系統架構設計。

過度設計的特徵如下。

◎ 超高強度。

◎ 終極效能。

◎ 重新設計。◎ 過度合理。

過度設計的影響如下。

◎ 開發時間和成本。每個新功能都必須經過設計、研發、測試的步驟。這樣大大增加了人力和時間成本，導致專案的交付時間延長。

◎ 維護成本。過於複雜的架構設計都會導致各種問題，增加了維護成本，並且讓整個系統的維護過程變得複雜。

過度設計的原因如下。

◎ 需求透明度。如果在架構設計之初並未完全理解需求方提出的需求，或遺漏了關鍵的需求，出現誤解的可能性就會大大提高，從而導致架構設計過度。

◎ 架構效能未知。高估了產品的市場預期。