前端須要什麼樣的方案設計

背景

對於咱們平常工做來講，寫代碼可能佔去了大部分時間，但當咱們回頭看之前代碼的時候，咱們每每會以爲之前本身寫的很糟糕。

或者在向前看看資歷比較老的同事，每每均可以寫出比較清晰的代碼，有一種莫名的優雅。
也許經過時間的歷練，在幾年以後本身也能夠達到對方的水平，可是這個時間過久。
可不能夠總結出一些能夠複製的方法、套路，讓新人也能儘早寫出一套漂亮的代碼？

本篇文章就是針對前端的研發狀況，討論這些方法、套路的。

現狀

咱們每每都會陷入這樣一種循環，在拿到需求文檔時候，咱們會大體看一下，感受開發上沒有什麼太大的問題，而後就看看交互、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. 前端開發效率高，不會有歷史包袱，有時候直接重寫的效率反而更高

可是這些緣由其實都不是咱們不作方案設計的理由，方案設計是個結構化思惟的過程，他不光是能讓項目更好執行，也能提高開發者自己的架構能力和宏觀意識。

因此同窗們在平時開發的時候多想想如何作設計吧。