轉行前端該怎么開始？

跟著互聯網開展，互聯網的體系越多越多，越來越雜亂，用戶不能滿意基本功用的需求，對互聯網體會要求越來越高，客戶端與服務器的交互不在是簡略頁面和頁面的交互，而變為頁面和頁面+程序+數據的交互，其間完成與客戶交互和體會的程序就是Web前端工程師完成的，這時Web前端工程師就誕生了，跟著用戶對體會和交互要求越高，體系功用越雜亂，Web前端工程師的崗位就越重要。

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

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

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

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

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

現狀

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

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

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

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

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

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

那么我們應該如何從這個循環里跳出來呢？

對比

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

但是我們嘗試按照后端的方法來做方案設計發現根本寫不出來什么內容：

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

• 后端需要列舉出來數據庫表結構，而我們都是把數據丟給后端

• 后端有業務模型，而對我們來說，從后端拿數據就行了

• 后端有核心業務流程，而我們調用他們 API 就行了

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

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

分析

這時候我們要重新審視方案設計的套路，來發現前后端的不同：

• 業務分析

• 業務模型

• 核心流程

• 邏輯架構、類圖、部署圖

• 接口

• 實施方案

• 風險控制

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

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

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

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

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

結論

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

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

2. 前端業務變化太快，經過半年的迭代之后，可能第一版的方案就反應不出現有代碼邏輯了

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

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

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

所以同學們在平時開發的時候多想一想如何做設計吧。

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