轉(zhuǎn)行前端該怎么開始？

跟著互聯(lián)網(wǎng)開展，互聯(lián)網(wǎng)的體系越多越多，越來越雜亂，用戶不能滿意基本功用的需求，對互聯(lián)網(wǎng)體會要求越來越高，客戶端與服務(wù)器的交互不在是簡略頁面和頁面的交互，而變?yōu)轫撁婧晚撁?程序+數(shù)據(jù)的交互，其間完成與客戶交互和體會的程序就是Web前端工程師完成的，這時Web前端工程師就誕生了，跟著用戶對體會和交互要求越高，體系功用越雜亂，Web前端工程師的崗位就越重要。

對于前端日常工作來說，寫代碼可能占去了大部分時間，但當(dāng)我們回頭看以前代碼的時候，我們往往會覺得以前自己寫的很糟糕。

或者在向前看看資歷比較老的同事，往往都可以寫出比較清晰的代碼，有一種莫名的優(yōu)雅。

也許通過時間的歷練，在幾年之后自己也可以達(dá)到對方的水平，但是這個時間太久。

可不可以總結(jié)出一些可以復(fù)制的方法、套路，讓新人也能盡早寫出一套漂亮的代碼？

讓我們來看看前端老司機(jī)是怎么做的吧？

現(xiàn)狀

我們往往都會陷入這樣一種循環(huán)，在拿到需求文檔時候，我們會大致看一下，感覺開發(fā)上沒有什么太大的問題，然后就看看交互、UI 稿上有哪些頁面，接下來就開始著手寫了。

在寫代碼的過程中，我們也許會發(fā)現(xiàn)有些實現(xiàn)不合理的地方，這時我們會稍微動一下我們的大腦，然后抽象一下流程和模塊，重構(gòu)一下部分代碼。遇到簡單點的情況，我們發(fā)現(xiàn)加個參數(shù)傳過去做一下判斷也能實現(xiàn)，于是我們也就這么做了。

開發(fā)完后，我們會覺得比較滿足，代碼在腦中的邏輯比較清晰，里面也許有些地方寫的不太妥當(dāng)，但是也無妨吧。

然后項目就開始測試了，QA 會針對各種邊界問題給我們提 bug，在改 bug 的過程中我們痛苦不堪，之前的代碼邏輯變得支離破碎，我們不得不為了各種 bug 去為代碼修修補補，方法的參數(shù)加了一個又一個，邏輯里的條件判斷加了又加。往往到這個時候，我們開始對 QA 提出的 bug 表示質(zhì)疑，我們會用“現(xiàn)在的表現(xiàn)是符合邏輯的”，“這種情況沒問題”等等這樣的說辭來避免對代碼的更改。

過去幾個月之后，我們接到一個需求，要對這部分代碼增加幾個新功能，翻開代碼的時候，整個人都崩潰了。以前代碼的邏輯自己早就忘記了，面對自己已經(jīng)看不懂的代碼，我們會問“這個方法什么意思？為什么邏輯這么復(fù)雜？”，“代碼在不同頁面之間跳來跳去，他們的邏輯到底是什么樣的？”，“為什么會有這么多標(biāo)識位，他們都是干嘛的？”。注釋什么的是不存在的，即使存在，也不明白在講些什么。

在經(jīng)歷過閱讀源碼的痛苦過程之后，我們看了看排期，嗯。。。還有 30% 的 buffer，于是我們決定把這部分代碼重寫掉，然后再重復(fù)這個痛苦的循壞。

那么我們應(yīng)該如何從這個循環(huán)里跳出來呢？

對比

我們相比一下后端，會發(fā)現(xiàn)他們在寫代碼之前都會做方案設(shè)計。方案設(shè)計是軟件工程里的一個最佳實踐，通常做技術(shù)方案的過程中會體現(xiàn)出軟件整體的架構(gòu)，當(dāng)對核心流程梳理完成之后，最后基本都能落實到代碼上。也就是說好的技術(shù)方案能體現(xiàn)出最后代碼的邏輯，通過看方案就能知道代碼怎么寫。這樣就防止了在寫代碼過程中邊寫邊改，最后導(dǎo)致代碼結(jié)構(gòu)混亂的問題。

但是我們嘗試按照后端的方法來做方案設(shè)計發(fā)現(xiàn)根本寫不出來什么內(nèi)容：

• 后端的流程圖是系統(tǒng)間交互的流程，而我們大都數(shù)場景下只需要和一個后端交互

• 后端需要列舉出來數(shù)據(jù)庫表結(jié)構(gòu)，而我們都是把數(shù)據(jù)丟給后端

• 后端有業(yè)務(wù)模型，而對我們來說，從后端拿數(shù)據(jù)就行了

• 后端有核心業(yè)務(wù)流程，而我們調(diào)用他們 API 就行了

從上面我們可以看出，前端只運行在瀏覽器里，業(yè)務(wù)上只和后端有交互，而且 API 都是后端定好的，所以按照后端方案設(shè)計的套路，前端是寫不出來什么東西的。

