背景
對於我們日常工作來說，寫代碼可能佔去了大部分時間，但當我們回頭看以前代碼的時候，我們往往會覺得以前自己寫的很糟糕。
或者在向前看看資歷比較老的同事，往往都可以寫出比較清晰的代碼，有一種莫名的優雅。
也許通過時間的歷練，在幾年之後自己也可以達到對方的水平，但是這個時間太久。
可不可以總結出一些可以複製的方法、套路，讓新人也能儘早寫出一套漂亮的代碼？
本篇文章就是針對前端的研發情況，討論這些方法、套路的。
現狀
我們往往都會陷入這樣一種循環，在拿到需求文檔時候，我們會大致看一下，感覺開發上沒有什麼太大的問題，然後就看看交互、UI 稿上有哪些頁面，接下來就開始著手寫了。
在寫代碼的過程中，我們也許會發現有些實現不合理的地方，這時我們會稍微動一下我們的大腦，然後抽象一下流程和模塊，重構一下部分代碼。遇到簡單點的情況，我們發現加個參數傳過去做一下判斷也能實現，於是我們也就這麼做了。
開發完後，我們會覺得比較滿足，代碼在腦中的邏輯比較清晰，裡面也許有些地方寫的不太妥當，但是也無妨吧。
然後項目就開始測試了，QA 會針對各種邊界問題給我們提 bug，在改 bug 的過程中我們痛苦不堪，之前的代碼邏輯變得支離破碎，我們不得不為了各種 bug 去為代碼修修補補，方法的參數加了一個又一個，邏輯裡的條件判斷加了又加。往往到這個時候，我們開始對 QA 提出的 bug 表示質疑，我們會用“現在的表現是符合邏輯的”，“這種情況沒問題”等等這樣的說辭來避免對代碼的更改。
過去幾個月之後，我們接到一個需求，要對這部分代碼增加幾個新功能，翻開代碼的時候，整個人都崩潰了。以前代碼的邏輯自己早就忘記了，面對自己已經看不懂的代碼，我們會問“這個方法什麼意思？為什麼邏輯這麼複雜？”，“代碼在不同頁面之間跳來跳去，他們的邏輯到底是什麼樣的？”，“為什麼會有這麼多標識位，他們都是幹嘛的？”。註釋什麼的是不存在的，即使存在，也不明白在講些什麼。
在經歷過閱讀源碼的痛苦過程之後，我們看了看排期，嗯。。。還有 30% 的 buffer，於是我們決定把這部分代碼重寫掉，然後再重複這個痛苦的循壞。
那麼我們應該如何從這個循環裡跳出來呢？
對比
我們相比一下後端，會發現他們在寫代碼之前都會做方案設計。方案設計是軟件工程裡的一個最佳實踐，通常做技術方案的過程中會體現出軟件整體的架構，當對核心流程梳理完成之後，最後基本都能落實到代碼上。也就是說好的技術方案能體現出最後代碼的邏輯，通過看方案就能知道代碼怎麼寫。這樣就防止了在寫代碼過程中邊寫邊改，最後導致代碼結構混亂的問題。
但是我們嘗試按照後端的方法來做方案設計發現根本寫不出來什麼內容：
- 後端的流程圖是系統間交互的流程，而我們大都數場景下只需要和一個後端交互
- 後端需要列舉出來數據庫表結構，而我們都是把數據丟給後端
- 後端有業務模型，而對我們來說，從後端拿數據就行了
- 後端有核心業務流程，而我們調用他們 API 就行了
從上面我們可以看出，前端只運行在瀏覽器裡，業務上只和後端有交互，而且 API 都是後端定好的，所以按照後端方案設計的套路，前端是寫不出來什麼東西的。
所以我們會發現，我們大多數設計文檔都是偏 Node 層的東西，因為我們往往都是按照後端設計方案的模式去做的，但是瀏覽器內部運行的代碼卻沒有文檔去描述。
分析
這時候我們要重新審視方案設計的套路，來發現前後端的不同：
- 業務分析
- 業務模型
- 核心流程
- 邏輯架構、類圖、部署圖
- 接口
- 實施方案
- 風險控制
業務分析與業務模型可能前後端都是一致的，畢竟我們是解決同一個業務問題。但其中也有稍許差別，前端有些數據不是從後端獲取的，或者說不一定非要從後端獲取，這點我們需要在做設計的時候考慮進去，比如同樣是獲取地理位置，我們可以通過 GPS 也可以通過訪問後端服務通過 IP 地址來判斷，google 甚至有通過 WIFI 唯一識別碼來定位的。
前後端對於「核心流程」的定義也不同，對於後端來說核心流程是數據的產生、流轉、消費，但是提到流程，在前端來說更多的是頁面的流轉、組件的交互。同樣一件事情，在前後端來看完全是兩個東西，比如保存一項數據，後端需要關注的可能是如何校驗，如何存儲，如何索引，如何關聯。但前端要關注的卻是校驗結果的展現形式如何，生成一個結構化數據需要調用多少頁面，這些頁面在不同的屏幕下面如何展現，是跳轉還是覆蓋或者彈窗。
後端其實更注重邏輯架構與部署圖，因為後端需要為服務化，服務間邊界的定義要非常清晰、具體，對於一個服務內的代碼後端有 Spring 等明確的框架去規範如何寫。前端與微服務對應的，應該就是組件 了，但是組件覆蓋的範圍太廣，從一個按鈕到一個頁面都可以稱之為組件，所以前端的組件需要被劃分成模塊、控件等不同封裝水平的單位。在這個劃分的過程中，邏輯架構和類圖就自然體現出來了。同時前後端解決的問題不同，導致關注點也不同，前端需要關注頁面的還原，比如頁面的元素應該如何抽象，樣式應該如何複用，這個是後端不用考慮的。
後端需要關注暴露出去的 thrift 或者 http 接口，因為這體現了系統間交互的邏輯。而對於前端來說對應的也應該明確獨立模塊或者頁面之間的交互邏輯，所以也就需要明確這些接口。
關於實施方案和風險控制，各方的關注點也有稍許不同，後端更關心繫統之間的集成，舊數據的兼容。而前端應該關心的是和移動 Native 的集成，或者微信、支付寶的集成，如果是桌面 web 的話就該考慮 iframe 集成的場景。
結論
作為軟件工程的最佳實現，方案設計在前端開發過程中還是十分必要的，那麼為什麼前端領域長時間不注重這個事情呢，我覺得有以下原因：
- 方案設計依賴技術能力，而前端技術棧變化太快，今天的設計套路放在明天可能就失效了
- 前端業務變化太快，經過半年的迭代之後，可能第一版的方案就反應不出現有代碼邏輯了
- 前端的業務流程、交互流程比後端複雜太多，而且可複用性差，需要花費大量時間去思考和整理，而且對抽象能力有比較高的要求
- 前端開發效率高，不會有歷史包袱，有時候直接重寫的效率反而更高
但是這些原因其實都不是我們不做方案設計的理由，方案設計是個結構化思維的過程，他不光是能讓項目更好執行，也能提升開發者本身的架構能力和宏觀意識。
所以同學們在平時開發的時候多想一想如何做設計吧。
閱讀更多 前端小白說 的文章
