分析與設計這兩個詞我們平時經常聽到，也經常講，那麼分析與設計的本質究竟是什麼呢？到底要分析什麼？又到底要怎樣去設計？這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 將經驗轉化成能力
當我們有一些分析設計經驗之後，更進一步地要轉化成設計能力，設計能力是抽象的，需要在實際中得到檢驗。就像在第三部分講到的設計，它不像分析那麼很好地講出具體的方法出來，設計本身是凝聚了思想、心血在裡面，同時設計是一種藝術，具有高度的靈活性，因此很難講出具體的設計方法，也不會有統一的方法，有靈活性一定不是具體的，所以這部分需要在大量的實踐基礎上，提煉出設計原則，將其轉化成設計能力。
五 招聘
阿里巴巴國際化中臺跨境平臺團隊在招人，期待您的加入，請投遞簡歷至 [email protected] 。
Redis入門及實戰
本課召集高校、業界及阿里雲的知名Redis專家共同出品。不僅會系統性地介紹Redis的整體架構及在多種場景下的最佳實踐經驗，而且會揭秘阿里雲Redis開發規範和運維解法；你還將在講師的帶領下一起構建秒殺搶購與疫情播報應用，完成基於Redis的開發實操。進階課程包含了企業版Redis（Tair）的場景開發和使用案例，將第一次系統性地講述Redis如何在超大規模應用場景下做到極致最佳化。點選閱讀原文檢視詳情。
關鍵詞
問題
方案
就是
經驗
結構