所以我們會發(fā)現(xiàn)，我們大多數(shù)設(shè)計文檔都是偏 Node 層的東西，因為我們往往都是按照后端設(shè)計方案的模式去做的，但是瀏覽器內(nèi)部運行的代碼卻沒有文檔去描述。

分析

這時候我們要重新審視方案設(shè)計的套路，來發(fā)現(xiàn)前后端的不同：

• 業(yè)務(wù)分析

• 業(yè)務(wù)模型

• 核心流程

• 邏輯架構(gòu)、類圖、部署圖

• 接口

• 實施方案

• 風(fēng)險控制

業(yè)務(wù)分析與業(yè)務(wù)模型可能前后端都是一致的，畢竟我們是解決同一個業(yè)務(wù)問題。但其中也有稍許差別，前端有些數(shù)據(jù)不是從后端獲取的，或者說不一定非要從后端獲取，這點我們需要在做設(shè)計的時候考慮進(jìn)去，比如同樣是獲取地理位置，我們可以通過 GPS 也可以通過訪問后端服務(wù)通過 IP 地址來判斷，google 甚至有通過 WIFI 唯一識別碼來定位的。

前后端對于「核心流程」的定義也不同，對于后端來說核心流程是數(shù)據(jù)的產(chǎn)生、流轉(zhuǎn)、消費，但是提到流程，在前端來說更多的是頁面的流轉(zhuǎn)、組件的交互。同樣一件事情，在前后端來看完全是兩個東西，比如保存一項數(shù)據(jù)，后端需要關(guān)注的可能是如何校驗，如何存儲，如何索引，如何關(guān)聯(lián)。但前端要關(guān)注的卻是校驗結(jié)果的展現(xiàn)形式如何，生成一個結(jié)構(gòu)化數(shù)據(jù)需要調(diào)用多少頁面，這些頁面在不同的屏幕下面如何展現(xiàn)，是跳轉(zhuǎn)還是覆蓋或者彈窗。

后端其實更注重邏輯架構(gòu)與部署圖，因為后端需要為服務(wù)化，服務(wù)間邊界的定義要非常清晰、具體，對于一個服務(wù)內(nèi)的代碼后端有 Spring 等明確的框架去規(guī)范如何寫。前端與微服務(wù)對應(yīng)的，應(yīng)該就是組件 了，但是組件覆蓋的范圍太廣，從一個按鈕到一個頁面都可以稱之為組件，所以前端的組件需要被劃分成模塊、控件等不同封裝水平的單位。在這個劃分的過程中，邏輯架構(gòu)和類圖就自然體現(xiàn)出來了。同時前后端解決的問題不同，導(dǎo)致關(guān)注點也不同，前端需要關(guān)注頁面的還原，比如頁面的元素應(yīng)該如何抽象，樣式應(yīng)該如何復(fù)用，這個是后端不用考慮的。

后端需要關(guān)注暴露出去的 thrift 或者 http 接口，因為這體現(xiàn)了系統(tǒng)間交互的邏輯。而對于前端來說對應(yīng)的也應(yīng)該明確獨立模塊或者頁面之間的交互邏輯，所以也就需要明確這些接口。

關(guān)于實施方案和風(fēng)險控制，各方的關(guān)注點也有稍許不同，后端更關(guān)心系統(tǒng)之間的集成，舊數(shù)據(jù)的兼容。而前端應(yīng)該關(guān)心的是和移動 Native 的集成，或者微信、支付寶的集成，如果是桌面 web 的話就該考慮 iframe 集成的場景。

結(jié)論

作為軟件工程的最佳實現(xiàn)，方案設(shè)計在前端開發(fā)過程中還是十分必要的，那么為什么前端領(lǐng)域長時間不注重這個事情呢，我覺得有以下原因：

1. 方案設(shè)計依賴技術(shù)能力，而前端技術(shù)棧變化太快，今天的設(shè)計套路放在明天可能就失效了

2. 前端業(yè)務(wù)變化太快，經(jīng)過半年的迭代之后，可能第一版的方案就反應(yīng)不出現(xiàn)有代碼邏輯了

3. 前端的業(yè)務(wù)流程、交互流程比后端復(fù)雜太多，而且可復(fù)用性差，需要花費大量時間去思考和整理，而且對抽象能力有比較高的要求

4. 前端開發(fā)效率高，不會有歷史包袱，有時候直接重寫的效率反而更高

但是這些原因其實都不是我們不做方案設(shè)計的理由，方案設(shè)計是個結(jié)構(gòu)化思維的過程，他不光是能讓項目更好執(zhí)行，也能提升開發(fā)者本身的架構(gòu)能力和宏觀意識。

所以同學(xué)們在平時開發(fā)的時候多想一想如何做設(shè)計吧。

總而言之，web前端歸于編程技術(shù)類，都是與頁面前端有更大的聯(lián)系，并且都是目前社會上比較短少的人才，而我們需要的就是可以挑選好自己想學(xué)習(xí)的技術(shù)，極力的學(xué)習(xí)好它，讓它為你所用。