簡介：分析與設計這兩個詞我們平時經常聽到，也經常講，那么分析與設計的本質究竟是什么呢？到底要分析什么？又到底要怎樣去設計？這3個問題如果平時沒有一些積累，突然被問到這些，一時也會顯得不知所措。接下面在第一部分中回答分析與設計的本質，只有清楚了本質，那就知道要怎么分析與設計，因此在第二、第三部分具體講軟件的分析與設計方法，最后一部分講述個人的一些思考。

作者 | 不拔
來源 | 阿里技術公眾號

分析與設計這兩個詞我們平時經常聽到，也經常講，那么分析與設計的本質究竟是什么呢？到底要分析什么？又到底要怎樣去設計？這3個問題如果平時沒有一些積累，突然被問到這些，一時也會顯得不知所措。接下面在第一部分中回答分析與設計的本質，只有清楚了本質，那就知道要怎么分析與設計，因此在第二、第三部分具體講軟件的分析與設計方法，最后一部分講述個人的一些思考。

一 分析與設計的本質

1 分析的本質

"分析"，由"分"和"析"兩個字組成，"分"是分開的意思，這個比較好理解；"析"，左"木"又"斤"，"斤"通"金"，即把木劈開。延伸來講，分析的本質即是洞察出事物的內部要素，包含組成結構、運行機制等。平時開發同學經常看到"需求分析"、"軟件分析"、"架構分析"這些詞，以"需求分析"為例，分析階段要了解的內容有：需求背景、需求目的、需求目標、利益相關方、業務流程、業務依賴方、業務指標。分析的目的是為了找出隱藏在現象背后的本質，考察的是否對事物打散認識，深入到事物內部去看問題，就像我們高中學習化學一樣，分子結構決定表現現象。在實際軟件開發中，產品同學提的一個需求，有時它就包含了技術解決方案，只有深入分析之后，開發同學有可能提出更為合理的技術解決方案，否則只是就事論事的解決問題，在新的場景下，現有的解決方案又有問題。

有一個段子說一個人去做美容，剛來的一個醫生不懂人體結構，結果一刀下去，把大動脈劃破了，結果人失血過多死了，"美死你了"這個詞就是這么來的。段子歸段子，這也說明如果分析沒有做得相當充分，也即缺乏對事物的了解，往往做事會出錯。

2 設計的本質

"設"和"計"兩個字都有"言"字旁，并且右邊有"多"的意思，如"十"、"又"，即集多家之言。延伸來講，設計的本質即是對方案優中選優，包含了對方案設計的思考、取舍和權衡。只有了解了當時的設計思想才會比較快掌握是怎樣實現的，在軟件編碼實現層面上，我們有時看到一些比較難理解的邏輯，這些邏輯就是當時設計的產物，在當時是為了解決特定的問題產生的。

一個好的設計凝集了設計者的思想和心血，比如經典的文學著作，里面有優秀的寫作手法；比如經典的影視橋段，里有精彩的故事情節；比如巧奪天工的建筑設計，里面有豐富的寓意。相反一個糟糕的設計，輕則讓人迷惑，看不懂為什么要這么設計，影響美觀、使用，重則產生事故，在《復雜系統的產品設計與開發》一書中，作者舉了一個輪船的例子，當時建造輪船提了很多要求，在面對這么復雜的系統時，設計沒有考慮周全，結果設計出來的輪船下水就沉了。

拉曼《UML和模式應用》一書中，對分析與設計概括成：分析是做正確的事；設計是正確地做事，之前看到這2句話挺迷糊，并沒有領會到這兩句的精髓，后面經歷了一些系統的設計之后，重新去看發現這2句話高度概括出了分析與設計的本質內涵。

二 到底要分析什么

1 分析全景圖

分析的起點是問題本身，比如現象、痛點、挑戰、價值等，從這些基礎點去分析，如分析一個業務時，我喜歡從業務愿景和業務目標去看這個業務有哪些利益相關者，也即有哪些角色在使用這個業務，從這些利益相關者的角度去思考他們的本質訴求，正是他們的訴求構成了我們要做什么的輸入，不管外部怎么變化，他們的本質訴求是不變的，如對于消費者來講，他們的訴求是花最短的時間、最少的錢、更好的體驗買到心儀的商品；對于商家來講，他們的訴求是怎么賣出更多的貨、怎樣獲得更大的利潤。反而如果我們不去關注利益關注點的本質訴求，而只是自己憑空想出來的，自以為有價值，結果一落地就出現了問題。

當明確了要做什么(What)之后，接下來就要思考業務流程以及業務中包含的要素(業務對象)、業務模型以及業務能力(How)，實際上這部分就是提供一個解決方案去實現前面提到的訴求。分析的階段，一定要非常細，在軟件分析中，有一些分析的工具幫助我們更好地理解事物本身，具體地在下一節中講到。分析的產物是業務模型和業務能力地圖，通過業務模型可以看出業務是什么、有什么，通過業務能力地圖可以看出具體的業務能力有哪些，可以支撐哪些業務場景。

