掃二維碼與項(xiàng)目經(jīng)理溝通
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問(wèn)/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
圖中分了 3 個(gè)階段：
這可以很好的表達(dá)出，從業(yè)務(wù)最開(kāi)始，到長(zhǎng)期迭代后，復(fù)雜度提升帶來(lái)的問(wèn)題。做一個(gè)相同的需求，最開(kāi)始可能
1 天就可以搞定，但長(zhǎng)期迭代后，可能要 3
天，甚至更多，這并不是開(kāi)發(fā)人員主觀上導(dǎo)致的，而是代碼狀態(tài)的維護(hù)成本太高，做到最后經(jīng)常會(huì)出現(xiàn)牽一發(fā)而動(dòng)全身。也側(cè)面抑制了業(yè)務(wù)的迭代速度。
所以對(duì)于長(zhǎng)期迭代的產(chǎn)品，切記不要簡(jiǎn)單做，否則都是給后面挖的坑。
當(dāng)然，看問(wèn)題還是要去看本質(zhì)。根據(jù)復(fù)雜度守恒定律（泰斯勒定律），每個(gè)應(yīng)用程序都具有其內(nèi)在的、無(wú)法簡(jiǎn)化的復(fù)雜度。這一固有的復(fù)雜度都無(wú)法依照我們的意愿去除，只能設(shè)法調(diào)整、平衡。而現(xiàn)在前端的復(fù)雜度拆分主要包括：框架、通用組件、業(yè)務(wù)組件和業(yè)務(wù)邏輯，如下圖所示：
上圖中可以看到，當(dāng)把框架和通用組件建設(shè)完成后，能夠承擔(dān)的復(fù)雜度基本穩(wěn)定了，未來(lái)無(wú)輪再怎么改善或者更換其他框架，也很難再去突破天花板，對(duì)業(yè)務(wù)的復(fù)雜度的改變也微乎其微了（如果你的業(yè)務(wù)經(jīng)歷過(guò)底層框架更換，你就能體會(huì)到它到底對(duì)你的業(yè)務(wù)復(fù)雜度有沒(méi)有帶來(lái)變化了）。
我們就要去思考，到底哪里還能把復(fù)雜度給降下來(lái)。換個(gè)角度，是不是可以從業(yè)務(wù)共有的 “業(yè)務(wù)邏輯” 側(cè)去進(jìn)行突破？目前發(fā)現(xiàn)的，做業(yè)務(wù)側(cè)提效的方案中，很少有從 “業(yè)務(wù)邏輯” 視角為出發(fā)點(diǎn)去做的，更多的是聚焦在場(chǎng)景化上的提效。
把視角聚焦到 “業(yè)務(wù)邏輯” 側(cè)，這里就要看所有業(yè)務(wù)中都會(huì)面臨的問(wèn)題，是什么讓業(yè)務(wù)復(fù)雜度提升上去了。這里主要存在兩點(diǎn)，如下：
?flag?? 變量的劇增：即便是自己，寫(xiě)多了這種變量，也很難清楚的知道每個(gè) ??flag?? 是干什么用的。?if/else??：??if/else?? 嵌套地獄估計(jì)在很多大型的業(yè)務(wù)產(chǎn)品中都能看到吧。還有內(nèi)部的各種邏輯判斷，如 ??isA && isB || !(isC || !isD && isE)??，完全看不懂，即便問(wèn) PD，時(shí)間久了她也不知道了。還有因此可能導(dǎo)致一些意識(shí)不到的 Bug。我們需要通過(guò)發(fā)現(xiàn)的這些問(wèn)題，來(lái)尋找合適的解決方案。
代碼層面的問(wèn)題，主要來(lái)源于 ??flag?? 變量過(guò)多，及 ??if/else?? 的嵌套及大量分支，導(dǎo)致難以修改和擴(kuò)展，任何改動(dòng)和變化都是致命的。其實(shí)這類(lèi)問(wèn)題，在設(shè)計(jì)模式中是有合適的方案——狀態(tài)模式。
狀態(tài)模式主要解決的是，當(dāng)控制一個(gè)對(duì)象狀態(tài)轉(zhuǎn)換的條件表達(dá)式過(guò)于復(fù)雜時(shí)的情況。把狀態(tài)的判斷邏輯轉(zhuǎn)移到表示不同狀態(tài)的一系列類(lèi)當(dāng)中，減少相互間的依賴(lài)，可以把復(fù)雜的判斷邏輯簡(jiǎn)化。
狀態(tài)模式是一種行為模式，在不同的狀態(tài)下有不同的行為，它將狀態(tài)和行為解耦。
從類(lèi)圖中可以看到，狀態(tài)模式是多態(tài)特性和面向接口的完美體現(xiàn)，??State?? 是一個(gè)接口，表示狀態(tài)的抽象，??ConcreteStateA?? 和 ??ConcreteStateB?? 是具體的狀態(tài)實(shí)現(xiàn)類(lèi)，表示兩種狀態(tài)的行為，??Context?? 的 ??request()?? 方法將會(huì)根據(jù)狀態(tài)的變更從而調(diào)用不同 ??State?? 接口實(shí)現(xiàn)類(lèi)的具體行為方法。
狀態(tài)模式的好處是，將與特定狀態(tài)相關(guān)的行為局部化，并且將不同狀態(tài)的行為分割開(kāi)來(lái)。這樣這些對(duì)象就可以不依賴(lài)于其他對(duì)象而獨(dú)立變化了，未來(lái)增加或修改狀態(tài)流程，就不是困難的事了。
當(dāng)一個(gè)對(duì)象的行為取決于它的狀態(tài)，并且它必須在運(yùn)行時(shí)刻根據(jù)狀態(tài)改變它的行為時(shí)，就可以考慮使用狀態(tài)模式了。
狀態(tài)機(jī)，全稱(chēng)有限狀態(tài)機(jī)（finite-state
machine，縮寫(xiě)：FSM），又稱(chēng)有限狀態(tài)自動(dòng)機(jī)（finite-state
automaton，縮寫(xiě)：FSA），是現(xiàn)實(shí)事物運(yùn)行規(guī)則抽象而成的一個(gè)數(shù)學(xué)模型，并不是指一臺(tái)實(shí)際機(jī)器。狀態(tài)機(jī)是圖靈機(jī)的一個(gè)子集。它是一種認(rèn)知論。從某種角度來(lái)說(shuō)，我們的現(xiàn)實(shí)世界就是一個(gè)有限狀態(tài)機(jī)。
有限狀態(tài)自動(dòng)機(jī)在很多不同領(lǐng)域中是重要的，包括電子工程、語(yǔ)言學(xué)、計(jì)算機(jī)科學(xué)、哲學(xué)、生物學(xué)、數(shù)學(xué)和邏輯學(xué)。有限狀態(tài)機(jī)是在自動(dòng)機(jī)理論和計(jì)算理論中研究的一類(lèi)自動(dòng)機(jī)。在計(jì)算機(jī)科學(xué)中，有限狀態(tài)機(jī)被廣泛用于建模應(yīng)用行為、硬件電路系統(tǒng)設(shè)計(jì)、軟件工程，編譯器、網(wǎng)絡(luò)協(xié)議、和計(jì)算與語(yǔ)言的研究。它是非常成熟的一套方法論。
有限狀態(tài)機(jī)包含五個(gè)重要部分：
更簡(jiǎn)潔的總結(jié)，就三個(gè)部分：
同一時(shí)刻，只可能存在一個(gè)狀態(tài)。例如，人有 “睡著” 和 “醒著” 兩個(gè)狀態(tài)，同一時(shí)刻，要么 “睡著” 要么 “醒著”，不可能存在 “半睡半醒” 的狀態(tài)。
邏輯學(xué)中說(shuō)，現(xiàn)實(shí)生活中描述的事物都可以抽象為命題。命題本質(zhì)上就是狀態(tài)機(jī)的 State，Event 就是命題的條件，通過(guò)命題和條件推導(dǎo)過(guò)程。而 Transition 就是命題推導(dǎo)完成的結(jié)論。
所以當(dāng)我們拿到需求的時(shí)候，首先要分離出哪些是已知的命題（State），哪些是條件（Event），哪些是結(jié)論（Transition）。而我們要通過(guò)這些已知命題和條件，推導(dǎo)出結(jié)論的過(guò)程。
fetch(url).then().catch()
有限的一組狀態(tài)：
初始狀態(tài)：
有限的一組最終狀態(tài):
有限的一組事件：
?Idle?? 狀態(tài)只處理 ??FETCH?? 事件?Pending?? 狀態(tài)只處理 ??RESOLVE?? 和 ??REJECT?? 事件由事件驅(qū)動(dòng)的一組狀態(tài)轉(zhuǎn)移關(guān)系:
下面采用一個(gè)小需求來(lái)對(duì)比一下區(qū)別。
根據(jù)輸入的關(guān)鍵字進(jìn)行搜索，并將搜索結(jié)果顯示出來(lái)。如下圖所示：
根據(jù)關(guān)鍵字拿到請(qǐng)求結(jié)果，再將結(jié)果塞回去就行了，代碼如下：
function onSearch(keyword) {
fetch(SEARCH_URL + "?keyword=" + keyword).then((data) => {
this.setState({ data });
});
}看似幾行代碼就把這個(gè)需求搞定了，但其實(shí)還有一些其他問(wèn)題要處理。如果接口響應(yīng)比較慢，則需要給一個(gè)用戶預(yù)期的交互，如 Loading 效果：
function onSearch(keyword) {
this.setState({
isLoading: true,
});
fetch(SEARCH_URL + "?keyword=" + keyword).then((data) => {
this.setState({ data, isLoading: false });
});
}還會(huì)發(fā)生出請(qǐng)求出錯(cuò)的情況：
function onSearch(keyword) {
this.setState({
isLoading: true,
});
fetch(SEARCH_URL + "?keyword=" + keyword)
.then((data) => {
this.setState({ data, isLoading: false });
})
.catch((e) => {
this.setState({
isError: true,
});
});
}當(dāng)然，不能忘記把 Loading 關(guān)掉：
function onSearch(keyword) {
this.setState({
isLoading: true,
});
fetch(SEARCH_URL + "?keyword=" + keyword)
.then((data) => {
this.setState({ data, isLoading: false });
})
.catch((e) => {
this.setState({
isError: true,
isLoading: false,
});
});
}我們每次搜索時(shí)，還需要把錯(cuò)誤清除：
function onSearch(keyword) {
this.setState({
isLoading: true,
isError: false,
});
fetch(SEARCH_URL + "?keyword=" + keyword)
.then((data) => {
this.setState({ data, isLoading: false });
})
.catch((e) => {
this.setState({
isError: true,
isLoading: false,
});
});
}這就結(jié)束了么，是不是我們把所有的 Bug 都考慮進(jìn)去了？并沒(méi)有。當(dāng)用戶在等待搜素請(qǐng)求的時(shí)候，不應(yīng)該再去搜索，所以搜索結(jié)果返回前，禁止再次發(fā)送請(qǐng)求：
function onSearch(keyword) {
if (this.state.isLoading) {
return;
}
this.setState({
isLoading: true,
isError: false,
});
fetch(SEARCH_URL + "?keyword=" + keyword)
.then((data) => {
this.setState({ data, isLoading: false });
})
.catch((e) => {
this.setState({
isError: true,
isLoading: false,
});
});
}可以看到，應(yīng)用的復(fù)雜度在不斷變大，可能你經(jīng)歷的場(chǎng)景比這個(gè)小示例還要復(fù)雜的多的多。如果因?yàn)樗阉鹘涌谔貏e慢，用戶希望有一個(gè)中斷搜索的功能，那么新的需求又來(lái)了：
function onSearch(keyword) {
if (this.state.isLoading) {
return;
}
this.fetchAbort = new AbortController();
this.setState({
isLoading: true,
isError: false,
});
fetch(SEARCH_URL + "?keyword=" + keyword, {
signal: this.fetchAbort.signal,
})
.then((data) => {
this.setState({ data, isLoading: false });
})
.catch((e) => {
this.setState({
isError: true,
isLoading: false,
});
});
}
function onCancel() {
this.fetchAbort.abort();
}不能落下對(duì) catch 的特殊處理，因?yàn)橹袛嗾?qǐng)求會(huì)觸發(fā) catch：
function onSearch(keyword) {
if (this.state.isLoading) {
return;
}
this.fetchAbort = new AbortController();
this.setState({
isLoading: true,
isError: false,
});
fetch(SEARCH_URL + "?keyword=" + keyword, {
signal: this.fetchAbort.signal,
})
.then((data) => {
this.setState({ data, isLoading: false });
})
.catch((e) => {
if (e.name == "AbortError") {
this.setState({
isLoading: false,
});
} else {
this.setState({
isError: true,
isLoading: false,
});
}
});
}
function onCancel() {
this.fetchAbort.abort();
}最后還要處理沒(méi)有值的情況：
function onSearch(keyword) {
if (this.state.isLoading) {
return;
}
this.fetchAbort = new AbortController();
this.setState({
isLoading: true,
isError: false,
});
fetch(SEARCH_URL + "?keyword=" + keyword, {
signal: this.fetchAbort.signal,
})
.then((data) => {
this.setState({ data, isLoading: false });
})
.catch((e) => {
if (
e &&
e.name == "AbortError"
) {
this.setState({
isLoading: false,
});
} else {
this.setState({
isError: true,
isLoading: false,
});
}
});
}
function onCancel() {
if (
this.fetchAbort.abort &&
typeof this.fetchAbort.abort == "function"
) {
this.fetchAbort.abort();
}
}僅僅這么簡(jiǎn)單的一個(gè)小需求，從開(kāi)始幾行代碼就可以完成，到最終判斷各種邊界完成的代碼，對(duì)比一下，如下圖所示：
可以看到，這種包含各種 ??flag?? 變量和嵌套著各種 ??if/else?? 的代碼，會(huì)越來(lái)越難維護(hù)，所有的邏輯只存在于你的腦子里。當(dāng)你寫(xiě)測(cè)試的時(shí)候必須從頭再梳理一遍代碼邏輯，才能寫(xiě)出來(lái)。
由于業(yè)務(wù)的高頻變化，很多業(yè)務(wù)開(kāi)發(fā)人員是不寫(xiě)單元測(cè)試的，因?yàn)槌杀咎咛撸@也導(dǎo)致了交接代碼時(shí)，別人去理解你的代碼是一件很困難的事。寫(xiě)久了，你自己都可能讀不懂代碼里面的邏輯了。
這樣會(huì)導(dǎo)致：
看一下我們用狀態(tài)機(jī)的做法。記住流程：梳理出有哪些狀態(tài)，每個(gè)狀態(tài)有哪些事件，經(jīng)歷了這些事件又會(huì)轉(zhuǎn)換到什么狀態(tài)。
下面是用 XState 狀態(tài)機(jī)工具的 JSON 描述：
{
initial: "空閑",
states: {
空閑:{
on:{
搜索: '搜索中'
}
},
搜索中:{
on:{
搜索成功: '成功',
搜索失敗: '失敗',
取消: '空閑'
}},
成功:{
on:{
搜索: '搜索中'
}},
失敗:{
on:{
搜索: '搜索中'
}}
},
}沒(méi)錯(cuò)，就這幾行代碼就描述清楚所有的關(guān)系了。并且，可以把它可視化出來(lái)，如下圖所示：
可以看到狀態(tài)之間表達(dá)的非常清晰，結(jié)合到 View 中，也不需要再去編寫(xiě)復(fù)雜的 ??flag?? 及 ??if/else?? 了，View 中只需要知道當(dāng)前是什么狀態(tài)，已及將事件發(fā)送到狀態(tài)機(jī)就可以了，其他什么都不需要做。在新增或者修改需求的情況下，只需要對(duì)狀態(tài)進(jìn)行新增或者編排就可以了。
而且可視化后，有以下變化：
另一個(gè)很大的問(wèn)題是解決協(xié)作問(wèn)題，主要包括：
這里就需要引用一個(gè)可視化的概念了。可視化，是利用人眼的感知能力對(duì)數(shù)據(jù)進(jìn)行交互的可視表達(dá)以增強(qiáng)認(rèn)知的技術(shù) 。
所以很大程度上，可視化可以解決一大部分協(xié)作問(wèn)題。當(dāng)然，必須要確定把什么進(jìn)行可視化才是有意義的。
要想可視化，狀態(tài)工具就需要具備可序列化的能力。這也是 Redux 之類(lèi)的狀態(tài)管理工具缺乏的，主要有以下幾方面問(wèn)題：
回到狀態(tài)機(jī)。你單純用狀態(tài)機(jī)去寫(xiě)代碼，需求數(shù)量上去了，狀態(tài)多了，會(huì)面臨 “狀態(tài)爆炸” 問(wèn)題，依然很難維護(hù)，且閱讀成本巨大。
當(dāng)然，這個(gè)場(chǎng)景其實(shí)很早之前就有人考慮到了，1987 年，Harel 就發(fā)表論文，解決復(fù)雜狀態(tài)機(jī)可視化的問(wèn)題，在狀態(tài)機(jī)的基礎(chǔ)上進(jìn)一步增強(qiáng)，提出狀態(tài)圖的概念。
隨后，由微軟、IBM、惠普等多家公司，從 2005 到 2015 年花了 10 年時(shí)間制定了規(guī)范，并推出了 W3C 的 State Chart XML (SCXML) 規(guī)范，至此基本穩(wěn)定，各家編程語(yǔ)言也基于此規(guī)范進(jìn)行了狀態(tài)圖的封裝。
看一下，狀態(tài)機(jī)、狀態(tài)圖和手寫(xiě)代碼復(fù)雜度的對(duì)比，如下圖所示：
從圖中可以看到：
前面給狀態(tài)機(jī)畫(huà)的圖，就是狀態(tài)圖。
狀態(tài)圖大概長(zhǎng)這樣，如下圖所示：
主要包括：
即使?fàn)顟B(tài)非常復(fù)雜，也可以通過(guò)狀態(tài)圖的模式進(jìn)行聚合、分組、細(xì)化，還可以通過(guò) Actor 模型進(jìn)行劃分，不會(huì)發(fā)生 “狀態(tài)爆炸” 現(xiàn)象。
目前對(duì)項(xiàng)目需求的描述主要有：
而這兩個(gè)，在描述頁(yè)面行為上都不夠細(xì)致，PRD 幾乎不會(huì)去描述過(guò)于細(xì)節(jié)的交互行為，設(shè)計(jì)稿大概率也不會(huì)（因?yàn)闃I(yè)務(wù)交付周期上不允許在這上面花費(fèi)太多的時(shí)間）。而對(duì)于這些不清楚的、模糊的點(diǎn)，就帶來(lái)了后面的問(wèn)題，針對(duì)于這些細(xì)節(jié)點(diǎn)，各個(gè)角色之間的溝通成本和拉通成本。
還有一個(gè)很?chē)?yán)重的問(wèn)題，就是同步問(wèn)題。很多時(shí)候在開(kāi)發(fā)過(guò)程中，進(jìn)行需求變動(dòng)，而大多數(shù)情況下，這些變動(dòng)不會(huì)重新對(duì) PRD 和設(shè)計(jì)稿進(jìn)行修改，不同角色之間去對(duì)焦及未來(lái)回顧，都是問(wèn)題。
而如果你使用狀態(tài)機(jī)開(kāi)發(fā)，那這兩個(gè)問(wèn)題就可以迎刃而解。狀態(tài)機(jī)方式，要求你在開(kāi)發(fā)之前必須把所有可能的狀態(tài)都羅列出來(lái)，狀態(tài)之間的關(guān)聯(lián)關(guān)系必須描述清晰。基于生成的狀態(tài)圖，是可以完全表達(dá)清楚所有的狀態(tài)交互及變化，且它是來(lái)源于代碼的，所以它是實(shí)時(shí)同步的，你代碼中怎么運(yùn)行的，這個(gè)狀態(tài)圖就是怎么表達(dá)的。
回到前面說(shuō)的，與不同角色協(xié)作的問(wèn)題上。有了狀態(tài)圖的加持，會(huì)發(fā)生什么變化：
除了解決復(fù)雜度的問(wèn)題，基于狀態(tài)機(jī)的特性，還可以帶來(lái)一些新的思路，如用戶操作鏈路追蹤和分析。
目前，針對(duì)于分析用戶操作鏈路的方法，主要是在頁(yè)面中的可操作標(biāo)簽上進(jìn)行埋點(diǎn)，如，Button、Tab Item 等。有手動(dòng)埋點(diǎn)和自動(dòng)埋點(diǎn)。
無(wú)論使用哪種埋點(diǎn)，都存在 回放噪音 的問(wèn)題。
如，上報(bào)信息里包含，“查看詳情” 按鈕的操作，那么對(duì)應(yīng)的 “詳情對(duì)話框” 一定會(huì)出來(lái)么？這個(gè)時(shí)候鏈路回放，只能去猜測(cè)，認(rèn)為點(diǎn)擊了這個(gè)按鈕，就意味著這個(gè)對(duì)話框出來(lái)了。其實(shí)是不準(zhǔn)確的。
如果，頁(yè)面上新增加了一個(gè)功能，要判斷這個(gè)新功能用戶的使用量，及用戶做了哪些操作才找到這個(gè)新功能。通過(guò)這個(gè)數(shù)據(jù)來(lái)判斷新的交互設(shè)計(jì)是否存合理。在這種不精準(zhǔn)數(shù)據(jù)及 “噪音” 的回放中也是不準(zhǔn)確的。
同樣，分析頁(yè)面中的哪些部分是高頻操作，也有類(lèi)似的問(wèn)題。
狀態(tài)機(jī)做這種用戶鏈路分析，是天然合適的。因?yàn)橛脩舻乃胁僮鳎行袨?，本質(zhì)上就是 “狀態(tài)在接收了什么事件，要變換到什么狀態(tài)” 上的過(guò)程。這是在 View 上埋點(diǎn)的方式缺乏的。
我們只需要在每次 “狀態(tài)” 發(fā)生轉(zhuǎn)換時(shí)，把狀態(tài)圖數(shù)據(jù)上報(bào)到分析平臺(tái)就可以。完全可以基于狀態(tài)的方式， 1:1 的回放用戶操作鏈路。
最后，總結(jié)一下?tīng)顟B(tài)機(jī)方式帶來(lái)的好處和不足。
狀態(tài)機(jī)已經(jīng)發(fā)展幾十年了，前面也說(shuō)過(guò)，在非常的多場(chǎng)景有使用，像電子、嵌入式、游戲、通訊等領(lǐng)域。那為什么前端上使用較少呢（限定國(guó)內(nèi)）？
除了上面列出的 “帶來(lái)的一些問(wèn)題” 中的一些點(diǎn)，我覺(jué)的還有以下問(wèn)題導(dǎo)致的：
?if/else/switch?? 來(lái)解決問(wèn)題。?flag?? 變量和布爾值中蔓延。就像溫水煮青蛙，溫水中的青蛙不會(huì)注意到溫度的緩慢升高一樣，開(kāi)發(fā)人員也不會(huì)注意到復(fù)雜度的蔓延。在一些小的系統(tǒng)中運(yùn)行的很好，但隨著系統(tǒng)的迭代和變大，一個(gè)個(gè)凌亂的 ??if/else/switch?? 語(yǔ)句，它修改了各種變量的狀態(tài)，以試圖維持它們的一致性。就好像你不需要狀態(tài)機(jī)，直到為時(shí)已晚。任何解決方案都不能解決一切問(wèn)題，一定要找到它適合的場(chǎng)景。不過(guò)，現(xiàn)階段，狀態(tài)機(jī)確實(shí)是我能看到的，解決復(fù)雜業(yè)務(wù)邏輯最好的工具。
如果文中說(shuō)的問(wèn)題也發(fā)生在你身邊，且無(wú)法徹底解決，那推薦你可以嘗試一下，或許會(huì)有驚喜。
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問(wèn)/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動(dòng)版官網(wǎng)