分析往上看一層，就是要分析商業價值鏈和商業模式，雖然這一塊并不是開發同學負責的范疇，了解一些還比較好，能讓我們對業務有更深刻的認識，商業模式決定商業結構，商業結構決定交易結構，交易結構決定業務組成結構。利益相關者也是從業務組成結構中推導出來的，這一部分是最頂層的分析，分析業務的可行性，也即我們常說的Why。

2 具體分析方法

在實際中，我們會看到各種各樣的分析方法，這些方法本身并不重要，重要的是它能給我們帶來什么的幫助，為什么需要它，個人的觀點是分析方法不要貪多，真正融匯到實際中，有那么1、2個方法就足已，不要迷失在各種各樣的分析方法中，真正還是要了解分析的本質是什么，在第一部分中，已經提到分析的本質是要洞察出事物的組成，包含組成結構和運行機制，你再去看各種各樣的分析方法，它們都是為了找出事物的組成結構和運行機制。如黃金圈分析方法，它就包含了三層（Why、What、How），分析事物不斷從宏觀到微觀、從目的到實現；再比如5W2H，真正的把一件事分析得非常仔細，什么人在什么時間什么地點因為什么做了什么事。

再回到軟件分析本身，之前在大學里我們我們學習軟件工程、UML等課程，由于當時并沒有多少實際的研發、設計的經驗，學習的時候覺得這些內容比較空洞，反正老師讓我們這樣做就這樣做，缺乏對這些UML圖的理解。

• 用例圖：用戶對系統最直接的交互，要表達出用戶需要怎樣的能力去滿足他們的訴求，它的關鍵是用戶、目的、價值。

• 活動圖：用戶在某一類場景中，要表達出業務流程是怎樣的，它的關鍵是業務活動、流程交互（僅是業務層面，不是系統流程）。

• 模型圖：屏蔽業務細節，抽象出業務關鍵要素以及它們之間的聯系，它的關鍵是業務抽象出來的實體以有實體之間的關聯。

我們現在反過來去想想當時學習的UML課程，里面各種圖都是為了幫助我們更好去認識、理解項目需求，畫這些圖并非是做做樣子，而是真正地挖掘出業務能力有哪些、系統能力有哪些、業務模型是怎樣的、要有哪些對象、對象之間的關系是怎樣的。在實際工作中，有些人在分析階段在這一塊落實得并不那么好，其實問幾個問題很容易暴露出來，比如設計的類圖的出發點是什么、這個類的職責為什么有這些、這個職責為什么在這個類而不是在另外一個類中。如果我們分析階段做得不扎實，設計階段的輸入就會比較少，或者是淺層次的輸入，設計的質量也不會高，因為并沒有真正洞察出問題。

3 1個分析案例

用2.1節中提到的分析方法，我當時分析一個分銷業務也是用了上面的方法，從下面這張圖中可以看出業務發展思路是怎樣，用了幾個關鍵詞進行概括：打基礎、拓渠道、夯能力、搭體系、數據化。當有了這些認識之后，再去推導技術側要做哪些就比較容易，以拓展渠道為例，當多個渠道接入進來時就暴露了一些問題，比如答疑成本比較高，因此就有一個重要的方面就是渠道接入保障，怎么減少渠道接入成本、答疑成本就是技術側要思考的問題。

三 到底要怎樣設計

1 設計全景圖

如果說分析階段是把事物打散，那么設計就是把打散的事物更好地組合起來。設計最為核心的是從分析中提煉出問題，即定義技術問題，這個是非常難的，比如你覺得某個設計不好，但又講不出來為什么不好，說明對問題的理解程度還不高。常見的技術問題有：性能、擴展性、穩定性、安全、效能、體驗、成本、數據一致性等。

當定義好了技術問題，接下來就要調研業界對這個問題有哪些方案，每個方案的優缺點是什么，比如數據一致性，有事務型解決方案，也有補償型解決方案，結合業務本身去做選擇，這個選擇就包含了決策，決策就意味著取舍和平衡，并不是隨意的決策，而是有決策的依據來支撐，比如經驗、原則、數據等。

設計是包含原則的，這些原則應該是大家都去遵循的，比如分層原則，這個在軟件設計中非常常見，原則是平時大家開發過程經驗的結晶，以分層原則為例，可以深入思考，為什么要分層、分層解決了什么問題、要分多少層、如何去分層，只有深入思考了這些原則，在新的場景中再去做設計時，就會得心應手，而不是僵硬地去套用分層原則。

2 設計原則

設計原則，每個設計者有自己的理解，很難有統一的設計原則，只能在局部上達成一致，比如分層原則，這個大家比較容易達成的，設計原則應該是一系列的原則組成集合，并非是單一。設計原則是在大量實踐過程中沉淀出來的，我更想說的是如果你對看到的某些原則能結合自己的經歷講得出來，說明你是有過真正實踐和思考的，否則這些設計原則也僅僅是一些文字，轉化不了設計經驗和設計能力，這里列出一些常用的設計原則。

• 系統性原則
• 抽象分層原則
• 領域原則
• 復用原則
• 簡易原則
• 成本效率原則
• 正交原則
• 擴展原則
• 演進原則

3 2個設計案例

對于上面提到的9個設計原則，這里主要聊的是系統性原則和正交原則，系統性原則是站在全局上思考系統之間的交互，這個是非常重要的，相當于是指明燈，當看懂了整個系統未來的樣子，在當下每一步的執行都清楚知道是為了什么。反之沒有這個系統性原則，所做的事都只是關注點狀事情，不成體系。以2.3節中的例子來講，當分析出來要做的事情后，如下圖畫出系統架構圖。從系統架構圖中可以看出系統之間的交互是怎樣的、鏈路邏輯是怎樣的（注：逆向鏈路沒有表達出來）。

我們在數學中學習過正交，最簡單的理解是兩條線是垂直的，在軟件中我們看到一些邏輯中包含了很多的邏輯，每次修改的時候，改了這個邏輯結果影響了另外一個邏輯，說明我們的邏輯耦合度比較高。正交原則即是分離出不同的變化點，讓變化自治，即每個變化只影響自身，不會影響到其它的變化點。平時我們寫代碼中有兩種場景影響正交：代碼重復和關系依賴，對于重復的代碼可以抽取出來，對于依賴的部分，可以抽象一層防腐層出來。

舉一個正交的例子，假如有一個需求是：查找員工名為John的員工，這個代碼可以很快寫出來，但細細想想的它的變化點，至少可以想到下面3個變化點：

• 查找的內容會變，不一定按照名字來查，比如按照員工工號來查；

• 查找的對象會變，不一定查員工，還有可能查學生；

• 查找的規則會變，不一定是待值查找，還有可能是范圍查找，比如查找年齡在20至30的員工。

當想到了這些變化，重新設計后的效果就會不一樣了，當面臨業務場景變化的時候，可以做到最少的改動，這也即是設計能夠降本增效的原因。

四 分析與設計的思考

1 衡量標準

衡量分析與設計的標準是比較難的，一般是從一些大的原則去看，比如復雜性、開放性等，但又很難有一個量化的指標去衡量，到底復雜度有多高、開放性有多底。真正衡量好壞只有通過比較才比較好判斷，比如多個方案之間的比較，這個是比較容易衡量誰好。因此我們需要多去看別人是怎么設計的，有哪些好的設計思想值得借鑒，多吸收好的設計思想、設計案例。

做設計最怕是閉門造車，結果設計出來的東西不能夠很好地解決實際問題。個人的經驗是去看業界的方案，看看它們是怎么設計的，各自的特點，比如數據不一致性的問題，有很多種設計方案來解決，有的方案對業務入侵比較大，需要改造很大，能不能無入侵業務呢？阿里提出了TXC解決方案，這個設計就非常好，使用者只有打上一個注解就ok，對業務改造沒有什么成本，這也即是前面提到的簡易設計原則。

2 虛實結合

提到分析與設計，很多人覺得很虛，的確，在我剛工作前3年，也覺得這個非常虛，這個不就是畫畫圖嘛，后面發現還真不是這么一回事。印象最深的一件事，當時在滴滴，我的主管給我們展示了營銷系統未來我們要做的事，用了一張系統架構圖非常體系地講出來，知道未來我們要做成什么樣子，當前我們處在什么位置上，那段時間我們過得非常充實，知道我們在做什么、要做什么，1年半以后我們把當時那張系統架構圖上的事情都完成了，回過來頭來看，如果沒有當時的指引，每天還是做著需求，來一個需求做一個需求，這也即是最開始做事沒啥動力，沒看到目標。

當設計的內容確定之后，最為重要的就是落實，這個過程是經驗的積累，在實踐的過程中會遇到一些問題，比如發放優惠券的過程中怎么扣庫存、怎么保持事務一致性，技術難度的問題，我聽一個人講過一句話：要么沒看到問題；要么回避問題，在實際中，我們會遇到各種各樣的問題，只是我們把它忽略掉了，到最后說這個事技術上沒復雜度。我經常分享的一個觀點是往上抽象看2層，或許你的設計方案會變。架構設計是需要大量的實實在在的經驗，不是簡單地畫畫架構圖就行了，需要在實踐中反復檢驗，再去指導下一次更好地設計，我欣賞的一句話是：將虛的事情做實。

3 將經驗轉化成能力

當我們有一些分析設計經驗之后，更進一步地要轉化成設計能力，設計能力是抽象的，需要在實際中得到檢驗。就像在第三部分講到的設計，它不像分析那么很好地講出具體的方法出來，設計本身是凝聚了思想、心血在里面，同時設計是一種藝術，具有高度的靈活性，因此很難講出具體的設計方法，也不會有統一的方法，有靈活性一定不是具體的，所以這部分需要在大量的實踐基礎上，提煉出設計原則，將其轉化成設計能力。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的软件分析与设计：分析什么？如何设计？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。